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

Fri Jul 3 14:44:09 UTC 2015

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