> In the default case IPA, will automatically allocate a non conflicting range > to > AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix > Ids stored in AD then yes, you will have to take care manually to avoid > conflicts.
A perhaps doable, more applied thesis still requiring a substantial bit of work: Posit a successful collaboration ecosystem that organizations are free to join or leave at will. Each realm must be free to use UID/GID of their choice without coordinating with all potential collaborators. The combination of UIDs/GIDs presented to individual machines still must not collide. I think this could happen in IPA, assuming that all local machines and services authenticate with Kerberos. IPA would have to allocate a "foreign principal" record whenever the KDC was presented with a cross-realm TGT for a local service from a "new" foreign client (that may be tricky). IPA could manage the UID space for its own realm. Sssd would no longer need multiple realm entries and all relevant "id_provider" info could be synthesized at the realm level by IPA. Effectively, the unique identifier for all external principles is username@REALM, with all the previously mentioned renaming problems. Local principals have their numeric id. But admins still shouldn't rename principals because they will cause problems for their collaborators. Or, each machine could do it. It's a matter of deciding what the integration point is for cross-realm operation. That's pretty well defined for Kerberos (the KDC), and for the id provider (sssd). Trouble is, they're different integration points. > Actually the solution to avoid capaths on clients is already planned, and it > is to > stop having clients try to discover topology on their own at all. Clients > should > always communicate with their KDC, and the KDC will issue referrals as > appropriate. Once you do this capaths can be dismantled for the clients, the > KDC will care for handling topology information. I take it this is a reading assignment for RFC6806. :) I shall dive in. > One small problem remains: how do I find the KDC if the realm name of the > realm does not match the DNS domain name ? That is something that can be, > perhaps resolved with some additional PA-DATA on the referrals if there is > no other way. Yeah. Also, the DNS domain name of a service may not match the DNS domain name of it's home KDC... 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. _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
