On 03/23/2014 06:59 PM, Nordgren, Bryce L -FS wrote:
I’m not, in general, in favor of solutions which promiscuously sling
Kerberos passwords around the net. JpGina + Kerberos authenticating
directly off of IPA would be the way to go, I think.
Presumably Dimitri’s statement about the user being “foreign” and
having limited access to windows services would apply equally well to
a user with a SID from a foreign domain in a large Kerberos
federation. This, and the uncertainty concerning what type of
directory service the foreign KDC is paired with, is probably
responsible for keeping Kerberos-based federations small.
If you have a SID you can tell Windows what t odo with it and how to
resolve it to name. If you do not have one you can't do anything if you
accessing elements of the Windows infra.
That being said, the collaboration use case (not to mention “home
networks”) is what makes “foreign” logins interesting. There’s hardly
anything in common between two collaboration projects, so it’s hard to
define far-reaching policies (i.e., you’re not missing out on much).
Most all authorization decisions are delegated out to some project
member responsible for the server/asset. Constructing authorization
sets having members defined by text based principals makes a certain
amount of sense. Hence the LDAP “member” attribute in RFC4519.
Collaboration can be in different ways. It all depends on the use case.
It can be OpenID, SAML, Kerberos, etc. There are different technologies
and they suit better different use cases.
What would really be cool is the “inverse” of gluu or openam. Kerberos
preauthentication data which allows the KDC to authenticate off of an
OpenID Connect, SAML, or LDAP authentication source, caching the
provided password and provisioning a Kerberos principal. Future AS
exchanges would start out as “normal” Kerberos. Sort of like migration
mode does now. If the KDC could then signal IPA that a new principal
was provisioned, IPA could allocate and harmonize an SID and a UID for
the principal in the domain.
It is already to some extend possible. It is called "constrained
delegation". The problem is that the gateway that would do such protocol
conversion would be able to impersonate any user in the Kerberos realm.
This is not the best but since it is being asked we are looking into it.
There is a project called Ipsilon
https://git.fedorahosted.org/git/ipsilon that is building the way of
federating different applications via SAML but in future it might be
extended to the workflows you are talking about here though I am not
sure I met these use cases in practice. Can you please share under what
circumstances such "inversion" would actually be needed?
Poof. Console logins for Windows (pGina) and Linux (sssd) using IPA
backed by your google account. That just eliminated 98% of the
external accounts you would have had to create and manage.
Your Google account does not use Kerberos that means that your password
goes over the wire. The whole point of Kerberos that password does not
go the wire.
That being said modern Kerberos server and client support OTP
preauthentication method. This method can be used (abused) to proxy to
any RADIUS server including the one provided by Google. So if you use
Google 2FA then it becomes more interesting. You can extually try it now
with the latest upstream bits. It is not 100% complete but good enough
to give it a try.
We are also working with MIT to make sure that one can use IPA with
Kerberos password + HOTP/TOTP token. Then instead of sending the
authentication to the external entity (RADIUS server) the token code
would be processed by IPA, but to make is more secure and not send the
password over the wire together with OTP, KDC and client need to support
authentication sets. It is a feature that we will be looking to have in
a 1.14 Kerberos release.
Food for thought.
Bryce
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Dmitri Pal
*Sent:* Saturday, March 22, 2014 5:55 PM
*To:* Will Sheldon
*Cc:* [email protected]
*Subject:* Re: [Freeipa-users] About Windows client
On 03/22/2014 05:47 PM, Will Sheldon wrote:
I’d be curious to see how well a solution that combines pGina using
RADIUS against some middleware like the Gluu server (www.gluu.org
<http://www.gluu.org>) backed by IPA would work.
This is not an interesting scenario. This would would probably work
right now but the machine would still not know who the user is because
it will not know user SID so he would be foreign and no Windows
policies would apply to him. I suspect such user would have no or very
limited read only access to Windows resources because all Windows ACLs
are based on knowing the user SIDs and SIDs of the groups the user is
a member of.
The value of native IdM integration would be to get user SID and SIDs
of the groups from IdM and then get the right kerberos ticket(s) for
Windows resources using cross realm kerberos trusts and put these
tickets into the right place so that windows system can use them
automatically when user navigates to the corresponding resource.
Something like this.
It strikes me that getting domain federation between IPA and Gluu
would tick a lot of boxes as it seems to offer a host of
authentication and accounting interfaces including oAuth, SAML, OpenID
and of course RADIUS.
Kind regards,
Will Sheldon
+1.778-689-1244
On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:
On 03/22/2014 01:18 PM, Arthur wrote:
Dmitri Pal wrote:
On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
HI!
I've got some thoughts on 4-th point: there is a
http://pgina.org/
pgina
project, may be them are able to do such thing.
Yes pgina is one of the options.
Someone would have to take it and integrate with MIT
Kerberos for
Windows if it is not already doing so.
But I suspect that it would be more a project in itself
that would
leverage code from MIT and may be pgina to integrate
different parts.
The biggest part figuring out the domain affiliation. I
mean the use
cases like this:
a) The system is domainless but user authentictaes with
user name and
password against IPA
b) The system is domainless but user authentictaes with
user name and
OTP against IPA
c) The system is in an AD domain trusted by IdM domain but
user
authenticates with user name and password against IPA
because he is
in IdM domain.
d) The system is in an AD domain trusted by IdM domain but
user
authenticates with user name and password against IPA
because he is
in IdM domain.
More to research. We can help with guidance if someone
wants to run
with it.
Thanks
Dmitri
20.02.2014 04:23, Dmitri Pal пишет:
Hello,
I want to summarize our position regarding joining
Windows systems
into IPA.
1) If you already have AD we recommend using this
system with AD and
using trusts between AD and IPA.
2) If you do not have AD then use Samba 4 instead
of it. It would be
great when Samba 4 grows capability to establish
trusts. Right now it
can't but there is an effort going on. If you are
interested - please
contribute.
3) If neither of the two options work for you you
can configure
Windows system to work directly with IPA as
described on the wiki. It
is an option of last resort because IPA does not
provide the services
windows client expects. If this is good enough for
you, fine by us.
4) Build a native Windows client (cred provider)
for IPA using latest
Kerberos. IMO this would be really useful if
someone does that because
we will not build this ourselves. With the native
OTP support in IPA
it becomes a real business opportunity to provide
a native 2FA inside
enterprise across multiple platforms. But please
do it open source way
otherwise we would not recommend you ;-)
_______________________________________________
Freeipa-users mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/freeipa-users
My friend agreed to try. He is C# programmer. But the problem
that has
low knowledge about kerberos, GSSAPI, and I could not told him
what is
wrong with current pgina's ldap plugin.
He does not want to subscribe to freeipa mail-lists, so may be
I shall
give him your (Dmitri) e-mail?
He speaks russian :)
List is really the way to develop open source software
collaboratively.
This is what we are doing here.
We can agree that the communication about the topic will be
prefixed in
such a way that he can create a filter so that he would get only
mails
that match the filter.
Would that work?
I am not sure that I would be able to provide all the support. We
are a
community here and we have different roles and angles. Working
with just
one person would not fly, sorry.
_______________________________________________
Freeipa-users mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
_______________________________________________
Freeipa-users mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
