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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

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.