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 ? >> >> RowlandTry having a look here: https://support.microsoft.com/en-us/kb/314494
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
.... forget the previous mail. this can be a mDNS problem. kigm.local ..>-----Oorspronkelijk bericht----- >Van: ryana at reachtechfp.com >[mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >Verzonden: vrijdag 3 juli 2015 16:59 >Aan: samba at lists.samba.org >Onderwerp: Re: [Samba] Clients unable to get group policy... > >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-945 >F-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 > >-- >To unsubscribe from this list go to the following URL and read the >instructions: https://lists.samba.org/mailman/options/samba > >
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/314494OK, 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