Univention Bugzilla – Bug 32268
Sync Posix ID to Samba4
Last modified: 2020-11-24 12:36:03 CET
To use NFS on MAC OS X it is important to have the same posix id on both the NFS Server as well as on the MAC. Therefore it would be good if the posix ID would be synchronized to Samba 4. Important for Ticket: #2013081321058168
We would need to write uidNumber/gidNumber attributes and add objectClass: posixAccount/posixGroup. If we do this, it's vital that samba idmap is also configured to make use of these rfc2307 attributes. For this the Samba 4 smb.conf offers the parameter "idmap_ldb:use rfc2307" which should then be set to yes. This way the idmap code prefers uidNumber/gidNumber attributes for idmap_xid_to_sid if found in the backend directory. We could also supply the option --use-rfc2307 provision (don't know currently if this does something extra). Note: With 4.1.0 "samba-tool user create" will also offer "--uid-number" etc. which could be used to assign uids conflicting to UDM. Maybe we would need to use an LDB module similar to the one used in UCS@school to pre-allocate/create a UID in UDM on user creation (and similar for <x>idNumber modifications). PS: The samba-tool classicupgrade actually seems to add some extra objects to the directory to make ADUC (+"Server for NIS Tools") detect and show the rfc2307 attributes.
Actually, since we have our samba4-idmap listener taking care if idmap.ldb, it's not really required to have "idmap_ldb:use rfc2307". Forget about that (flashy thing-ed).
(In reply to Arvid Requate from comment #1) > We would need to write uidNumber/gidNumber attributes and add objectClass: > posixAccount/posixGroup. > > If we do this, it's vital that samba idmap is also configured to make use of > these rfc2307 attributes. For this the Samba 4 smb.conf offers the parameter > "idmap_ldb:use rfc2307" which should then be set to yes. This way the idmap > code prefers uidNumber/gidNumber attributes for idmap_xid_to_sid if found in > the backend directory. We could also supply the option --use-rfc2307 > provision (don't know currently if this does something extra). [..] > > PS: The samba-tool classicupgrade actually seems to add some extra objects > to the directory to make ADUC (+"Server for NIS Tools") detect and show the > rfc2307 attributes. The customer reported that accounts generated by a samba3-migration have a correct posixAccount, later created accounts not. That seems to work with the current idmap-configuration?
Yes, reportedly the samba-tool classicupgrade sets the attributes for the migrated accounts. The S4 Connector doesn't do this yet for new accounts, but idmapping stuff works in both cases, see Comment 2.
(In reply to Kevin Dominik Korte from comment #0) > To use NFS on MAC OS X it is important to have the same posix id on both the > NFS Server as well as on the MAC. Therefore it would be good if the posix ID > would be synchronized to Samba 4. Why not use CIFS?
Requested via Ticket#2014102921000381
also requested in http://forum.univention.de/viewtopic.php?t=3568
Also Ticket#2015011921000217, but slightly different scenario: * MS AD with Unix Attributes (uidNumber, gidNumber ...) * AD Takeover with UCS/S4 * Feature Request: During Takeover create the accounts in S4 and OpenLDAP with the same UID/GID than they had in the MS AD
This was requested again during an expert talk today by several people. Main scenario is OS X and NFS shares.
This issue has been filed against UCS 3.1. UCS 3.1 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please reopen.
I reopen this one because it's also valid for UCS 4.1. I recently talked to ... a) one customer who joined their Suse Desktops via YaST against the Samba/AD domain. They hit the same problem: the local UID/GID do not match those in the UCS domain and therefore they can't use NFS shares and some custom application that tries to find the local user via their UID in the OpenLDAP. b) a partner who wanted to use 'realmd' to join Ubuntu clients to the Samba/AD domain because they experienced problems with our documentation on how to join Ubuntu clients. Again, they were not able to use NFS shares. I still think it would be great if we would make this possible.
What is the problem with this bug/request? I don't see any. There is at least no technical problem. You have to add some lines to the S4 connecter. I've done this more than once. Thats it. Are there political reasons not to sync these IDs? If you start to fix it, what about other attributes: jpegPhoto, phone, fax and room numbers, addresses, (Birthdays?), ...; everything you find attributes in the standard AD schema.
No, we don't have any political reasons. There are only more requests than time. That's the reason why we close old bug requests from time to time. If we add these attributes, we have to check the first sync order to ensure we don't delete the values.
Requesting during workshop today. Scenario are Linux based systems that connect to Samba/AD via sssd. (sssd is configured to use the 'memberOf' attribute for access restriction)
Created attachment 8217 [details] s4connector-rfc2307.patch This might be sufficient.
I think what is missing here is the full availability to be rfc2307 compliant. It doesn't help to only enable uidNumber and gidNumber in ldap.
Ok, we could also synchronize unixHomeDirectory (Bug #40270) and loginShell., see also https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
Hi Arvid, Yes, this would be perfect and I think enough for Unix clients. I didn't knew that it will be removed from Srv 2016, sad :-(
> I didn't knew that it will be removed from Srv 2016, sad :-( Oh, that's a misunderstanding, the MS blog says that the attributes will remain part of the schema: "Active Directory does not remove the populated UID/GID Active Directory attributes during the upgrade to Windows Server 2016".
I have been able to get it to work on my UCS domain: See here for some details: https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD The link to ypServ30.ldif is not included in UCS though, I got it from here: https://github.com/samba-team/samba/blob/master/source4/setup/ypServ30.ldif That creates the schema in Samba for Unix extensions at least, I didn't do any of the configuration changes that it says (the only change would be idmap_ldb:use rfc2307 = yes) because I didn't want to screw anything up. Then I just have to do the following to the Samba domain every time I create a user: dn: cn=username,cn=users,dc=my,dc=domain,dc=edu changetype: modify add: objectClass objectClass: posixAccount - add: uid uid: username - add: uidNumber uidNumber: 1234 - add: gidNumber gidNumber: 1234 - add: loginShell loginShell: /bin/bash ldapmodify -x -H ldap://master-samba.my.domain.edu -Z -D 'cn=Administrator,cn=users,dc=my,dc=domain,dc=edu' -w password -f user.ldif To highlight, it adds the posixAccount object class to the user which the schema requires you to set uid, uidNumber and gidNumber (perhaps even loginShell). The rest of the items (such as Unix/NFS homeDirectory) are already in the regular schema. Since none of the above change, I really don't care (much/ever) about syncing them between the LDAP/Samba at this point. I've wrapped it all up in my user creation script. In Mac OS X, you then create the AD connection and set the following (either through GUI or dsconfigad) Advanced Options - Mappings Mapping UID to attribute = uidNumber Mapping user GID to attribute = gidNumber Mapping group GID to attribute = gidNumber That makes it work perfectly with FreeNAS, Solaris, Linux etc.
There are different aspects to this topic 1. Synchronizing the Posix IDs to Samba/AD (this bug) 2. Make Samba *read* these rfc2307 attributes * on a DC : set "idmap_ldb:use rfc2307 = yes" in smb.conf Note: with this Samba still needs the idmap.ldb to allocate unknown IDs * on a member: configure idmap_ad 3. Making them visible/editable in MS ADUC by adding ypServ30.ldif This bug is about point 1.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
This will be implemented by Bug #49092