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 >>> >>> On 06/15/2015 09:59 AM, Ryan Ashley wrote: >>>> Well, here is my plan of action. I will migrate the VMs on the >>>> secondary >>>> server to the primary one. Then I will zero the RAID10 array, install >>>> the latest XenServer, and load a Gentoo VM to build the needed binary >>>> packages. I can then create a new DC, promote it to the primary server, >>>> move the Windows VMs back to the secondary server, and then wipe and >>>> reload the primary box. This way I have an evolving OS which shouldn't >>>> be left behind, no systemd, and my problems with Samba should go away. >>>> Oh, and I am not blaming Samba for the issues. It has evolved and >>>> become >>>> better. Debian 6 (Squeeze) has NOT, due to being oldstable and now >>>> obsolete. >>>> >>>> Hey, it will be a learning experience for my assistant. Besides, if I >>>> screw something up I can get great help on this list and worst case >>>> scenario is I get to build a new domain. Thanks for the help, Rowland >>>> and Louis. >>>> >>>> Lead IT/IS Specialist >>>> Reach Technology FP, Inc >>>> >>>> On 06/12/2015 11:03 AM, Rowland Penny wrote: >>>>> On 12/06/15 15:54, L.P.H. van Belle wrote: >>>>>> Ok, so if i understand right, >>>>>> your sysvol is on a shared folder which is a debian squeeze server. >>>>>> i think you problem is that the needed acl cant be set on the queeze >>>>>> server. >>>>> You are probably right Louis. >>>>> >>>>>> and why not systemd, since gentoo also does systemd >>>>>> https://wiki.gentoo.org/wiki/Systemd >>>>> Ah but Gentoo only does systemd if you want to, systemd is a cure >>>>> looking for a problem, or to put it another way, it is like using a >>>>> sledgehammer to crack a nut. >>>>> >>>>>> and if you really want, just run your install with >>>>>> >>>>>> preseed/late_command="in-target apt-get install -y sysvinit-core" >>>>>> ( see https://wiki.debian.org/systemd#Installing_without_systemd ) >>>>> :-D :-D :-D ROFL ROFL >>>>> >>>>> Have you tried NOT using systemd on Jessie! >>>>> >>>>>> I've a running debian jessie as fileserver, proxy server and mail >>>>>> server and im really happy with it. ( yes, with systemd ) >>>>>> much faster boot, well much faster whole os.. ;-) but thats not on >>>>>> debated here.. >>>>>> choose what you like. >>>>> 99% of your speed gain has nothing to do with systemd. >>>>> >>>>> Rowland >>>>> >>>>>> Greetz, >>>>>> >>>>>> Louis >>>>>> >>>>>> >>>>>>> -----Oorspronkelijk bericht----- >>>>>>> Van: ryana at reachtechfp.com >>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>> Verzonden: vrijdag 12 juni 2015 16:17 >>>>>>> Aan: samba at lists.samba.org >>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>> >>>>>>> Louis, 4.2.2 (git clone method for 4-2-stable branch) is what I am >>>>>>> running. I will NOT be using Debian 8 due to systemd. If I have >>>>>>> to do >>>>>>> this, we're going to plan a down-time for the client, zero >>>>>>> everything, >>>>>>> do a fresh XenServer install and install Gentoo 64bit under XS. >>>>>>> If that >>>>>>> is what must be done, so be it. I can do that. I'll simply have >>>>>>> one VM >>>>>>> on each physical server which builds the source packages into binary >>>>>>> ones for the others to pull. This way Gentoo doesn't bog things down >>>>>>> during business hours with compiling updates. >>>>>>> >>>>>>> Lead IT/IS Specialist >>>>>>> Reach Technology FP, Inc >>>>>>> >>>>>>> On 06/12/2015 09:14 AM, L.P.H. van Belle wrote: >>>>>>>> Or upgrade you xen servers and a tip for a jessie install on >>>>>>> xen 6.2 choose other linux >>>>>>>> or upgrade to Xen 6.5. for jessie support. >>>>>>>> >>>>>>>> or you can try upgradeing to latest 3.6 version on squeeze. >>>>>>> ( 3.6.25 ) >>>>>>>> http://www.enterprisesamba.com/samba-packages/debian-linux/squeeze/ >>>>>>>> or even better move up to 4.2.2. ( i advice a wheezy install >>>>>>> with sernet samba ) >>>>>>>> and member servers can be debian jessie with 4.1.17. thats >>>>>>> what you want. >>>>>>>> which samba are you using on squeeze. 3.5.x of the >>>>>>> backported 3.6.6 ? >>>>>>>> Greetz, >>>>>>>> >>>>>>>> Louis >>>>>>>> >>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>> Van: ryana at reachtechfp.com >>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>>>> Verzonden: vrijdag 12 juni 2015 14:47 >>>>>>>>> Aan: samba at lists.samba.org >>>>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>>>> >>>>>>>>> Anybody? Is my problem that this client is still on Debian 6? >>>>>>>>> >>>>>>>>> Lead IT/IS Specialist >>>>>>>>> Reach Technology FP, Inc >>>>>>>>> >>>>>>>>> On 06/08/2015 11:25 AM, Ryan Ashley wrote: >>>>>>>>>> Rowland, you are correct. I remember now. When we started using >>>>>>>>>> XenServer, Wheezy would not work under it. This is a Squeeze >>>>>>>>>> installation, not Wheezy. Will Samba no longer work with >>>>>>>>> Squeeze? If so >>>>>>>>>> it may be an excuse to upgrade the domain after all these years. >>>>>>>>>> >>>>>>>>>> On 06/05/2015 11:23 AM, Rowland Penny wrote: >>>>>>>>>>> On 05/06/15 16:07, Ryan Ashley wrote: >>>>>>>>>>>> I noticed something different on the page you linked. It >>>>>>>>>>>> must be >>>>>>>>>>>> outdated or maybe it is setup for a different version of >>>>>>>>> Debian. The >>>>>>>>>>>> system runs Debian Wheezy AMD64. The paths referenced do >>>>>>>>> not exist. I >>>>>>>>>>>> also checked several other Debian systems and NONE have the >>>>>>>>>>>> "x86_64-linux-gnu" directories. >>>>>>>>>>>> >>>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>>> 2.6.32-5-amd64 >>>>>>>>>>>> root at dc01:~# l /lib | grep x86 >>>>>>>>>>>> lrwxrwxrwx 1 root root 12 Dec 27 2012 >>>>>>>>> ld-linux-x86-64.so.2 -> >>>>>>>>>>>> ld-2.11.3.so >>>>>>>>>>>> root at dc01:~# l /usr/lib | grep x86 >>>>>>>>>>>> root at dc01:~# >>>>>>>>>>>> >>>>>>>>>>>> Is this the problem? What version of Debian is the guide >>>>>>>>> for? I believe >>>>>>>>>>>> Debian 8 was released recently but cannot be sure since it >>>>>>>>> is a systemd >>>>>>>>>>>> distro I now use Gentoo. If the guide is for 8, maybe we >>>>>>>>> need one for 7 >>>>>>>>>>>> since it is supported until the release of 9. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Are you sure it is running wheezy ? >>>>>>>>>>> >>>>>>>>>>> On my DC: >>>>>>>>>>> >>>>>>>>>>> root at dc01:~# cat /etc/os-release >>>>>>>>>>> PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" >>>>>>>>>>> NAME="Debian GNU/Linux" >>>>>>>>>>> VERSION_ID="7" >>>>>>>>>>> VERSION="7 (wheezy)" >>>>>>>>>>> ID=debian >>>>>>>>>>> ANSI_COLOR="1;31" >>>>>>>>>>> HOME_URL="http://www.debian.org/" >>>>>>>>>>> SUPPORT_URL="http://www.debian.org/support/" >>>>>>>>>>> BUG_REPORT_URL="http://bugs.debian.org/" >>>>>>>>>>> >>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>> 3.2.0-4-amd64 >>>>>>>>>>> >>>>>>>>>>> root at dc01:~# ls /lib | grep x86 >>>>>>>>>>> x86_64-linux-gnu >>>>>>>>>>> >>>>>>>>>>> Rowland >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>> >>>>>>> >> 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
Good Afternoon Ryan, I had a similar problem to solve and had to put the users in the administration group. It makes a test places the primary group of a User to administrator and test to see if the GPO will work. Regards, Gabriel Franca> Em 02/07/2015, ?(s) 13:26, Rowland Penny <rowlandpenny241155 at gmail.com> escreveu: > > 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 >>>> >>>> On 06/15/2015 09:59 AM, Ryan Ashley wrote: >>>>> Well, here is my plan of action. I will migrate the VMs on the >>>>> secondary >>>>> server to the primary one. Then I will zero the RAID10 array, install >>>>> the latest XenServer, and load a Gentoo VM to build the needed binary >>>>> packages. I can then create a new DC, promote it to the primary server, >>>>> move the Windows VMs back to the secondary server, and then wipe and >>>>> reload the primary box. This way I have an evolving OS which shouldn't >>>>> be left behind, no systemd, and my problems with Samba should go away. >>>>> Oh, and I am not blaming Samba for the issues. It has evolved and >>>>> become >>>>> better. Debian 6 (Squeeze) has NOT, due to being oldstable and now >>>>> obsolete. >>>>> >>>>> Hey, it will be a learning experience for my assistant. Besides, if I >>>>> screw something up I can get great help on this list and worst case >>>>> scenario is I get to build a new domain. Thanks for the help, Rowland >>>>> and Louis. >>>>> >>>>> Lead IT/IS Specialist >>>>> Reach Technology FP, Inc >>>>> >>>>> On 06/12/2015 11:03 AM, Rowland Penny wrote: >>>>>> On 12/06/15 15:54, L.P.H. van Belle wrote: >>>>>>> Ok, so if i understand right, >>>>>>> your sysvol is on a shared folder which is a debian squeeze server. >>>>>>> i think you problem is that the needed acl cant be set on the queeze >>>>>>> server. >>>>>> You are probably right Louis. >>>>>> >>>>>>> and why not systemd, since gentoo also does systemd >>>>>>> https://wiki.gentoo.org/wiki/Systemd >>>>>> Ah but Gentoo only does systemd if you want to, systemd is a cure >>>>>> looking for a problem, or to put it another way, it is like using a >>>>>> sledgehammer to crack a nut. >>>>>> >>>>>>> and if you really want, just run your install with >>>>>>> >>>>>>> preseed/late_command="in-target apt-get install -y sysvinit-core" >>>>>>> ( see https://wiki.debian.org/systemd#Installing_without_systemd ) >>>>>> :-D :-D :-D ROFL ROFL >>>>>> >>>>>> Have you tried NOT using systemd on Jessie! >>>>>> >>>>>>> I've a running debian jessie as fileserver, proxy server and mail >>>>>>> server and im really happy with it. ( yes, with systemd ) >>>>>>> much faster boot, well much faster whole os.. ;-) but thats not on >>>>>>> debated here.. >>>>>>> choose what you like. >>>>>> 99% of your speed gain has nothing to do with systemd. >>>>>> >>>>>> Rowland >>>>>> >>>>>>> Greetz, >>>>>>> >>>>>>> Louis >>>>>>> >>>>>>> >>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>> Van: ryana at reachtechfp.com >>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>>> Verzonden: vrijdag 12 juni 2015 16:17 >>>>>>>> Aan: samba at lists.samba.org >>>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>>> >>>>>>>> Louis, 4.2.2 (git clone method for 4-2-stable branch) is what I am >>>>>>>> running. I will NOT be using Debian 8 due to systemd. If I have >>>>>>>> to do >>>>>>>> this, we're going to plan a down-time for the client, zero >>>>>>>> everything, >>>>>>>> do a fresh XenServer install and install Gentoo 64bit under XS. >>>>>>>> If that >>>>>>>> is what must be done, so be it. I can do that. I'll simply have >>>>>>>> one VM >>>>>>>> on each physical server which builds the source packages into binary >>>>>>>> ones for the others to pull. This way Gentoo doesn't bog things down >>>>>>>> during business hours with compiling updates. >>>>>>>> >>>>>>>> Lead IT/IS Specialist >>>>>>>> Reach Technology FP, Inc >>>>>>>> >>>>>>>> On 06/12/2015 09:14 AM, L.P.H. van Belle wrote: >>>>>>>>> Or upgrade you xen servers and a tip for a jessie install on >>>>>>>> xen 6.2 choose other linux >>>>>>>>> or upgrade to Xen 6.5. for jessie support. >>>>>>>>> >>>>>>>>> or you can try upgradeing to latest 3.6 version on squeeze. >>>>>>>> ( 3.6.25 ) >>>>>>>>> http://www.enterprisesamba.com/samba-packages/debian-linux/squeeze/ >>>>>>>>> or even better move up to 4.2.2. ( i advice a wheezy install >>>>>>>> with sernet samba ) >>>>>>>>> and member servers can be debian jessie with 4.1.17. thats >>>>>>>> what you want. >>>>>>>>> which samba are you using on squeeze. 3.5.x of the >>>>>>>> backported 3.6.6 ? >>>>>>>>> Greetz, >>>>>>>>> >>>>>>>>> Louis >>>>>>>>> >>>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>>> Van: ryana at reachtechfp.com >>>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>>>>> Verzonden: vrijdag 12 juni 2015 14:47 >>>>>>>>>> Aan: samba at lists.samba.org >>>>>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>>>>> >>>>>>>>>> Anybody? Is my problem that this client is still on Debian 6? >>>>>>>>>> >>>>>>>>>> Lead IT/IS Specialist >>>>>>>>>> Reach Technology FP, Inc >>>>>>>>>> >>>>>>>>>> On 06/08/2015 11:25 AM, Ryan Ashley wrote: >>>>>>>>>>> Rowland, you are correct. I remember now. When we started using >>>>>>>>>>> XenServer, Wheezy would not work under it. This is a Squeeze >>>>>>>>>>> installation, not Wheezy. Will Samba no longer work with >>>>>>>>>> Squeeze? If so >>>>>>>>>>> it may be an excuse to upgrade the domain after all these years. >>>>>>>>>>> >>>>>>>>>>> On 06/05/2015 11:23 AM, Rowland Penny wrote: >>>>>>>>>>>> On 05/06/15 16:07, Ryan Ashley wrote: >>>>>>>>>>>>> I noticed something different on the page you linked. It >>>>>>>>>>>>> must be >>>>>>>>>>>>> outdated or maybe it is setup for a different version of >>>>>>>>>> Debian. The >>>>>>>>>>>>> system runs Debian Wheezy AMD64. The paths referenced do >>>>>>>>>> not exist. I >>>>>>>>>>>>> also checked several other Debian systems and NONE have the >>>>>>>>>>>>> "x86_64-linux-gnu" directories. >>>>>>>>>>>>> >>>>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>>>> 2.6.32-5-amd64 >>>>>>>>>>>>> root at dc01:~# l /lib | grep x86 >>>>>>>>>>>>> lrwxrwxrwx 1 root root 12 Dec 27 2012 >>>>>>>>>> ld-linux-x86-64.so.2 -> >>>>>>>>>>>>> ld-2.11.3.so >>>>>>>>>>>>> root at dc01:~# l /usr/lib | grep x86 >>>>>>>>>>>>> root at dc01:~# >>>>>>>>>>>>> >>>>>>>>>>>>> Is this the problem? What version of Debian is the guide >>>>>>>>>> for? I believe >>>>>>>>>>>>> Debian 8 was released recently but cannot be sure since it >>>>>>>>>> is a systemd >>>>>>>>>>>>> distro I now use Gentoo. If the guide is for 8, maybe we >>>>>>>>>> need one for 7 >>>>>>>>>>>>> since it is supported until the release of 9. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Are you sure it is running wheezy ? >>>>>>>>>>>> >>>>>>>>>>>> On my DC: >>>>>>>>>>>> >>>>>>>>>>>> root at dc01:~# cat /etc/os-release >>>>>>>>>>>> PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" >>>>>>>>>>>> NAME="Debian GNU/Linux" >>>>>>>>>>>> VERSION_ID="7" >>>>>>>>>>>> VERSION="7 (wheezy)" >>>>>>>>>>>> ID=debian >>>>>>>>>>>> ANSI_COLOR="1;31" >>>>>>>>>>>> HOME_URL="http://www.debian.org/" >>>>>>>>>>>> SUPPORT_URL="http://www.debian.org/support/" >>>>>>>>>>>> BUG_REPORT_URL="http://bugs.debian.org/" >>>>>>>>>>>> >>>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>>> 3.2.0-4-amd64 >>>>>>>>>>>> >>>>>>>>>>>> root at dc01:~# ls /lib | grep x86 >>>>>>>>>>>> x86_64-linux-gnu >>>>>>>>>>>> >>>>>>>>>>>> Rowland >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>>>> >>>>>>>>>> >>>>>>>> -- >>>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>> >>>>>>>> >>> 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 > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba <https://lists.samba.org/mailman/options/samba>
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
I cannot do such a thing. This is a place where many users struggle just to use Windows (older people) and one is prone to getting viruses. If this person was an admin, I would be reloading her system monthly instead of deleting her user folder and letting it regen fresh. Besides, GPOs are pulled BEFORE login. Even then, I have logged into the system as domain admin and still cannot do it. This means that it isn't working for the SYSTEM account or the domain admin account. Lead IT/IS Specialist Reach Technology FP, Inc On 07/02/2015 02:39 PM, Gabriel Franca wrote:> Good Afternoon Ryan, > > I had a similar problem to solve and had to put the users in the administration group. > > It makes a test places the primary group of a User to administrator and test to see if the GPO will work. > > Regards, > > Gabriel Franca > > >> Em 02/07/2015, ?(s) 13:26, Rowland Penny <rowlandpenny241155 at gmail.com> escreveu: >> >> 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 >>>>> >>>>> On 06/15/2015 09:59 AM, Ryan Ashley wrote: >>>>>> Well, here is my plan of action. I will migrate the VMs on the >>>>>> secondary >>>>>> server to the primary one. Then I will zero the RAID10 array, install >>>>>> the latest XenServer, and load a Gentoo VM to build the needed binary >>>>>> packages. I can then create a new DC, promote it to the primary server, >>>>>> move the Windows VMs back to the secondary server, and then wipe and >>>>>> reload the primary box. This way I have an evolving OS which shouldn't >>>>>> be left behind, no systemd, and my problems with Samba should go away. >>>>>> Oh, and I am not blaming Samba for the issues. It has evolved and >>>>>> become >>>>>> better. Debian 6 (Squeeze) has NOT, due to being oldstable and now >>>>>> obsolete. >>>>>> >>>>>> Hey, it will be a learning experience for my assistant. Besides, if I >>>>>> screw something up I can get great help on this list and worst case >>>>>> scenario is I get to build a new domain. Thanks for the help, Rowland >>>>>> and Louis. >>>>>> >>>>>> Lead IT/IS Specialist >>>>>> Reach Technology FP, Inc >>>>>> >>>>>> On 06/12/2015 11:03 AM, Rowland Penny wrote: >>>>>>> On 12/06/15 15:54, L.P.H. van Belle wrote: >>>>>>>> Ok, so if i understand right, >>>>>>>> your sysvol is on a shared folder which is a debian squeeze server. >>>>>>>> i think you problem is that the needed acl cant be set on the queeze >>>>>>>> server. >>>>>>> You are probably right Louis. >>>>>>> >>>>>>>> and why not systemd, since gentoo also does systemd >>>>>>>> https://wiki.gentoo.org/wiki/Systemd >>>>>>> Ah but Gentoo only does systemd if you want to, systemd is a cure >>>>>>> looking for a problem, or to put it another way, it is like using a >>>>>>> sledgehammer to crack a nut. >>>>>>> >>>>>>>> and if you really want, just run your install with >>>>>>>> >>>>>>>> preseed/late_command="in-target apt-get install -y sysvinit-core" >>>>>>>> ( see https://wiki.debian.org/systemd#Installing_without_systemd ) >>>>>>> :-D :-D :-D ROFL ROFL >>>>>>> >>>>>>> Have you tried NOT using systemd on Jessie! >>>>>>> >>>>>>>> I've a running debian jessie as fileserver, proxy server and mail >>>>>>>> server and im really happy with it. ( yes, with systemd ) >>>>>>>> much faster boot, well much faster whole os.. ;-) but thats not on >>>>>>>> debated here.. >>>>>>>> choose what you like. >>>>>>> 99% of your speed gain has nothing to do with systemd. >>>>>>> >>>>>>> Rowland >>>>>>> >>>>>>>> Greetz, >>>>>>>> >>>>>>>> Louis >>>>>>>> >>>>>>>> >>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>> Van: ryana at reachtechfp.com >>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>>>> Verzonden: vrijdag 12 juni 2015 16:17 >>>>>>>>> Aan: samba at lists.samba.org >>>>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>>>> >>>>>>>>> Louis, 4.2.2 (git clone method for 4-2-stable branch) is what I am >>>>>>>>> running. I will NOT be using Debian 8 due to systemd. If I have >>>>>>>>> to do >>>>>>>>> this, we're going to plan a down-time for the client, zero >>>>>>>>> everything, >>>>>>>>> do a fresh XenServer install and install Gentoo 64bit under XS. >>>>>>>>> If that >>>>>>>>> is what must be done, so be it. I can do that. I'll simply have >>>>>>>>> one VM >>>>>>>>> on each physical server which builds the source packages into binary >>>>>>>>> ones for the others to pull. This way Gentoo doesn't bog things down >>>>>>>>> during business hours with compiling updates. >>>>>>>>> >>>>>>>>> Lead IT/IS Specialist >>>>>>>>> Reach Technology FP, Inc >>>>>>>>> >>>>>>>>> On 06/12/2015 09:14 AM, L.P.H. van Belle wrote: >>>>>>>>>> Or upgrade you xen servers and a tip for a jessie install on >>>>>>>>> xen 6.2 choose other linux >>>>>>>>>> or upgrade to Xen 6.5. for jessie support. >>>>>>>>>> >>>>>>>>>> or you can try upgradeing to latest 3.6 version on squeeze. >>>>>>>>> ( 3.6.25 ) >>>>>>>>>> http://www.enterprisesamba.com/samba-packages/debian-linux/squeeze/ >>>>>>>>>> or even better move up to 4.2.2. ( i advice a wheezy install >>>>>>>>> with sernet samba ) >>>>>>>>>> and member servers can be debian jessie with 4.1.17. thats >>>>>>>>> what you want. >>>>>>>>>> which samba are you using on squeeze. 3.5.x of the >>>>>>>>> backported 3.6.6 ? >>>>>>>>>> Greetz, >>>>>>>>>> >>>>>>>>>> Louis >>>>>>>>>> >>>>>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>>>>> Van: ryana at reachtechfp.com >>>>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >>>>>>>>>>> Verzonden: vrijdag 12 juni 2015 14:47 >>>>>>>>>>> Aan: samba at lists.samba.org >>>>>>>>>>> Onderwerp: Re: [Samba] Clients unable to get group policy... >>>>>>>>>>> >>>>>>>>>>> Anybody? Is my problem that this client is still on Debian 6? >>>>>>>>>>> >>>>>>>>>>> Lead IT/IS Specialist >>>>>>>>>>> Reach Technology FP, Inc >>>>>>>>>>> >>>>>>>>>>> On 06/08/2015 11:25 AM, Ryan Ashley wrote: >>>>>>>>>>>> Rowland, you are correct. I remember now. When we started using >>>>>>>>>>>> XenServer, Wheezy would not work under it. This is a Squeeze >>>>>>>>>>>> installation, not Wheezy. Will Samba no longer work with >>>>>>>>>>> Squeeze? If so >>>>>>>>>>>> it may be an excuse to upgrade the domain after all these years. >>>>>>>>>>>> >>>>>>>>>>>> On 06/05/2015 11:23 AM, Rowland Penny wrote: >>>>>>>>>>>>> On 05/06/15 16:07, Ryan Ashley wrote: >>>>>>>>>>>>>> I noticed something different on the page you linked. It >>>>>>>>>>>>>> must be >>>>>>>>>>>>>> outdated or maybe it is setup for a different version of >>>>>>>>>>> Debian. The >>>>>>>>>>>>>> system runs Debian Wheezy AMD64. The paths referenced do >>>>>>>>>>> not exist. I >>>>>>>>>>>>>> also checked several other Debian systems and NONE have the >>>>>>>>>>>>>> "x86_64-linux-gnu" directories. >>>>>>>>>>>>>> >>>>>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>>>>> 2.6.32-5-amd64 >>>>>>>>>>>>>> root at dc01:~# l /lib | grep x86 >>>>>>>>>>>>>> lrwxrwxrwx 1 root root 12 Dec 27 2012 >>>>>>>>>>> ld-linux-x86-64.so.2 -> >>>>>>>>>>>>>> ld-2.11.3.so >>>>>>>>>>>>>> root at dc01:~# l /usr/lib | grep x86 >>>>>>>>>>>>>> root at dc01:~# >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this the problem? What version of Debian is the guide >>>>>>>>>>> for? I believe >>>>>>>>>>>>>> Debian 8 was released recently but cannot be sure since it >>>>>>>>>>> is a systemd >>>>>>>>>>>>>> distro I now use Gentoo. If the guide is for 8, maybe we >>>>>>>>>>> need one for 7 >>>>>>>>>>>>>> since it is supported until the release of 9. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Are you sure it is running wheezy ? >>>>>>>>>>>>> >>>>>>>>>>>>> On my DC: >>>>>>>>>>>>> >>>>>>>>>>>>> root at dc01:~# cat /etc/os-release >>>>>>>>>>>>> PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" >>>>>>>>>>>>> NAME="Debian GNU/Linux" >>>>>>>>>>>>> VERSION_ID="7" >>>>>>>>>>>>> VERSION="7 (wheezy)" >>>>>>>>>>>>> ID=debian >>>>>>>>>>>>> ANSI_COLOR="1;31" >>>>>>>>>>>>> HOME_URL="http://www.debian.org/" >>>>>>>>>>>>> SUPPORT_URL="http://www.debian.org/support/" >>>>>>>>>>>>> BUG_REPORT_URL="http://bugs.debian.org/" >>>>>>>>>>>>> >>>>>>>>>>>>> root at dc01:~# uname -r >>>>>>>>>>>>> 3.2.0-4-amd64 >>>>>>>>>>>>> >>>>>>>>>>>>> root at dc01:~# ls /lib | grep x86 >>>>>>>>>>>>> x86_64-linux-gnu >>>>>>>>>>>>> >>>>>>>>>>>>> Rowland >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> To unsubscribe from this list go to the following URL and read the >>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba >>>>>>>>> >>>>>>>>> >>>> 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 >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba <https://lists.samba.org/mailman/options/samba>
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
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 recallgo correct your sysvol SHARE rights first. and reset it from within windows. test and keep "everyone" full acces on the share right. then go to the security tab, and set. Verificed users. Read and execute SYSTEM, Full control Administrators, Full controll Server Operators. Read and execute then try from 1 pc. login as DOMAIN\Administrator try accessing \\server\sysvol and try \\server.your.domain.tld\sysvol do they both work ? if only \\server.your.domain.tld works, then add the domain option to your dhcp server. and there are 2 ! domain options. 1 for the pc and 1 for the domain search. whats the difference... pc joins the domain and wil be named pc.your.domain.tld. pc search can be different, and this can be set wrong in dhcp server. test this also on the remote location. make a test user, set the primairy group to "Domain User" try above again. but, when i read through your mails below, im thinking almost sure your sysvol share rights are not correct. Greetz, Louis>-----Oorspronkelijk bericht----- >Van: ryana at reachtechfp.com >[mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >Verzonden: vrijdag 3 juli 2015 16:19 >Aan: samba at lists.samba.org >Onderwerp: Re: [Samba] Clients unable to get group policy... > >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 > >-- >To unsubscribe from this list go to the following URL and read the >instructions: https://lists.samba.org/mailman/options/samba > >