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