[Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Simo Sorce]

On Mon, 2014-03-10 at 23:06 +0000, Nordgren, Bryce L -FS wrote:
> 
> > 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.

This is what we basically do with AD trusts if you do not configure the
trust to go and fetch Posix Ids from AD and is the default case :-)

I see no problem doing the same with another IPA trusts once we have
such a thing.

> Effectively, the unique identifier for all external principles is
> username at REALM, with all the previously mentioned renaming problems.

Not necessarily we can do algorithmic mapping (like we do for SID->UID
with AD trusts) and maintain the foreign ID as the actual identifier.

>  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.
> 
Well for IPA it will not be a big deal, once we offocially support
trusts these trusts will be sssd subdomains and the configuration is
fetched from IPA.

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

Indeed.

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

That's not a problem, just a capath routing.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York