[Freeipa-users] External Collaboration Domains

Tue Apr 8 13:42:30 UTC 2014

On 04/08/2014 09:34 AM, Alexander Bokovoy wrote:
> On Sun, 30 Mar 2014, Dmitri Pal wrote:
>> On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote:
>>>> 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.
>>>
>>
>>
>> Wow!
>> First of all thanks for a nice pictures and sharing your ideas.
>> A lot of work and though put into it.
>>
>> Let me just point couple things:
>> 1) It looks like the whole idea is about creating entries for 
>> external users on the server when external user authenticates via 
>> KDC. But don't we already lookup cache these users in a local SSSD 
>> cache and expose via the compat tree for legacy clients?
>> AFAIU the purpose is to be able to create local groups for the 
>> external users. May be we can do something and use compat tree DNs 
>> for external users?
>> In general it is better to distill the problem we are trying to 
>> solve: did I get it right?
>>
>> 2) I think PKINIT and related part of the proposal is not something 
>> that we would do.
>> Instead of PKI based Ipsilon would use GSS proxy that implements 
>> s4u2proxy + s4u2self to acquire a ticket on user behalf.
>> This functionality already exists, so there is no new code need.
>>
>> 3) The case when you send TGT back to the client from Ipsilon that 
>> authenticated user and acquired TGT on his behalf is an interesting 
>> one. The intent for client to later use SSH is understandable though 
>> hard to achieve. Currently there is no mechanism for Ipsilon or 
>> Ipsilon like gateways to return the TGT for a user and pass it to 
>> client browser. There is also no way a browser can save this TGT in 
>> the cache.
>>
>> Bottom line:
>> Let us focus on the problem we are trying to solve here. Keep in mind 
>> that we have not started designing IPA to IPA trusts and Kerberos to 
>> IPA trusts. It might very well be that we would need to create some 
>> external entries for those trusts so IMO looking into these trust 
>> scenarios would reveal where our AD integration approach lacks 
>> external info and needs to be extended. If we want to solve the high 
>> level problem of trusts in general we need to build those specific 
>> flows and see what data is not in ldap and we can get it there. A 
>> simple mental exercise  suggests that we would need something for 
>> grouping of the identities coming from a vanilla trusted Kerberos 
>> domain. May be this is something we should drill down as a next step?
> Now we have this tracked with the ticket
> https://fedorahosted.org/freeipa/ticket/4287
>
>
> Bryce, please continue expanding on your potential use cases using the
> wiki page you've created. I'm not sure we are even close to start
> implementing this but gathering the information is a first step.
>
> I think Dmitri has some valid questions above that might be good to
> answer through your wiki page.
>
And may be we can start smaller. Can we have a concise definition of the 
speific problem we are trying to solve here.
May be there are different ways to solve it other than auto creating 
records.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.