I’m not, in general, in favor of solutions which promiscuously sling Kerberos 
passwords around the net. ☺ pGina + 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.

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.

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.


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.

Food for thought.

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Saturday, March 22, 2014 5:55 PM
To: Will Sheldon
Cc: freeipa-users@redhat.com
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
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
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
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
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
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
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.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to