[SSSD-users] uid/gid allocation strategy

Nordgren, Bryce L -FS bnordgren at fs.fed.us
Tue Jan 28 20:47:58 UTC 2014


> 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.


More information about the sssd-users mailing list