On Wed, Oct 16, 2019 at 6:17 PM Jeff Thornsen <jthornsen(a)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
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(a)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
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.