On 08/28/2014 12:08 PM, Gerardo Padierna wrote:

In a setup where FreeIPA + sssd act as an authentication for AD users (taking advantage of sssd's ability to act as an authentication client for AD users), why do we need to establish a (two-way) trust relationship? Ins't there a workaround for this, given that sssd is already able to authenticate users without having to do nothing on the DA-side (just need a read-only user to carry out the initial bind)?

In a bit more detail: We'd like to use AD-based authentication on some Unix hosts (mostly Solaris 10) for which there's no sssd available (we're already using sssd on RHEL hosts); we were thinking of setting up a server with FreeIPA + sssd to act as sort of a proxy to the actual AD for authentication, for those hosts for which there's no sssd client available (based on this doc: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts).
There reasons why we're doing this are basically:
· there's no unix-compatibiliy available on the AD sever (and most likely there won't ever be) · we'd like to keep the same UID/GIDs for all users that already authenticate on the RHEL boxes (to be able to work on the same home directories, maintain homogenous file ownership accross shared ressources, etc.)

So, we've set up:
· a CentOS 7.0 host with ipa-server v3.3.3 and sssd v1.11.2 and configured (with domain: ipa-dom.com) · checked that sssd-based authenticacion to the AD server works on this box (AD-users in domain da-dom.com) · checked that the IPA server works for users created on the IPA server (domain e.g. u...@ipa-dom.com)

Now, to set up what we really wanted, which is basically, on a Unix-box with no sssd client, be able to authentica a us...@da-dom.com via the FreeIPA-server, through sssd. But, the final step of the configuration process (cmd: ipa trust-add ...) requires to establish a two-way trust relationship between the IPA server and the AD DC, which requires AD administrator privileges (which we don't have, and I don't see why we should have them). The AD admins of the company are not willing to consider this trust relationship to be established because the regard this as a secury risk.

My question is basically, isn't there a workaround for this situation? If sssd is already able to authenticate, and based on the explanations of the doc mentioned above, I can't see why for plaiin user authentication there must be a trust relationship established. We don't need that for any of our sssd-based hosts (and they haven't been added to the domain da-dom.com, no need to).

Any suggestions? Maybe there are different setups and/or tool combinations for a this kind of scenario?

Thanks a lot,


*Gerardo Padierna*

Will one way trust be acceptable by AD admins?
Is there more prejudice to IdM connecting to AD in general or one way trust when IPA trusts AD but not the other way around is OK?
It will still require admin privileges to establish the trust.
There is already work going on to make the trust be one way by default since there is some confusion about it. Trusts are needed for Kerberos to be able to forward tickets and do SSO. Without trusts you can do only basic proxy setup which can be done with a DS server and PAM proxy plugin - a non goal for IPA.

Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to