>>I think that the requirement is to have two distinct sets of users
>>while you don't have control over one set (AD users) but you have to
>>manage the other set (IPA users) somehow.


>I'm yet to see what is the benefit over having only IPA users. Given single 
>sign-on wasn't a concern, it makes no difference then to specify IPA's user 
>name during logon from AD machines, so no integration would really be needed.

Difference #1 (user experience): Users in AD do not have a new password to 
remember and/or manage.
Difference #2 (administration overhead): I don't have to create users which are 
already in AD.
Difference #3 (political): I'm not duplicating effort of our IT division, I'm 
serving an un-served community, so there's less "turf" violation.

>An attempt to keep users in AD but use IPA features is really asking for 
>collaboration between the two infrastructure setups.

Well, part of the confusion may lie in the fact that much of the functionality 
in IPA and AD is unfamiliar to me, particularly at the beginning. First and 
foremost, I'm viewing both AD and IPA as identity stores which can provide 
Authentication services and store some information about the users which can be 
used by clients for various purposes: access decisions being a big one. I've 
been using the LDAP interface to AD because it's easier to understand, and 
because I can "graft in" my external users via an LDAP metadirectory. This can 
be done without any infrastructure collaboration, and it provides support for 
applications which do not allow you to configure more than one domain.

Then I started looking at trying to authenticate using Kerberos. Didn't know 
much about Kerberos when I started. It's supposed to have all sorts of good 
features. But it also seems to be the layer that introduces the need to 
collaborate, where before there was none. Early testing seems to indicate that 
I can in fact "kinit" against AD using a machine not joined to the domain. This 
gets me a no-address, forwardable TGT, and should suffice to tell the machine 
that the AD server believes I'm me. I suspect I will run into problems if I 
then try to use my TGT to get a login ticket for this "host-unknown-to-AD". I'm 
in the middle of trying to configure sssd on my test VM to use krb5/ldap 
authentication. It appears I cannot have sssd bind against AD's LDAP interface 
using Kerberos, or I just haven't figured out how, so the next step is to type 
my DN and password into another plain text file. Once this works, I'll 
configure IPA as a second domain on this host.

If machines on my research network (which does not share DNS namespace with AD) 
are joined to any domain, it would be to the FreeIPA domain. I do not quite 
understand the implications of this with regard to user principles from AD. It 
seems like it should be possible for me to make groups in FreeIPA which name 
members from other directories. It also seems like sssd should be capable of 
making access decisions based on a user principle from one domain and a group 
from another. But if I understand Kerberos correctly, it will be impossible for 
the FreeIPA TGS to issue a cross-realm ticket without the required cross realm 
trust and the associated "remote" principle entries in both directories.

I think my ability to make use of FreeIPA's extra (beyond authentication) 
functionality may depend on exactly where the access control decision is made, 
and how the information to support that decision is gathered. I'm hoping that 
sssd can be convinced to make these decisions based on information returned 
from an LDAP query on the freeIPA server and the TGT from the AD server. 
Contrary-wise, I'm hoping that I don't need a cross-realm Kerberos ticket from 
either domain.

Thanks for your patience. Sorry its taking so long to come up to speed.


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 

Freeipa-users mailing list

Reply via email to