[Samba] Restricting DC Roles?

[Bethel, Zach]

I went ahead and updated to samba-master, and the error is replaced by a new one that is rather strange:

"Windows was unable to determine whether new Group Policy settings defined by a network administrator should be enforced for this user or computer because this computer's clock is not synchronized with the clock of one of the domain controllers for the domain. Because of this issue, this computer system may not be in compliance with the network administrator’s requirements, and users of this system may not be able to use some functionality on the network. Windows will periodically attempt to retry this operation, and it is possible that either this system or the domain controller will correct the time settings without intervention by an administrator, so the problem will be corrected.

If this issue persists for more than an hour, checking the local system's clock settings to ensure they are accurate and are synchronized with the clocks on the network's domain controllers is one way to resolve this problem. A network administrator may be required to resolve the issue if correcting the local time settings does not address the problem."

So it's obviously complaining about clock skew. Once again, I checked the event log and it's trying to update from the samba machine. The odd thing is that the samba DC time is perfectly in sync with the two Windows DCs. I setup NTP on it, and lsof reveals that the signed socket is indeed being read by samba. I am not having any other authentication issues with kerberos.

Is this a known issue by chance?
Thanks!

________________________________________
From: Andrew Bartlett [abartlet at samba.org]
Sent: Friday, October 26, 2012 5:53 PM
To: Bethel, Zach
Cc: samba at lists.samba.org
Subject: Re: [Samba] Restricting DC Roles?

On Fri, 2012-10-26 at 16:56 +0000, Bethel, Zach wrote:
> Okay, I copied the files over and ran those two commands. Both of them returned nothing (which I assume is a good thing?) and the file permissions appear to have extended ACLs in the sysvol folder. So I'm assuming that worked.
>
> However, when my Windows client attempts to `gpupdate /force` (as the domain admin) from the samba machine, I get the following error message for the computer policy:
>
> "The processing of Group Policy failed. Windows attempted to read the file \\csetest.taylor.edu\sysvol\csetest.taylor.edu\Policies\{GUID}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
>
> a) Name Resolution/Network Connectivity to the current domain controller.
> b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
> c) The Distributed File System (DFS) client has been disabled."
>
> The user policy gets applied just fine.
> When I look in the event viewer, I get error code 5 with "Access is Denied" as the description. The same event has a DCName field which points at the samba machine, so I know that it's trying to talk to samba. I can mount the sysvol share manually as the domain administrator and see all the files just fine.
>
> Any idea what might be going on?

This fix I just put in master is almost certainly for this problem.

If it doesn't apply, then just run 'sh -c 'umask 0 && samba-tool ntacl
sysvolreset' to remove the umask for the duration of this operation.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.