[Samba] Clients unable to get group policy...

Fri Jul 3 15:20:58 UTC 2015

On 03/07/15 15:58, Ryan Ashley wrote:
> They left a PC on, so I got the info. The info pissed me off, but not
> because of the issue. This time it worked flawlessly, but I got the
> error from the event log from prior attempts. First, today's results.
>
> C:\Users\reachfp.KIGM>gpupdate
> Updating Policy...
>
> User Policy update has completed successfully.
> Computer Policy update has completed successfully.
>
>
> C:\Users\reachfp.KIGM>gpupdate /force
> Updating Policy...
>
> User Policy update has completed successfully.
> Computer Policy update has completed successfully.
>
>
> C:\Users\reachfp.KIGM>
>
>
>
> Now, what was happening EVERY time until today.
>
> The processing of Group Policy failed. Windows attempted to read the
> file
> \\kigm.local\sysvol\kigm.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\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 error comes and goes, but it happens more often than not now, which
> makes it an issue. I will review the link you sent me.
>
> Lead IT/IS Specialist
> Reach Technology FP, Inc
>
> On 07/03/2015 10:44 AM, Rowland Penny wrote:
>> On 03/07/15 15:18, Ryan Ashley wrote:
>>> The only Unix client I can think of would be the Buffalo NAS. It runs
>>> Samba3 and hosts various shares via SMB. DNS is handled by BIND9 on the
>>> Samba4 DC. DNS does work and the domain name resolves to the IP address
>>> of the server. DHCP is also handled on the DC. As for the GPO's, they're
>>> in the correct place as far as I can tell. In fact, the error in the
>>> event log says it cannot access gpt.ini, but if I click the link in the
>>> log, the ini file opens in Notepad, so it is accessible. This is very
>>> strange due to this fact. The event log error is 1058 if I recall
>>> correctly. The client location is closed today, but maybe I can remote
>>> in and find a workstation on to test with. If I can I will post the
>>> exact error shortly.
>>>
>>> Lead IT/IS Specialist
>>> Reach Technology FP, Inc
>>>
>>> On 07/02/2015 12:26 PM, Rowland Penny wrote:
>>>> On 02/07/15 16:55, Ryan Ashley wrote:
>>>>> Rowland, here is what I found in the ldb.
>>>>>
>>>>> # record 68
>>>>> dn: CN=S-1-5-32-544
>>>>> cn: S-1-5-32-544
>>>>> objectClass: sidMap
>>>>> objectSid: S-1-5-32-544
>>>>> type: ID_TYPE_BOTH
>>>>> xidNumber: 3000000
>>>>> distinguishedName: CN=S-1-5-32-544
>>>>>
>>>>> # record 70
>>>>> dn: CN=S-1-5-32-549
>>>>> cn: S-1-5-32-549
>>>>> objectClass: sidMap
>>>>> objectSid: S-1-5-32-549
>>>>> type: ID_TYPE_BOTH
>>>>> xidNumber: 3000001
>>>>> distinguishedName: CN=S-1-5-32-549
>>>>>
>>>>> # record 73
>>>>> dn: CN=S-1-5-18
>>>>> cn: S-1-5-18
>>>>> objectClass: sidMap
>>>>> objectSid: S-1-5-18
>>>>> type: ID_TYPE_BOTH
>>>>> xidNumber: 3000002
>>>>> distinguishedName: CN=S-1-5-18
>>>>>
>>>>> # record 16
>>>>> dn: CN=S-1-5-11
>>>>> cn: S-1-5-11
>>>>> objectClass: sidMap
>>>>> objectSid: S-1-5-11
>>>>> type: ID_TYPE_BOTH
>>>>> xidNumber: 3000003
>>>>> distinguishedName: CN=S-1-5-11
>>>>>
>>>>> It appears as though they're in my database, but clients still cannot
>>>>> update group policy. It randomly works once or twice, then goes
>>>>> back to
>>>>> not working. Due to this, some workstations can hang for 20min
>>>>> trying to
>>>>> update all of their GPOs upon first boot. I have wbinfo working, but
>>>>> 'id' and 'getent' still do not work for domain users and groups.
>>>>> PAM is
>>>>> setup and is pasted below to save you from asking for it, should
>>>>> you be
>>>>> so inclined.
>>>>>
>>>>> # /etc/nsswitch.conf
>>>>> #
>>>>> # Example configuration of GNU Name Service Switch functionality.
>>>>> # If you have the `glibc-doc-reference' and `info' packages
>>>>> installed, try:
>>>>> # `info libc "Name Service Switch"' for information about this file.
>>>>>
>>>>> passwd:         compat winbind
>>>>> group:          compat winbind
>>>>> shadow:         compat
>>>>>
>>>>> hosts:          files dns wins
>>>>> networks:       files
>>>>>
>>>>> protocols:      db files
>>>>> services:       db files
>>>>> ethers:         db files
>>>>> rpc:            db files
>>>>>
>>>>> netgroup:       nis
>>>>>
>>>>> If you have any suggestions, I am all ears. If you say we must upgrade
>>>>> to Gentoo, I have to bite the bullet and do it.
>>>>>
>>>>> One more thing. I discovered that Samba4 cannot be a master
>>>>> browser. Due
>>>>> to this, workstations are randomly being elected as the master
>>>>> browser.
>>>>> When that system sleeps because the client doesn't turn it off, shares
>>>>> become inaccessible. I have a Buffalo NAS that can be a master browser
>>>>> (Samba3 on it), but Buffalo apparently locked me out of SSH access!
>>>>> Could this be related?
>>>>>
>>>>> Lead IT/IS Specialist
>>>>> Reach Technology FP, Inc
>>>>>
>>>>> On 06/30/2015 03:50 PM, Rowland Penny wrote:
>>>>>> On 30/06/15 17:18, Ryan Ashley wrote:
>>>>>>> I hate to revive this, but before I push my client through an
>>>>>>> upgrade, I
>>>>>>> have to be sure my issue is with ACLs not being supported, as
>>>>>>> suggested.
>>>>>>> Squeeze does have ACL support.
>>>>>>>
>>>>>>> root at dc01:/samba/var/locks# getfacl sysvol
>>>>>>> # file: sysvol
>>>>>>> # owner: root
>>>>>>> # group: 3000000
>>>>>>> user::rwx
>>>>>>> user:root:rwx
>>>>>>> user:3000000:rwx
>>>>>>> user:3000001:r-x
>>>>>>> user:3000002:rwx
>>>>>>> user:3000003:r-x
>>>>>>> group::rwx
>>>>>>> group:3000000:rwx
>>>>>>> group:3000001:r-x
>>>>>>> group:3000002:rwx
>>>>>>> group:3000003:r-x
>>>>>>> mask::rwx
>>>>>>> other::rwx
>>>>>>> default:user::rwx
>>>>>>> default:user:root:rwx
>>>>>>> default:user:3000000:rwx
>>>>>>> default:user:3000001:r-x
>>>>>>> default:user:3000002:rwx
>>>>>>> default:user:3000003:r-x
>>>>>>> default:group::---
>>>>>>> default:group:3000000:rwx
>>>>>>> default:group:3000001:r-x
>>>>>>> default:group:3000002:rwx
>>>>>>> default:group:3000003:r-x
>>>>>>> default:mask::rwx
>>>>>>> default:other::---
>>>>>>>
>>>>>>> root at dc01:/samba/var/locks# uname -r
>>>>>>> 2.6.32-5-amd64
>>>>>>>
>>>>>>> With this information, are we absolutely sure that my issue is
>>>>>>> somehow
>>>>>>> related to ACL's in Squeeze? The client is against upgrading
>>>>>>> unless we
>>>>>>> have no other option, but now the problem has spread and is
>>>>>>> affecting a
>>>>>>> large number, but not all PCs at their location.
>>>>>>>
>>>>>>> Lead IT/IS Specialist
>>>>>>> Reach Technology FP, Inc
>>>>>>>
>>>>>>>
>>>>>> Sorry about this, but I think we are going to have to start again, I
>>>>>> cannot remember just exactly what your problem is.
>>>>>>
>>>>>> This is the result of running 'getfacl /var/lib/samba/sysvol' on my
>>>>>> second DC:
>>>>>>
>>>>>> root at dc03:~# getfacl /var/lib/samba/sysvol/
>>>>>> getfacl: Removing leading '/' from absolute path names
>>>>>> # file: var/lib/samba/sysvol/
>>>>>> # owner: root
>>>>>> # group: 3000000 --> dn: CN=S-1-5-32-544
>>>>>> user::rwx
>>>>>> user:root:rwx
>>>>>> user:3000000:rwx --> dn: CN=S-1-5-32-544
>>>>>> user:3000009:r-x --> dn: CN=S-1-5-11
>>>>>> user:3000016:r-x --> dn: CN=S-1-5-32-549
>>>>>> user:3000017:rwx --> dn: CN=S-1-5-18
>>>>>> group::rwx
>>>>>> group:3000000:rwx --> dn: CN=S-1-5-32-544
>>>>>> group:3000009:r-x --> dn: CN=S-1-5-11
>>>>>> group:3000016:r-x --> dn: CN=S-1-5-32-549
>>>>>> group:3000017:rwx --> dn: CN=S-1-5-18
>>>>>> mask::rwx
>>>>>> other::---
>>>>>> default:user::rwx
>>>>>> default:user:root:rwx
>>>>>> default:user:3000000:rwx --> dn: CN=S-1-5-32-544
>>>>>> default:user:3000009:r-x --> dn: CN=S-1-5-11
>>>>>> default:user:3000016:r-x --> dn: CN=S-1-5-32-549
>>>>>> default:user:3000017:rwx --> dn: CN=S-1-5-18
>>>>>> default:group::---
>>>>>> default:group:3000000:rwx --> dn: CN=S-1-5-32-544
>>>>>> default:group:3000009:r-x --> dn: CN=S-1-5-11
>>>>>> default:group:3000016:r-x --> dn: CN=S-1-5-32-549
>>>>>> default:group:3000017:rwx --> dn: CN=S-1-5-18
>>>>>> default:mask::rwx
>>>>>> default:other::---
>>>>>>
>>>>>> As you can see, I have added some extra info, this is what the
>>>>>> xidNumbers are mapped from, so if your xidNumbers map to the same
>>>>>> 'well known SIDs' , then there doesn't seem to be much wrong.
>>>>>>
>>>>>> You can check your 'idmap.ldb' file with: ldbedit -e nano -H
>>>>>> /var/lib/samba/private/idmap.ldb
>>>>>>
>>>>>> Rowland
>>>>>>
>>>> The only difference between your sysvol 'getfacl' output and mine is
>>>> this:
>>>>
>>>> other::rwx
>>>>
>>>> Mine is:
>>>>
>>>> other::---
>>>>
>>>> But this will probably just be down to yours having unix permissions
>>>> '777' on /var/lib/samba/sysvol whilst mine is '770'
>>>>
>>>> If you do not have *any* Unix clients then when connecting to the DC
>>>> from a windows client, id & getent don't need to work. wbinfo works
>>>> differently from id & getent and as it shows your users & groups means
>>>> this is working ok. Is there anything in the event logs on the
>>>> clients, I 'think' this could just be a lack of communication between
>>>> the client & DC, or the GPOs are in the wrong place or something
>>>> stupid like this. How do the clients get their dns info ? Is it a time
>>>> problem ?
>>>>
>>>> Rowland
>> Try having a look here: https://support.microsoft.com/en-us/kb/314494

OK, I used to hate intermittent faults, they *never* appeared when you 
went to fix them :-)

Anyway, the error message gives a possible reason, you are using a 
.local domain, is avahi running on the DC ? if it is, turn it off and 
see how you go on.

Rowland