[Freeipa-devel] Planning for v2: How to deal with kerberos trusts?

[Simo Sorce]

On Mon, 2008-04-07 at 22:02 +0200, Geert Jansen wrote:
> Hi Simo, List,
> 
> tough questions :) First some things that I do not think we can do. 
> Maybe this will make things clearer:
> 
>  - I do not think we can require posix user names to be unique across 
> trusted realms. To make them unique, we could augment them with the 
> realm (user at realm). However I don't think we can do this either... Some 
> applications break with user names > 8 characters (notably older Oracle 
> versions). It would also break the default aname to lname mapping in 
> Kerberos as that just appends @domain to the posix name.

This is true, and false :-)
In Samba's Winbind we support trusted users and we make them unique
prefixing the trusted domain's short name, and by default even our main
domain has a prefixed name:

example:
WINDOM\user1
WINDOM\user2
TRUSTDOM\user1
etc...

While some very old app may not like it, I think the advantages are
noticeable and we should support a schema like this.
To do that we need of course to have a way to locally resolve the name
so that you can obtain the right kerberos principal name without
actually just appending the domain. This would make it also possible to
handle migrations where you need to keep the uinx user name mapped to
something that does not directly map back to user+domain as krb
principal.

Therefore using user1 at MY.COOL.REALM, could actually be a good idea, and
we may have some configuration option to map (optionally) our own
default account usernames to just the use rpart without the REALM part.
This would also allow us to more freely use real "local" accounts
without fear of clashes, something we can't actually completely avoid.

>  - I do not think we can require numeric user id's to be unique across 
> trusted realms. Here we don't even have an option of prefixing them with 
> something else as our name space is too small.

I think we can handle this case in various ways. True a 32bit id space
is tiny.
But, for planned use of trusted domains we could configure servers so
that they use a 24bit id + 8 bit Realm selector.

For unplanned trusts we could use some realms as a wildcard realm and
just map new user Ids there.
24bit is just 1.6 million user accounts, not much but should still cover
most scenarios for v1 and v2.
It would also mean we cannot support more than 255 trusted realms, but
that again shouldn't be a big deal.

In the long term we have 2 options:
1. we are able to make linux (at least) adopt 64/128 bit user ids
2. we never keep user ids on the directory, but our local daemon instead
maps users on the fly to local uids, and network file systems are made
mapping aware and use an idmapper that plugs into the local daemon.
Both CIFS and NFSv4 can already do this at the protocol level.

> So what is the use case for multiple realms? I can think of a few:
> 
>  - Delegation or administrative duties (user mgmt etc): should be 
> achievable without trusted realms so not an argument.

agree

>  - Privilege separation: yes, as long as local administrators control 
> what privileges are assigned to foreign principals.

This is an interesting point, would you mind expanding on it a bit ?

>  - A merger of two companies (or two independent naming domains): two 
> trusted realms could be useful during the transition period where there 
> is non-unique data across the realms.

For this my proposal above might work.

>  - Performance improvements. I assume there is no or very little 
> synchronization traffic between the trusted realms so you could use this 
> to separate different regions and save on inter-regional bandwidth cost.

I am not sure there is any performance benefit, we would need to analyze
the flux of information, but unless we completely discard foreign users
posix data I am not sure we will have much of a performance benefit.

> So given these the idea that pops to my mind is to use some kind of user 
> mapping process to map foreign principals onto local posix accounts. 

Yep this was one of the ideas I had as well, although I'd like to try to
map users from the trusted domain in the way I described above.

> Essentially, the mapping information should be held in the local realm 
> to ensure proper security separation. Administrators should be able to 
> set up a default mapping such as "guest", and also per-user mappings.

Yes this could be done, I am not sure mapping to a guest user will
actually give any benefit. A 1-1 mapping would probably be more
beneficial, but if we finally decide to go there, we need to talk about
how to do it and how to keep it correctly updated.

Users, also are just one part of the equation, what about group
memberships ?
Would it make sense to consider foreign group memberships at all ?

> Now is this useful, or is this scheme so watered down that it does not 
> give you much value when compared to a single big realm and no user 
> mapping? I think this depends on how many user mappings you will need. 
> If the primary use case is to give foreign users access to data that 
> requires authentication but no authorisation then a single default 
> mapping could suffice and the whole scheme could be quite useful.

Or in case authorization is enforced separately (ex: app server on the
web).

>  If on 
> the other hand every foreign user needs a locally mapped user then maybe 
> there are not many advantages of a single big realm without user mapping.

Yes there aren't many except it enables, mergers, privilege separation
and admin responsibilities.

I think come companies that are split in very separate groups might find
it compelling.

more comments are very welcome, I'd like to analyze pros. and cons. and
even consider hybrid modes or different behaviour given different
configurations.

Simo.

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