The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
On 10/17/19 12:17 AM, Jeff Thornsen wrote:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
There is [1]. But I am not sure if it is as thorough as you need and it might be also a little outdated. So the best documentation would be the sources of sss_idmap library [2]. Also it should be possible to use this library instead of implementing your own algorithm.
[1] https://docs.pagure.org/SSSD.sssd/design_pages/idmap_auto_assign_new_slices.... [2] https://github.com/SSSD/sssd/tree/master/src/lib/idmap
On (17/10/19 11:13), Pavel Březina wrote:
On 10/17/19 12:17 AM, Jeff Thornsen wrote:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
There is [1]. But I am not sure if it is as thorough as you need and it might be also a little outdated. So the best documentation would be the sources of sss_idmap library [2]. Also it should be possible to use this library instead of implementing your own algorithm.
+1 for usage of libsss_idmap.so
You might also want to check the man page (sss_rpcidmapd)[3] in case of NFS (it is part of sssd-nfs-idmap on fedora/CentOS)
[1] https://docs.pagure.org/SSSD.sssd/design_pages/idmap_auto_assign_new_slices.... [2] https://github.com/SSSD/sssd/tree/master/src/lib/idmap [3] https://www.mankier.com/5/sss_rpcidmapd
LS
I'm curious about this statement:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments.
What is the alternative?
We have beaucoup (older) storage appliances that (lamentably) each have to run their own usermapper to map between Windows SIDs to UNIX UIDs. It's a pain to maintain all those usermappers on all those NAS heads. We're wanting to migrate them to use the Posix Attributes stored in AD (aka RFC 2307bis). The MS-provided schema extension. Same as sssd on the Linux servers use.
Per-NAS head usermappers seem ideal for a small env, where the AD admin doesn't want to extend the AD schema; not so much for a large env with beaucoup NAS heads.
Spike
On Wed, Oct 16, 2019 at 5:17 PM Jeff Thornsen jthornsen@gmail.com wrote:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Wed, Oct 16, 2019 at 6:17 PM Jeff Thornsen jthornsen@gmail.com wrote:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
We are also waiting for our storage appliance vendor (one of the ones in your list above) to be able to map AD user/group objects without needing the RFC2307 attributes (uidNumber, gidNumber, et. al.).
My suggestion to them was that they don't need to implement the exact mapping algorithms that sssd uses. All they need to do to generate uid/gid values is to use the RID component of the objectSID as an offset from a user-configurable base. Because it's trivial for their customers to determine the correct base to use:
$ echo "$(getent group 'domain users' | cut -d: -f3) 513 - p" | dc
Mapping from a uid/gid back to the SID would consist of subtracting the base and appending it to the non-RID component of the domain SID.
The last time we asked our specific vendor what their ETA was for implementing this feature, alas, their reply was 1-2 years.
In the meantime, we're working on a utility that will read an LDIF dump, and at the cost of a single getgrnam('domain users') call (to determine sssd's offset), will output either a passwd(5) or group(5) file in the same format that sssd would generate, at O(1) cost. Then we will serve up these synthesized passwd/group files for our storage appliance's consumption. It's Rube-Goldberg-esque, but it's the best we can do until our storage appliance vendor finally implements uid/gid auto-mapping from the objectSID.
(We're trying not to reinvent the wheel here, but if someone has already created something like this and made it publicly available, we haven't stumbled across it.)
On Fri, Oct 18, 2019 at 3:03 PM Spike White spikewhitetx@gmail.com wrote:
I'm curious about this statement:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments.
What is the alternative?
Having the appliances calculate uid/gid values from the objectSID, instead of requiring the (uidNumber, gidNumber, et. al.) attributes.
We have beaucoup (older) storage appliances that (lamentably) each have to run their own usermapper to map between Windows SIDs to UNIX UIDs. It's a pain to maintain all those usermappers on all those NAS heads. We're wanting to migrate them to use the Posix Attributes stored in AD (aka RFC 2307bis). The MS-provided schema extension. Same as sssd on the Linux servers use.
It depends on the sssd configuration. If you are using the AD provider, it defaults ldap_id_mapping to true, and thus ignores the uidNumber et. al. attributes in favor of mapping them from the objectSID automatically.
Per-NAS head usermappers seem ideal for a small env, where the AD admin doesn't want to extend the AD schema; not so much for a large env with beaucoup NAS heads.
YMMV, but our experience is the opposite: user/group creation is a tier-1 task, and the simpler we can make it, the better. Avoiding having to maintain (uidNumber, gidNumber, et. al.) attributes for every single AD user and group object that must be visible to AD-joined Linux hosts is a *huge* win.
This is true even though there are growing pains from storage appliance vendors who have yet to awaken to the post-RFC2307 world.
Thanks James for your reply. Glad to discover that I'm not alone when dealing with these storage appliances and their lack of compatibility with sssd's automatic UID/GID mapping.
I believe my plan is to implement a similar Rube-Goldberg that generates a passwd/group file and serves them up over NIS/ypbind on a separate machine on our network to provide uid/gid mapping for the NAS (since at least our storage appliance still supports NIS)
As a follow-up to the discussion below, I have written a utility that synthesizes passwd(5) or group(5) entries from LDIF data, mimicking the entries that sssd produces when sssd is configured to auto-map uid/gid values from the Windows objectSid. It’s available here:
https://github.com/qralston/genent
It works for us in our environment; hopefully others will find it useful as well.
This is the initial release, so it may be buggy. Feedback, pull requests, issues, et. al. are all welcome; please consult the TODO.md file.
On Fri, Oct 25, 2019 at 8:11 PM James Ralston ralston@pobox.com wrote:
On Wed, Oct 16, 2019 at 6:17 PM Jeff Thornsen jthornsen@gmail.com wrote:
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
[We're] working on a utility that will read an LDIF dump, and at the cost of a single getgrnam('domain users') call (to determine sssd's offset), will output either a passwd(5) or group(5) file in the same format that sssd would generate, at O(1) cost. Then we will serve up these synthesized passwd/group files for our storage appliance's consumption. It's Rube-Goldberg-esque, but it's the best we can do until our storage appliance vendor finally implements uid/gid auto-mapping from the objectSID.
sssd-users@lists.fedorahosted.org
-
James Ralston -
Jeff Thornsen -
Lukas Slebodnik -
Pavel Březina -
Spike White