> 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 

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


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

Reply via email to