On 10/09/2016 02:51 AM, Rowland Penny via samba wrote:> Have you by any chance got another 3001108 'xidNumber' in idmap.ldb ? > If you give a user a 'uidNumber' attribute, the contents of this will be > used instead of the 'xidNumber' in idmap.ldb, hence you do not need to > (and probably shouldn't) use numbers in the '3000000' range.I managed to make this right at least for the DC, two Windows 7 Professional boxes, and two CentOS 6 systems. I have one CentOS 6 VM that doesn't work but it would seem that has to be specific to the VM. In order to fix the problem I had "accidentally" removed this line idmap_ldb:use rfc2307 = yes from the DC /etc/samba/smb.conf # Global parameters [global] server string = Example Active Directory Server workgroup = SAMDOM realm = SAMDOM.EXAMPLE.COM netbios name = DC_EXAMPLE server role = active directory domain controller server services = -dns bind interfaces only = yes interfaces = br0 lo encrypt passwords = true kerberos method = secrets and keytab winbind use default domain = yes winbind offline logon = false winbind enum groups = yes winbind enum users = yes # winbind separator = + winbind nss info = rfc2307 map untrusted to domain = no template homedir = /home/%U template shell = /bin/bash idmap_ldb:use rfc2307 = yes [netlogon] path = /var/lib/samba/sysvol/samdom.example.com/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No [Profiles] path = /home/Profiles/ read only = No [home] path = /home read only = No After I added back the missing line everything seemed to work again. The history to all this is that I am running the sernet-samba packages on a CentOS 6 system which seem to be not very compatible with sssd. Therefore I just want winbindd which is adequate for my purposes. To that end I tried to follow these wiki pages: https://wiki.samba.org/index.php/Idmap_config_ad https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD When I provisioned I had done so with rfc2307. So all the NIS extrensions are there. So this gets me to the problem at hand. First, there is actually no 3001108 xidNumber in the idmap.ldb. The xidNumber for this particular user is actually 3000062. For a user that works it turns out I apparently gave uidNumber = xidNumber = 3001107. I only have two users. I'm an unclear on what the correct thing to do in this case. Are you saying that since the xidNumbers are in the "3000000" I should not use uidNumbers in the same range? How should I "pick" the idmap ranges, the uidNumbers, etc.? Wouldn't the uidNumbers be independent from the xidNumbers which is why the addition of the "idmap_ldb:use rfc2307 = yes" in the DC smb.conf fixes the issue? Also on the member server side I have been using this smb.conf [global] workgroup = SAMDOM realm = SAMDOM.EXAMPLE.COM server string = Example Samba Server Version %v netbios name = EXAMPLE security = ads bind interfaces only = yes interfaces = br0 kerberos method = system keytab idmap config *:backend = tdb idmap config *:range = 1000000-2999999 idmap config SAMDOM:backend = ad idmap config SAMDOM:schema_mode = rfc2307 idmap config SAMDOM:range = 3000000-40000000 winbind nss info = rfc2307 winbind use default domain = true winbind offline logon = false winbind enum groups = yes winbind enum users = yes So what should I do at this point? Does it make sense to change the uidNumbers (possibly the gidNumbers too)? I really would like to make this right before I try to move the DC to other hardware. -- Paul (ganci at nurdog.com) Cell: (303)257-5208
On Sun, 9 Oct 2016 11:50:42 -0600 "Paul R. Ganci via samba" <samba at lists.samba.org> wrote:> On 10/09/2016 02:51 AM, Rowland Penny via samba wrote: > > Have you by any chance got another 3001108 'xidNumber' in > > idmap.ldb ? If you give a user a 'uidNumber' attribute, the > > contents of this will be used instead of the 'xidNumber' in > > idmap.ldb, hence you do not need to (and probably shouldn't) use > > numbers in the '3000000' range. > I managed to make this right at least for the DC, two Windows 7 > Professional boxes, and two CentOS 6 systems. I have one CentOS 6 VM > that doesn't work but it would seem that has to be specific to the > VM. In order to fix the problem I had "accidentally" removed this line > > idmap_ldb:use rfc2307 = yes > > from the DC /etc/samba/smb.conf > > # Global parameters > [global] > server string = Example Active Directory Server > workgroup = SAMDOM > realm = SAMDOM.EXAMPLE.COM > netbios name = DC_EXAMPLE > server role = active directory domain controller > server services = -dns > bind interfaces only = yes > interfaces = br0 lo > encrypt passwords = true > kerberos method = secrets and keytab > winbind use default domain = yes > winbind offline logon = false > winbind enum groups = yes > winbind enum users = yes > # winbind separator = + > winbind nss info = rfc2307 > map untrusted to domain = no > template homedir = /home/%U > template shell = /bin/bash > idmap_ldb:use rfc2307 = yes > > [netlogon] > path = /var/lib/samba/sysvol/samdom.example.com/scripts > read only = No > > [sysvol] > path = /var/lib/samba/sysvol > read only = No > > [Profiles] > path = /home/Profiles/ > read only = No > > [home] > path = /home > read only = No > > After I added back the missing line everything seemed to work again. > The history to all this is that I am running the sernet-samba > packages on a CentOS 6 system which seem to be not very compatible > with sssd. Therefore I just want winbindd which is adequate for my > purposes. To that end I tried to follow these wiki pages: > > https://wiki.samba.org/index.php/Idmap_config_ad > https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD > > When I provisioned I had done so with rfc2307. So all the NIS > extrensions are there. > > So this gets me to the problem at hand. First, there is actually no > 3001108 xidNumber in the idmap.ldb. The xidNumber for this particular > user is actually 3000062. For a user that works it turns out I > apparently gave uidNumber = xidNumber = 3001107. I only have two > users. I'm an unclear on what the correct thing to do in this case. > Are you saying that since the xidNumbers are in the "3000000" I > should not use uidNumbers in the same range? How should I "pick" the > idmap ranges, the uidNumbers, etc.? Wouldn't the uidNumbers be > independent from the xidNumbers which is why the addition of the > "idmap_ldb:use rfc2307 = yes" in the DC smb.conf fixes the issue? > > Also on the member server side I have been using this smb.conf > > [global] > workgroup = SAMDOM > realm = SAMDOM.EXAMPLE.COM > server string = Example Samba Server Version %v > netbios name = EXAMPLE > security = ads > bind interfaces only = yes > interfaces = br0 > kerberos method = system keytab > idmap config *:backend = tdb > idmap config *:range = 1000000-2999999 > idmap config SAMDOM:backend = ad > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 3000000-40000000 > winbind nss info = rfc2307 > winbind use default domain = true > winbind offline logon = false > winbind enum groups = yes > winbind enum users = yes > > So what should I do at this point? Does it make sense to change the > uidNumbers (possibly the gidNumbers too)? I really would like to make > this right before I try to move the DC to other hardware.OK, what I was trying to get at, if you use 'uidNumbers' starting at '3000000' and have problems, you have no real way of knowing if it is an idmap problem or a problem with Samba. Using a different range makes it easier to tell. As for the uidNumbers being independent of the the xidNumbers, this is not a problem, this is my info from AD via getent: root at dc1:~# getent passwd rowland SAMDOM\rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash How did you change to using winbind instead of the internal DNS server, did you follow the Samba wiki ? I wouldn't bother changing your uidNumber attributes, now you have it working. I would like to take you to task over 'winbindd which is adequate for my purposes'. Anything that sssd can do, winbind can do, in fact sssd uses some of the code from winbind. Rowland
On 10/09/2016 12:14 PM, Rowland Penny via samba wrote:> OK, what I was trying to get at, if you use 'uidNumbers' starting at > '3000000' and have problems, you have no real way of knowing if it is > an idmap problem or a problem with Samba. Using a different range makes > it easier to tell. > > As for the uidNumbers being independent of the the xidNumbers, this is > not a problem, this is my info from AD via getent: > > root at dc1:~# getent passwd rowland > SAMDOM\rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bashYes I understand. When I setup the Samba DC on 4.0 I had all kinds of issues with the mapping. I had started with RID and then you convinced me to go to the AD backend several years ago (2013). Why I picked the numbers I did... well it seemed like a good idea at the time. More recently I found from the wiki that ADUC can be used to set the UNIX attributes which will start in the range you show. If I wanted to change is it not as simple as using ldbedit -H /var/lib/samba/private/sam.ldb and changing the values and then using chown to make the directories owned by the proper uid?> How did you change to using winbind instead of the internal DNS server, > did you follow the Samba wiki ?I never was using the internal DNS server. I provisioned using BIND_DLZ back when I created the DC on 4.0.x. I never had a problem until more recently when the DNS didn't update after making changes using samba-tool. That is where I found the wiki https://wiki.samba.org/index.php/Changing_the_DNS_backend and followed the instructions there. The missing element I think is server services -dns I have always been using the AD backend with winbind from day one to get the UNIX attributes. It has worked just fine.> I wouldn't bother changing your uidNumber attributes, now you have it > working. > > I would like to take you to task over 'winbindd which is adequate for > my purposes'. Anything that sssd can do, winbind can do, in fact sssd > uses some of the code from winbind.I am sorry but on this point I will disagree mostly because I have chosen to use CentOS 6 (moving to 7) and the sernet-samba packages. There have been several threads which indicate that there are problems using sssd working with sernet-samba. For example I just ran into the one described in this thread https://lists.samba.org/archive/samba/2015-March/190477.html - [Samba]sssd-ad cannot be installed with sernet samba. Moreover I spent several weeks trying to get this to work back in november 2013. See thread [Samba]User home directory UID:GID incorrect on VM Samba 4 AD client. I think some of the issue is that the CentOS sssd is old. Some of the problem is that the sernet-samba packages put stuff in unexpected places. Some of the install can be worked out with manually creating links. But ultimately I could never get sssd to pull out the 4 things... user shell, home directory and proper uid & gid necessary to work with linux. FWIW I have always found winbind just to work albeit it there are limitations compared to a working sssd. -- Paul (ganci at nurdog.com) Cell: (303)257-5208
On 10/09/2016 12:14 PM, Rowland Penny via samba wrote:> I would like to take you to task over 'winbindd which is adequate for > my purposes'. Anything that sssd can do, winbind can do, in fact sssd > uses some of the code from winbind.I should say one more thing. If you have a URL of a good, recent guide I will give it a try again. I want to move to hardware running CentOS 7. I am willing to try yet one more time to get sssd to work given that I am going to move the server anyhow. Now is as good a time as any to try to get sssd working if it can be made to work given my choice of OS and Samba distributions. -- Paul (ganci at nurdog.com) Cell: (303)257-5208
On 10/09/2016 12:14 PM, Rowland Penny via samba wrote:> On Sun, 9 Oct 2016 11:50:42 -0600 > "Paul R. Ganci via samba"<samba at lists.samba.org> wrote: > >> >On 10/09/2016 02:51 AM, Rowland Penny via samba wrote: >>> > >Have you by any chance got another 3001108 'xidNumber' in >>> > >idmap.ldb ? If you give a user a 'uidNumber' attribute, the >>> > >contents of this will be used instead of the 'xidNumber' in >>> > >idmap.ldb, hence you do not need to (and probably shouldn't) use >>> > >numbers in the '3000000' range.So I am still seeing some flakiness with the uidNumber 3001108. I just added a new client to the domain and for some weird reason it is getting the incorrect group id for the ssh_users group I created. On the DC and 2 Windows 7 Boxes and 3 CentOS 6 boxes getent returns the correct: > getent group ssh_users ssh_users:x:3001109: But on the new CentOS 7 box with a fresh install off sernet-samba 4.5.0 I get this incorrect result: > getent group ssh_users ssh_users:x:3001108: I went through every entry in the idmap.ldb and there are no duplicates. In fact the only place 3001108 shows up is as the uidNumber for account sln-11868bg which I showed earlier in the day: > getent passwd sln-11868bg sln-11868bg:*:3001108:3000513:John Q. Public:/home/sln-11868bg:/bin/bash Here is the idmap.txt. The SIDs are listed in first column, the description of the SID is in the second column, the xidNumber is in the third column and where appropriate the uidNumber is in the 4th column and gidNumber in the 5th column. I sorted the idmap.ldb xidNumber in ascending order and determined there are no duplicate xidNumbers. Given this table does anyone see anything stand out that is wrong that would cause one client to get the incorrect group gidNumber? This is everything in the domain... SID Description xidNumber uidNumber gidNumber S-1-5-21-729452656-3029571206-2736118167-500 SAMDOM\Administrator 1 0 S-1-5-32-544 BUILTIN\Administrators 4 3000000 S-1-5-32-549 BUILTIN\Server Operators 4 3000001 S-1-5-21-729452656-3029571206-2736118167-572 SAMDOM\Denied RODC Password Replication Group 4 3000005 S-1-5-32-545 BUILTIN\Users 4 3000009 S-1-5-32-546 BUILTIN\Guests 4 3000015 S-1-5-21-729452656-3029571206-2736118167-1000 SAMDOM\NIKITA$ 1 3000016 S-1-5-32-560 BUILTIN\Windows Authorization Access Group 4 3000018 S-1-5-32-554 BUILTIN\Pre-Windows 2000 Compatible Access 4 3000019 S-1-5-21-729452656-3029571206-2736118167-1105 SAMDOM\SASHA$ 1 3000027 S-1-5-21-729452656-3029571206-2736118167-1114 SAMDOM\NANOOK$ 1 3000035 S-1-5-21-729452656-3029571206-2736118167-1115 SAMDOM\Roaming Profile and Folder Redirection Users 2 3000036 S-1-5-21-729452656-3029571206-2736118167-1116 SAMDOM\nas$ 1 3000037 S-1-5-21-729452656-3029571206-2736118167-1117 SAMDOM\imap-nikita 1 3000038 S-1-5-21-729452656-3029571206-2736118167-1118 SAMDOM\smtp-nikita 1 3000039 S-1-5-21-729452656-3029571206-2736118167-498 SAMDOM\Enterprise Read-Only Domain Controllers 2 3000052 S-1-5-21-729452656-3029571206-2736118167-1133 SAMDOM\mcduff$ 1 3000054 S-1-5-21-729452656-3029571206-2736118167-1134 SAMDOM\shamu$ 1 3000055 S-1-5-21-729452656-3029571206-2736118167-1143 SAMDOM\sln-11868bg 1 3000062 3001108 30000513 S-1-5-21-729452656-3029571206-2736118167-1145 SAMDOM\media-server$ 1 3000064 S-1-5-32-548 BUILTIN\Account Operators 4 3000066 S-1-5-32-551 BUILTIN\Backup Operators 4 3000068 S-1-5-32-550 BUILTIN\Print Operators 4 3000067 S-1-5-32-552 BUILTIN\Replicator 3000069 S-1-5-32-555 BUILTIN\Remote Desktop Users 4 3000070 S-1-5-32-556 BUILTIN\Network Configuration Operators 4 3000071 S-1-5-32-557 BUILTIN\Incoming Forest Trust Builders 4 3000072 S-1-5-32-558 BUILTIN\Performance Monitor Users 4 3000073 S-1-5-32-559 BUILTIN\Performance Log Users 4 3000074 S-1-5-32-561 BUILTIN\Terminal Server License Servers 4 3000075 S-1-5-32-562 BUILTIN\Distributed COM Users 4 3000076 S-1-5-32-568 BUILTIN\IIS_IUSRS 4 3000077 S-1-5-32-573 BUILTIN\Event Log Readers 4 3000079 S-1-5-32-569 BUILTIN\Cryptographic Operators 4 3000078 S-1-5-32-574 BUILTIN\Certificate Service DCOM Access 4 3000080 S-1-5-21-729452656-3029571206-2736118167-517 SAMDOM\Cert Publishers 4 3000081 S-1-5-21-729452656-3029571206-2736118167-553 SAMDOM\RAS and IAS Servers 4 3000082 S-1-5-21-729452656-3029571206-2736118167-571 SAMDOM\Allowed RODC Password Replication Group 4 3000083 S-1-5-21-729452656-3029571206-2736118167-1102 SAMDOM\DnsAdmins 4 3000084 CN=CONFIG lowerBound: 3000000 upperBound: 4000000 3000086 S-1-5-21-729452656-3029571206-2736118167-501 SAMDOM\Guest 1 3000501 S-1-5-21-729452656-3029571206-2736118167-502 SAMDOM\krbtgt 1 3000502 S-1-5-21-729452656-3029571206-2736118167-512 SAMDOM\Domain Admins 2 3000512 3000512 S-1-5-21-729452656-3029571206-2736118167-513 SAMDOM\Domain Users 2 3000513 3000513 S-1-5-21-729452656-3029571206-2736118167-514 SAMDOM\Domain Guests 2 3000514 S-1-5-21-729452656-3029571206-2736118167-515 SAMDOM\Domain Computers 2 3000515 S-1-5-21-729452656-3029571206-2736118167-516 SAMDOM\Domain Controllers 2 3000516 S-1-5-21-729452656-3029571206-2736118167-518 SAMDOM\Schema Admins 2 3000518 S-1-5-21-729452656-3029571206-2736118167-519 SAMDOM\Enterprise Admins 2 3000519 S-1-5-21-729452656-3029571206-2736118167-521 SAMDOM\Read-Only Domain Controllers 2 3000521 S-1-5-21-729452656-3029571206-2736118167-1101 SAMDOM\dns-nikita 1 3001101 S-1-5-21-729452656-3029571206-2736118167-1103 SAMDOM\DnsUpdateProxy 2 3001103 S-1-5-21-729452656-3029571206-2736118167-1144 SAMDOM\prg-11868bg 1 3001107 3001107 3000513 S-1-5-21-729452656-3029571206-2736118167-1109 SAMDOM\ssh_users 2 3001109 3001109 I only have a two accounts (not counting the Administrator account) and 3 groups that maybe I care about so changing gidNumbers and/or uidNumbers should not be too big a deal. But I am not convinced that is going to fix anything. -- Paul (ganci at nurdog.com) Cell: (303)257-5208