[Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

>>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.

Yup.

>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.

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.