On Sun, 30 Mar 2014, Nordgren, Bryce L -FS wrote:
Hey guys,

Back again. Thanks for your responses so far.

OTP is interesting, but requires that an account be created in the
local domain, which is kind of opposed to the notion of federated

Ipsilon is also interesting, from its description as a gateway to
non-Kerberos identitiy providers. I have not located much information
about it, though.

I've taken a couple of days to put together an RFE with three use cases
and tons of pictures. It locally maintains user attributes in LDAP
without creating a corresponding authentication principal in Kerberos.
It offers a little more flexibility for integrating AD users to an IPA
managed POSIX realm without conflicting with the existing method. It
also makes possible the management of inter-organizational cross realm
operation using PKINIT. Finally, it describes an interface between the
IPA server and Ipsilon (or any identity gateway), and a mechanism by
which Ipsilon may acquire TGTs for the local realm on behalf of clients
who authenticate via remote, non-Kerberos identity providers. This last
workflow is generic and supports methods other than a web-browser.

Please take a look and help me improve it. Also pls educate me out of
any mistakes you detect. Part of the reason for doing this is for me to
make sure I learned Kerberos concepts correctly.

Thanks for the writeup.
I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.

FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself
a non-trivial task.

Provisioning of an external user's account in LDAP in a separate OU
does not change anything from what we already would do for creating
accounts for external users on the fly, in standard users tree, and
putting them into a specific group set.

However, provisioning users in a separate OU would also mean changing
many of other functional modules to add awareness of those OUs. HBAC,
for example, needs changes on both server and client (SSSD) side. Client
side changes to properly recognize DNs of external users from a
separate OU when resolving HBAC rules will need to be distributed to all
IPA clients, including those where upgrade of the software is not
possible due to a customer constraints. Re-using existing mechanisms has
own advantages of not changing the client side.

PKINIT use in Kerberos is a big issue. Right now certificates produced
by FreeIPA do not include special extension that Kerberos KDC requires
to have PKINIT working. We have a ticket to solve this but it depends on
few items missing in FreeIPA, Dogtag, and nss. Solving it is required
for full OTP use, so we might gain this feature sooner or later.

I would generally not recommend both diminishing or relying too much on
existing RFCs for certain LDAP storage schema proposals, specifically
for Kerberos. These have little value outside of specific Kerberos KDC
backend utilizing them. We have already our own schema, specific enough
for FreeIPA and we are going to continue using it, regardless how
'expired' or new certain RFCs. There is simply no universal agreement
here and no need for it, actually.

What's reasonable and can be relatively easily pulled in from your
proposal is a mechanism to get users automatically provisioned in
FreeIPA based on their cross realm identities. For example, for cross
realm trust with AD we have means to selectively block certain SIDs from
being imported from the AD. The rest is recognized and accepted but no
local external groups created for them. We simply can automate creating
the groups on login attempt if SIDs involved aren't blocked. This
automation should solve majority of administrative load.

/ Alexander Bokovoy

Freeipa-users mailing list

Reply via email to