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.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
