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

[Simo Sorce]

On Sun, 2014-03-09 at 01:28 +0000, Nordgren, Bryce L -FS wrote:
> IPA supplements (or hopefully will supplement) AD in my environment. I
> need to worry about colliding with UIDs in a directory I don't
> control. IPA can't solve this problem for me. Neither can my current
> LDAP solution. But machines which could generate their own
> mappings...many headaches would go away.

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.

> The renaming thing you brought up (within a non-UID/SID-sharing
> environment) sounds like it could be a good thesis topic. "Going
> forward" probably means starting to use NFSv4, which also warns
> against renaming because it doesn’t use UID/SIDs. It sounds like a
> necessary and present issue to address.

Well, once you make the fully qualified name (user at realm) your unique
identifier, renaming becomes pretty much impossibile, except at great
pains (like having a 'synchronized' service that maps new name to old
name and banning reuse of the old unique name for any future user).

Efficiently transmitting group information also becomes a challenge, but
we may decide not to care about performance :)

> Assembling a functional realm containing only platform-independent
> principals (could include groups, not GIDs), by extending the NFS
> idmapper could be another. (Or at least ensuring that the POSIX
> mappings and NFS mappings are the same...) Try the same thing on
> Windows and see what the showstoppers are. Success may simplify
> integration of Windows into IPA managed domains if you didn't have to
> emulate an AD instance so completely. Home users everywhere may love
> being able to make all their machines have the same password via a KDC
> (or IPA?) running on their wireless router.

Unfortunately that is not really in our hands, Microsoft tied windows
clients to AD, so only Microsoft can provide 'simpler' interfaces and
let the client remain fully functional.

> If you're tired of this topic, how about a thesis which makes Kerberos
> KDCs function more like IP routers, collaboratively and automatically
> maintaining the connectivity topology between Kerberos realms?

Well there are some proposal, but a thesis on this that summarize the
problem and possible solution seem a really interesting topic for a
bright student. 

>  Clearly, its not the same: cross-realm connectivity (I will NOT use
> the word "trust") is inherently unidirectional. Also, the mapping from
> realm->dns and specific fqdns for the KDCs will need to be
> communicated.

Indeed we had to implement MS interfaces in IPA to communicate topology
back and forth. Unfortunately 'trust' is a word you have to use any time
you want to communicate information, either you trust the source or have
a way to verify it is truthful ... by trusting something else :-)

>  The KDC could potentially communicate this topology to interested
> clients, but why on earth would the clients want to know? IP routers
> made UUCP bang paths obsolete, something should do the same for
> Kerberos capaths.

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


But let me say I am not at all against having thesis' that explore some
of these theoretical questions, however one need to understand that the
deliverable may end up being something that cannot be implemented or
that it would require a long time to do so. As long as that is clear
everything is game.

Simo.

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