Hi, we are in the process of testing a migration from our NT Classic Domain with OpenLdap to Samba AD. In our test setup migration of all accounts, groups and computer accounts went well using the classicupgrade path. Next step now is testing how to add a member server for file server services. We were able to get the server to join the domain and also idmapping works mostly as expected. If we use getent group everything works as expected and we get the correct group with the correct GID: root at fileserv2:~# getent group SOMEDOM\\stas SOMEDOM\stas:x:10165: We can use getent passwd and wbinfo -i fine for all our ldap created users and get the correct UID/GID if we are using the config: idmap config SOMEDOM:unix_primary_group = yes root at fileserv2:~# getent passwd SOMEDOM\\test.zweimal SOMEDOM\test.zweimal:*:10409:10000::/home/test.zweimal:/bin/false root at fileserv2:~# wbinfo -i SOMEDOM\\test.zweimal SOMEDOM\test.zweimal:*:10409:10000::/home/test.zweimal:/bin/false 10000 is the default GID we were using in ldap for all of our users. If we remove this line we won't get any output as the primary group then will be 513 which is the default windows sid for "Domain Users" and as the mapping only starts at 10000 there is no mapping to find for winbind. So far so good and we can live perfectly having the line above in our config to make this work. But we still cannot get the info for "Domain Users" & "Domain Admins" as they still have the SID 513 & 512. If we change the groups GID in AD using the ADUC tool to 10513 & 10512 we are able to get the info out of wbinfo & getent passwd but I guess this is not the way to do it properly? root at fileserv2:~# getent group "SOMEDOM\\Domain Users" SOMEDOM\domain users:x:10513: root at fileserv2:~# getent group SOMEDOM\\Domain Admins" SOMEDOM\domain admins:x:10512: Can someone shed some light on this or maybe I just have some kind of misunderstanding of the concept. The RID backend will not be an option for us as we will have multiple domains we need to trust and as far as i understood this is not possible with RID. The following smb.conf is used on the member server: [global] netbios name = FILESERV2 workgroup = SOMEDOM security = ADS realm = AD.SOMEDOM.COM idmap config *:backend = tdb idmap config *:range = 3000-7999 idmap config SOMEDOM:backend = ad idmap config SOMEDOM:schema_mode = rfc2307 idmap config SOMEDOM:range = 10000-999999 idmap config SOMEDOM:unix_nss_info = yes idmap config SOMEDOM:unix_primary_group = yes winbind enum users = yes winbind enum groups = yes vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes Best, Kai
On Wed, 13 Feb 2019 16:23:10 +0100 Kai Noetzel via samba <samba at lists.samba.org> wrote:> Hi, > > we are in the process of testing a migration from our NT Classic > Domain with OpenLdap to Samba AD. > > In our test setup migration of all accounts, groups and computer > accounts went well using the classicupgrade path. > Next step now is testing how to add a member server for file server > services. > > We were able to get the server to join the domain and also idmapping > works mostly as expected. > > If we use getent group everything works as expected and we get the > correct group with the correct GID: > > root at fileserv2:~# getent group SOMEDOM\\stas > SOMEDOM\stas:x:10165: > > We can use getent passwd and wbinfo -i fine for all our ldap created > users and get the correct UID/GID if we are using the config: > idmap config SOMEDOM:unix_primary_group = yesHave you got any Windows machines ? I ask this because using 'idmap config SOMEDOM:unix_primary_group yes' only works locally on the Unix computers, if you connect via Samba, 'Domain Users' WILL be used.> > root at fileserv2:~# getent passwd SOMEDOM\\test.zweimal > SOMEDOM\test.zweimal:*:10409:10000::/home/test.zweimal:/bin/false > root at fileserv2:~# wbinfo -i SOMEDOM\\test.zweimal > SOMEDOM\test.zweimal:*:10409:10000::/home/test.zweimal:/bin/false > > 10000 is the default GID we were using in ldap for all of our users.Funny so is mine, but my group is Domain Users.> > If we remove this line we won't get any output as the primary group > then will be 513 which is the default windows sid for "Domain Users" > and as the mapping only starts at 10000 there is no mapping to find > for winbind.Ah, this was one of those ideas that was thought to be a good idea once, 'Lets use the RID for the gidNumber', time has shown this was a bad idea ;-)> > So far so good and we can live perfectly having the line above in our > config to make this work. But we still cannot get the info for > "Domain Users" & "Domain Admins" as they still have the SID 513 & 512. > > If we change the groups GID in AD using the ADUC tool to 10513 & > 10512 we are able to get the info out of wbinfo & getent passwd but I > guess this is not the way to do it properly?It is actually, either that or set the lower DOMAIN range to '500', the problem with that, you cannot have ANY local Unix users & groups.> > root at fileserv2:~# getent group "SOMEDOM\\Domain Users" > SOMEDOM\domain users:x:10513: > root at fileserv2:~# getent group SOMEDOM\\Domain Admins" > SOMEDOM\domain admins:x:10512: > > Can someone shed some light on this or maybe I just have some kind of > misunderstanding of the concept. The RID backend will not be an > option for us as we will have multiple domains we need to trust and > as far as i understood this is not possible with RID.It is actually, you set the different domains to have different ranges.> > The following smb.conf is used on the member server: > > [global] > netbios name = FILESERV2 > workgroup = SOMEDOM > security = ADS > realm = AD.SOMEDOM.COM > > idmap config *:backend = tdb > idmap config *:range = 3000-7999 > idmap config SOMEDOM:backend = ad > idmap config SOMEDOM:schema_mode = rfc2307 > idmap config SOMEDOM:range = 10000-999999 > idmap config SOMEDOM:unix_nss_info = yes > idmap config SOMEDOM:unix_primary_group = yesI see you read the wiki ;-)> > winbind enum users = yes > winbind enum groups = yesOnce you are sure everything is running OK, remove the two lines above. Rowland
In addition to Rowland's. And be aware that there is a bug in unix_primary_group = You only see 10000 or Domain Users. If you change the primary groep to something else, it stays 10000/Domain users. See: default group always set to "Domain Users" not evaluating PrimaryGroupID ldap attribute https://bugzilla.samba.org/show_bug.cgi?id=13371 And You know that you have to set the UID/GID's yourself? https://wiki.samba.org/index.php/User_and_group_management https://wiki.samba.org/index.php/Maintaining_Unix_Attributes_in_AD_using_ADUC Greetz, Louis
On Wed, 13 Feb 2019 17:26:05 +0100 "L.P.H. van Belle via samba" <samba at lists.samba.org> wrote:> In addition to Rowland's. > > And be aware that there is a bug in > > unix_primary_group = > You only see 10000 or Domain Users. > If you change the primary groep to something else, it stays > 10000/Domain users. > > See: > default group always set to "Domain Users" not evaluating > PrimaryGroupID ldap attribute > https://bugzilla.samba.org/show_bug.cgi?id=13371 > > > And > You know that you have to set the UID/GID's yourself? > https://wiki.samba.org/index.php/User_and_group_management > > https://wiki.samba.org/index.php/Maintaining_Unix_Attributes_in_AD_using_ADUC > > > Greetz, > > Louis > >This isn't in my opinion a bug ;-) Lets start with a Unix domain member that as 'unix_primary_group = yes' set: rowland at devstation:~/mate$ getent passwd usertest usertest:*:10007:10001:User Test:/dev/null:/bin/bash Here we can see that user 'usertest' has the group ID '10001', this is the ID for a Unix group stored in AD. Now we will go to a DC: root at dc4:~# getent passwd usertest SAMDOM\usertest:*:10007:10000::/home/usertest:/bin/bash The group ID is now '10000' and this is the gidNumber for 'Domain Users' Finally, a Unix domain member using the 'rid' backend adminuser at Computer4:~$ getent passwd usertest usertest:*:11112:10513::/home/usertest:/bin/bash The group id is now '10513', this is the RID for 'Domain Users' plus the low range set in smb.conf, this is '10000' So, one user, three group ID's So, why do I not think it is a bug ? If somebody logs into 'devstation' and has a gidNumber, they will get the Unix primary group. If somebody connects to a share, they are either connecting from a Windows machine or a Samba machine that is 'simulating' a Windows machine. In this case, Windows expects the users Primary group to be Domain Users. In my opinion, you either never use the same username from a Windows machine and Unix machines, or you always use 'Domain Users' as the users primary group. Rowland