Message posted to email@example.com:
How are you keeping ?
A while ago I mentioned a problem that I'm picking up with Samba with
OpenLDAP and the "logon hours" restrictions which are implemented via the NT
4.0 User Manager.
Basically my problem was that users were unable to login 2 hours before the
actual restriction should kick in.
At the time I thought that perhaps the problem was caused by Slackware Linux
and it's timezone implementation of SAST (GMT+2).
Since then I've experienced the same problem on SLES9 and Suse Linux 9.3.
From what I can see, the "sambaLogonHours" value is always set with GMT in
Because in South Africa we are at GMT+2 Samba enforces restrictions 2 hours
before it should.
For example if users should only denied login access at 16:00, Samba is
denying them access at 14:00.
I've looked all over and cannot find a solution to the problem other than
adding two hours to the logon hours restrictions for each user when using
the NT User Manager tool.
Does anyone know of a workaround for this ? Is there a way to get Samba to
check the time zone on the server first and make calculations before writing
values for the "sambaLogonHours" attribute ?
Explanation of feature: http://www.archive-two.com/new-2794385-2895.html
Thanks in advance.
This has been hashed out on the mailing list a good bit.
from auth_sam.c, logon_hours_ok():
hours = pdb_get_hours(sampass); 
utctime = localtime(&smb_last_time.tv_sec); 
Since the hours are stored in GMT, there should be some function to convert the GMT stored time to the server's local time, and after that, the  call makes sense.
More on this. I did some tests, and if the admin machine (the one who runs usrmgr) is in GMT (and the server isn't), looks like the time restriction works the way it should.
switched it to gmtime() instead of localtime() and now it is working for me. Please verify the checkin (rev 11886 in svn).
(In reply to comment #4)
> switched it to gmtime() instead of localtime() and now it is working for me.
> Please verify the checkin (rev 11886 in svn).
Hi Jim. I still haven't tested this. Do you know if this fix was ever implemented ?
Yah, that's what the revision number above is about...when it was checked in...so it should be there.
I will try the latest SerNET packages for SLES 9 and see if it's sorted.