On Wed, Oct 16, 2019 at 6:17 PM Jeff Thornsen <jthorn...@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 <spikewhit...@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.
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org
