6:36 p.m.
Can sssd allocate uid/gid out of a pool unique to each domain? The mapping need not be
complex: "last_allocated+1" should suffice.
I'm motivated to ask the following question because I "supplement" our
official active directory with accounts for external partners/collaborators. Numeric
uid/gid fields could well collide because there's no coordination, nor is there likely
to be. In the long term, we'd like to fix that, and we'd like to convince our
powers-that-be that joining one or more larger "identity federations" is in
their best interest. But that puts us right back where we started, as uid/gids across
several large, mostly disconnected organizations are not going to be coordinated.
So: What reasons still exist to insist on coordination? Are we ready to make the leap to
coordinating the set of text-based-principals which are valid within a domain?
File sharing via NFS with "sec=sys" is just about the only obstruction I can
think of. Otherwise, uid/gids are local to each machine, and it is sufficient to allow
each machine to perform its own unique mapping from "valid username" to uid.
So if I either prohibit NFS entirely or insist on "sec=krb5", could I have a
gaggle of linux boxes which individually allocate uids and gids as they encounter valid
Kerberos credentials?
Sorry for wandering into the abstract there...this seemed an appropriate venue for
determining whether such a scheme was viable.
Bryce
This electronic message contains information generated by the USDA solely for the intended
recipients. Any unauthorized interception of this message or the use or disclosure of the
information it contains may violate the law and subject the violator to civil or criminal
penalties. If you believe you have received this message in error, please notify the
sender and delete the email immediately.
2:37 a.m.
On Tue, Jan 28, 2014 at 12:36:09AM +0000, Nordgren, Bryce L -FS wrote:
Can sssd allocate uid/gid out of a pool unique to each domain? The
mapping need not be complex: "last_allocated+1" should suffice.
SSSD supports a simple mapping based on the RIDs of the users and
groups. You can find details in the sssd-ad man page in the 'ID MAPPING'
section. Does this scheme work for you?
HTH
bye,
Sumit
I'm motivated to ask the following question because I "supplement" our
official active directory with accounts for external partners/collaborators. Numeric
uid/gid fields could well collide because there's no coordination, nor is there likely
to be. In the long term, we'd like to fix that, and we'd like to convince our
powers-that-be that joining one or more larger "identity federations" is in
their best interest. But that puts us right back where we started, as uid/gids across
several large, mostly disconnected organizations are not going to be coordinated.
So: What reasons still exist to insist on coordination? Are we ready to make the leap to
coordinating the set of text-based-principals which are valid within a domain?
File sharing via NFS with "sec=sys" is just about the only obstruction I can
think of. Otherwise, uid/gids are local to each machine, and it is sufficient to allow
each machine to perform its own unique mapping from "valid username" to uid.
So if I either prohibit NFS entirely or insist on "sec=krb5", could I have a
gaggle of linux boxes which individually allocate uids and gids as they encounter valid
Kerberos credentials?
Sorry for wandering into the abstract there...this seemed an appropriate venue for
determining whether such a scheme was viable.
Bryce
This electronic message contains information generated by the USDA solely for the
intended recipients. Any unauthorized interception of this message or the use or
disclosure of the information it contains may violate the law and subject the violator to
civil or criminal penalties. If you believe you have received this message in error,
please notify the sender and delete the email immediately.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
12:18 p.m.
On 01/28/2014 03:37 AM, Sumit Bose wrote:
On Tue, Jan 28, 2014 at 12:36:09AM +0000, Nordgren, Bryce L -FS
wrote:
> Can sssd allocate uid/gid out of a pool unique to each domain? The mapping need not
be complex: "last_allocated+1" should suffice.
SSSD supports a simple mapping based on the RIDs of the users and
groups. You can find details in the sssd-ad man page in the 'ID MAPPING'
section. Does this scheme work for you?
HTH
bye,
Sumit
> I'm motivated to ask the following question because I "supplement" our
official active directory with accounts for external partners/collaborators. Numeric
uid/gid fields could well collide because there's no coordination, nor is there likely
to be. In the long term, we'd like to fix that, and we'd like to convince our
powers-that-be that joining one or more larger "identity federations" is in
their best interest. But that puts us right back where we started, as uid/gids across
several large, mostly disconnected organizations are not going to be coordinated.
>
> So: What reasons still exist to insist on coordination? Are we ready to make the leap
to coordinating the set of text-based-principals which are valid within a domain?
>
> File sharing via NFS with "sec=sys" is just about the only obstruction I
can think of. Otherwise, uid/gids are local to each machine, and it is sufficient to allow
each machine to perform its own unique mapping from "valid username" to uid.
>
> So if I either prohibit NFS entirely or insist on "sec=krb5", could I have
a gaggle of linux boxes which individually allocate uids and gids as they encounter valid
Kerberos credentials?
>
> Sorry for wandering into the abstract there...this seemed an appropriate venue for
determining whether such a scheme was viable.
>
> Bryce
>
>
>
>
> This electronic message contains information generated by the USDA solely for the
intended recipients. Any unauthorized interception of this message or the use or
disclosure of the information it contains may violate the law and subject the violator to
civil or criminal penalties. If you believe you have received this message in error,
please notify the sender and delete the email immediately.
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
You also may consider bringing FreeIPA to manage you Linux boxed and
provide uid/gid data while users from AD would come via trust or sync.
Have you looked at this avenue?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
2:47 p.m.
On 01/28/2014 03:37 AM, Sumit Bose wrote:
> On Tue, Jan 28, 2014 at 12:36:09AM +0000, Nordgren, Bryce L -FS wrote:
>> Can sssd allocate uid/gid out of a pool unique to each domain? The
mapping need not be complex: "last_allocated+1" should suffice.
> SSSD supports a simple mapping based on the RIDs of the users and
> groups. You can find details in the sssd-ad man page in the 'ID MAPPING'
> section. Does this scheme work for you?
I'll try it out. Conceptually, it should work. Our AD has uidNumbers, but no
gidNumbers, prompting the need to override or map. I'm a little confused as to why
this is a per-domain configuration item. Surely the definition of the slices must be the
same for all domains configured for one instance of sssd....And why does the configuration
section for a single domain define slices for 10000 domains by default?
I'm a little unclear from the description. Does an sssd "slice" maintain
separate allocation pools for uids and gids (e.g., a user can have the same numeric id as
a group), or is there a common pool from which both ids are drawn (e.g., a user can never
have the same is as a group)?
You also may consider bringing FreeIPA to manage you Linux boxed
and
provide uid/gid data while users from AD would come via trust or sync.
Have you looked at this avenue?
For the immediate term, I have:
* AD with uidNumber but no gidNumber.
* 389ds with external accounts
** all of which are inetOrgPerson (identities for web apps)
** some of which are also posixAccounts (identities for linux sftp/scp/login/etc.)
** none of which have an objectSID
If I understand correctly, I can "id-map" from AD, but not from my 389ds
directory (I lack an objectSID). So as long as I know my own uid/gid window, I can define
the AD window such that it does not conflict. So, I think the immediate term needs are
met.
I am considering FreeIPA/IdM for a longer term scenario (September-ish). It seems like
it’s the direction I should move in, but I'll have to find the time to migrate off of
what's working right now. (This started as a webapp identity solution and is starting
to grow into a file-sharing and/or login identity solution.) My objectives would be:
* client machines ignore uidNumbers/gidNumbers from all sources, performing their own
unique local mapping
* my directory does not need uidNumbers, and so I don't need to manually manage them
* file sharing is via some technology that does not use numeric ids (sftp, scp, sshfs,
webdav, NFSv4 w/sec=krb5)
* don't run services which require multi-machine id number coordination
The reason that ignoring uidNumbers/gidNumbers is a long term goal is that this is
intended to be a loosely federated environment, aligned with the vision of the rebooted
PKCROSS ietf draft. Numeric user ids from other organizations may collide, whereas the
identities themselves won't. I'd consider the ability to arbitrarily remap
uidNumber/gidNumber as an enabling technology for agile federation.
...so it seems that sssd does not at this moment support arbitrary remapping, but it also
seems that the barrier to doing so is relatively low. Another (simple) algorithm is
required, and another option similar to ldap_idmap_autorid_compat. The only requirement is
that AD-specific data cannot be used by the algorithm.
Is this something that would be entertained as an RFE on your trac instance?
Thanks,
Bryce
This electronic message contains information generated by the USDA solely for the intended
recipients. Any unauthorized interception of this message or the use or disclosure of the
information it contains may violate the law and subject the violator to civil or criminal
penalties. If you believe you have received this message in error, please notify the
sender and delete the email immediately.
3734
days inactive
3734
days old
sssd-users@lists.fedorahosted.org
3 comments
3 participants
participants (3)
-
Dmitri Pal -
Nordgren, Bryce L -FS -
Sumit Bose