Alexander Kushnirenko
2019-Nov-09 21:21 UTC
[Samba] Samba 4.9 + winbind and 'domain users' gidNumber=513 problem
Hi I apologize for long introduction, but I hope it can clarify the problem. We use Samba in the following configuration: 1. Samba DC based on Samba4 2. Windows Member Server 2008/2012 where we manage users (windows admin tools have Unix Attributes) and where some users work with Win Programs 3. Multiple Samba4 Member Servers for Shares 4. Multiple Windows/Linux Workstations that use Samba AD for authentication and have access to Samba shares Prior to last upgrade (debian9 use Samba 4.5 ---> debian10 use Samba 4.9) on member servers we used SSSD to extract user information and everything was working fine. But after latest update NTLM auth was gone from smbd and it is now supported only by winbind. We do need NTLM authentication, as there are some old scanners, that scan images to user shares. So we can no longer use SSSD and have to switch to WINBIND, and as I understood this problem is not going to be solved soon, as Samba and SSSD developers can not find a solution that is satisfactory for both products. (see discussion here for example https://lists.samba.org/archive/samba/2019-June/223608.html). Well we tried to marry Winbind (for NTLM auth) and SSSD (for user id mapping) and make it work, but we failed (though some people claim, that they made it work https://lists.fedoraproject.org/archives/list/sssd-users at lists.fedorahosted.org/thread/U66MEJBMXVJWJVCBORS2KBP7BIAGZ57H/ ). Ok, we got rid of SSSD and started to work with Winbind, actualy we used it few years ago and did not worry too much. But there is a problem as in our setup 'domain users' group is 513 (we did not pay attention to this when we created users). And winbind have problem with it as usual id ranges are: idmap config * : range = 3000-7999 <--- here all BUILTIN groups live idmap config DOMAIN : backend = ad idmap config DOMAIN : schema_mode = rfc2307 idmap config DOMAIN : range = 10000-999999 <-- here all our DOMAIN groups live except for domain_users So 'domain group'=513 is outside of DOMAIN group you get an error: # wbinfo -G 513 WBC_ERR_DOMAIN_NOT_FOUND (somewhat misleading error message in my view) And documentation clearly explain it - 513 is outside of 10000-999999 range, and to make things worse builtin ranges and DOMAIN ranges can not overlap. Our plan now is to use 'domain group' = 10513, but we have very little idea what problems it can lead to and it will upset a lot of users if we do it wrong. So here are some questions: 1. Along with gidNumber=513 there is Windows internal primaryGroupID=513 and ordinary users have both attributes set to 513. Should we worry about that? Our users live in mixed environment and use both Linux and Windows resources. 2. We hope that if we change Unix Attribute of 'domain users' to 10513, than change all files ownerships from group 513 to group 10513 in Linux world, then it will solve all our problems, but will it? 3. Or should we create additional 'domain_users_for_unix= 10513) group and move all users to this group and leave Windows builtin 'domain users' group intact? Can someone please comment on this problem? Thank you, Alexander
Rowland penny
2019-Nov-09 21:55 UTC
[Samba] Samba 4.9 + winbind and 'domain users' gidNumber=513 problem
On 09/11/2019 21:21, Alexander Kushnirenko via samba wrote:> Hi > > I apologize for long introduction, but I hope it can clarify the problem. > We use Samba in the following configuration: > 1. Samba DC based on Samba4 > 2. Windows Member Server 2008/2012 where we manage users (windows admin > tools have Unix Attributes) and where some users work with Win Programs > 3. Multiple Samba4 Member Servers for Shares > 4. Multiple Windows/Linux Workstations that use Samba AD for authentication > and have access to Samba shares > > Prior to last upgrade (debian9 use Samba 4.5 ---> debian10 use Samba 4.9) > on member servers we used SSSD to extract user information and everything > was working fine. But after latest update NTLM auth was gone from smbd and > it is now supported only by winbind. We do need NTLM authentication, as > there are some old scanners, that scan images to user shares. So we can no > longer use SSSD and have to switch to WINBIND, and as I understood this > problem is not going to be solved soon, as Samba and SSSD developers can > not find a solution that is satisfactory for both products. (see discussion > here for example https://lists.samba.org/archive/samba/2019-June/223608.html). > > > Well we tried to marry Winbind (for NTLM auth) and SSSD (for user id > mapping) and make it work, but we failed (though some people claim, that > they made it work > https://lists.fedoraproject.org/archives/list/sssd-users at lists.fedorahosted.org/thread/U66MEJBMXVJWJVCBORS2KBP7BIAGZ57H/ > ). > > Ok, we got rid of SSSD and started to work with Winbind, actualy we used it > few years ago and did not worry too much. But there is a problem as in our > setup 'domain users' group is 513 (we did not pay attention to this when we > created users). And winbind have problem with it as usual id ranges are: > idmap config * : range = 3000-7999 <--- here all BUILTIN groups live > idmap config DOMAIN : backend = ad > idmap config DOMAIN : schema_mode = rfc2307 > idmap config DOMAIN : range = 10000-999999 <-- here all our DOMAIN > groups live except for domain_users > > So 'domain group'=513 is outside of DOMAIN group you get an error: > # wbinfo -G 513 > WBC_ERR_DOMAIN_NOT_FOUND (somewhat misleading error message in my view) > And documentation clearly explain it - 513 is outside of 10000-999999 > range, and to make things worse builtin ranges and DOMAIN ranges can not > overlap. > > Our plan now is to use 'domain group' = 10513, but we have very little idea > what problems it can lead to and it will upset a lot of users if we do it > wrong. So here are some questions: > > 1. Along with gidNumber=513 there is Windows internal primaryGroupID=513 > and ordinary users have both attributes set to 513. Should we worry about > that? Our users live in mixed environment and use both Linux and Windows > resources. > 2. We hope that if we change Unix Attribute of 'domain users' to 10513, > than change all files ownerships from group 513 to group 10513 in Linux > world, then it will solve all our problems, but will it?Should do, however you do not have to use 10513, the number just has to be inside the DOMAIN? range you set in smb.conf, for instance I use '10000' getent group Domain\ Users domain users:x:10000: getent passwd rowland rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash The PrimaryGroupID of a user points to the RID of Domain Users, which is 513. Samba uses the PrimaryGroupID to identify the users primary group and this means the group must have a gidNumber attribute.> 3. Or should we create additional 'domain_users_for_unix= 10513) group and > move all users to this group and leave Windows builtin 'domain users' group > intact?You could use another group, if you also have this line in smb.conf: idmap config SAMDOM:unix_primary_group = yes But you will still have to give Domain Users a gidNumber inside the range set in smb.conf Rowland
Rowland penny
2019-Nov-11 21:08 UTC
[Samba] Samba 4.9 + winbind and 'domain users' gidNumber=513 problem
On 11/11/2019 20:34, Alexander Kushnirenko wrote:> ?Hi, Rowland! > Thank you for you comments, everything worked out just fine. > > > Our plan now is to use 'domain group' = 10513, but we have very > little idea > > what problems it can lead to and it will upset a lot of users if > we do it > > wrong.? So here are some questions: > > > > 1. Along with gidNumber=513 there is Windows internal > primaryGroupID=513 > > and ordinary users have both attributes set to 513. Should we > worry about > > that?? Our users live in mixed environment and use both Linux > and Windows > > resources. > > 2. We hope that if we change Unix Attribute of 'domain users' to > 10513, > > than change all files ownerships from group 513 to group 10513 > in Linux > > world, then it will solve all our problems, but will it? > > Should do, however you do not have to use 10513, the number just > has to > be inside the DOMAIN? range you set in smb.conf, for instance I > use '10000' > > getent group Domain\ Users > domain users:x:10000: > > getent passwd rowland > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > The steps included: > 1. Change UNIX attribute of domain user group to 10531 (in our case > 10000 is occupied) > 2. For every user change UNIX Primary group (gidNumber) to 10513 (Did > not find an elegant way for doing that) > 3. For every file in Unix wolrd if it has GID=513 change it to GID=10513 > > And that is it. > > The PrimaryGroupID of a user points to the RID of Domain Users, > which is > 513. Samba uses the PrimaryGroupID to identify the users primary > group > and this means the group must have a gidNumber attribute. > > That I do not quite understand (PrimaryGroupID -> RID -> domainGroup > SID -> domainGroup gidNumber) seems like a long path, as all users > have (shoud have?) gidNumber. >The PrimaryGroupID is designed to be used by Windows, it sets the objects primary group, a users primary group is '513', a computers is '515'. These numbers come from the groups objectSID, which is composed of the DOMAIN SID (S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz) and the unique group RID (513 for Domain Users). Samba uses the users PrimaryGroupID for all Unix users unless: A) you are using the winbind 'ad' backend on a Unix domain member And B) you are using Samba >= 4.6.0 And C) You have 'idmap config DOMAIN : unix_primary_group = yes' set in smb.conf And D) the users have a gidNumber attribute containing the gidNumber of the required group. If all of the above is correct, then the users GID will not be gidNumber set in Domain Users unless the users gidNumber is for Domain Users and if it is, then there is no point in doing the above, because Samba would use the gidNumber for Domain Users without any of the above. To put it another way, if you want all your Unix users to have Domain users as their Unix primary group (same as on Windows), then you do not have to do any of the above. Rowland