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

Ah. Well since that's the case, separate OUs are gone. (You may have to hit 
"reload" in your browser to get the new figure.) It does require that the RDN 
of all external entities encode both the name and the realm of the external 
Kerberos principal in order to avoid collisions. Is the current "external user" 
provisioning method able to handle the same name coming from two domains or 
does it assume that collisions will never happen?

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

The proposal actually doesn't involve producing kx509 certificates, only 
consuming them. :) I think these are two issues which can be handled in 
parallel rather than having one block the other. ;)

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

>From my cursory examination of the code, I proposed auditing the KDC's AS and 
>TGS conversations to trigger this automatic provisioning. Is this an approach 
>worth keeping?

I understand that IPA's bread and butter is to attach itself to a pre existing 
AD domain to simplify the administration of Linux machines within the same 
administrative boundaries.  This is a subset of Use Case 1. I just want to make 
sure that there's a plan in place for situations where the domain of origin is 
not AD, and no SID is exported  (the rest of Use Case 1, and Use Cases 2 & 3.) 
This is just a generalization of the procedure to allow "AD" users access to 
services such that users from non-AD realms can also be included.

Use Case 1 could be named "Intra-organizational cross-realm operation", Use 
Case 2 could be named "Inter-organizational cross realm operation", and Use 
Case 3 could be named "Multi-technology cross-realm operation". 2&3 involve 
independent administrative entities with a fair amount of autonomy. Traditional 
enterprise approaches are not valid for 2&3. :)

Thanks for the review!
Bryce






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


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to