> In the default case IPA, will automatically allocate a non conflicting range
> 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
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
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
> 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
> 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...
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
Freeipa-users mailing list