One-way trust support for IPA trusts to AD
ipasam module needs to be extended to add IPA$@AD account with the same key as primary Kerberos principal for the trust. The account should have 'disabled' status for Kerberos so that it will be impossible to kinit using this account against IPA KDC.
ACIs for IPA$@AD principal keys will be set to allow host/ipa.master reading them similar how we handle them for cifs/ipa.master with 'adtrust agents' group.
Generating keytab for trust account credentials can be done with existing IPA keytab retrieval extended operation.
SSSD would use this operation to retrieve key for IPA$@AD account and store it in a separate keytab in /var/lib/sss/db when running in IPA server mode on the masters configured to be domain controllers for AD. Keys for each trusted forest will be put in separate keytab files.
This keytab will be used by SSSD when talking to Active Directory DCs from a forest. Kerberos authentication is required here because in general we cannot guarantee secure channel towards LDAP or GC service in AD domains belonging to the forest.
The code in IPA framework will need to be changed to use one-way trust method by default and keep two-way trust method code to allow later re-enabling it for two-way approach to work when Global Catalog support will be added.
The IPA$@AD principal belongs to the replicated space, thus each SSSD on IPA master where ipa-adtrust-install was run can be used to retrieve up to date version of the key. Additionally, SSSD simply will initiate the retrieval request whenever there is absent per-trust keytab or the key there is invalid (AD DCs refuse authentication).
With this approach the only practical issue left is trust topology retrieval done with 'ipa trustdomains-fetch' once trust is established. Here we'll need to resurrect the code to authenticate as trust account and thus limit this operation to 'trust admins' group.
We do not have enough time to focus on this in 4.1, let's do it in 4.2.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1145748 (Red Hat Enterprise Linux 7)
I want to add an important note to this. We should not use the term "trust" for this solution. In this solution IPA is a member server in AD domain. There is no trust. It is a proxy solution and we should use the corresponding terminology. Many deployment have policies that do not allow any kind of trust. But using the word "trust" for this setup we are actually reducing the value of this approach.
So as we implement it we should IMO add a separate command that would be something like: ipa-ad-proxy-setup Internally it can be just a wrapper around ipa trust-add --proxy or something like but it will not expose any trust terminology to the end user.
It is extremely important as there is not much understanding of the details and T word scares people big time.
Use case: There are client systems that been to be managed for SUDO and authentication centrally. Kerberos authentication would be nice but not required. LDAP authentication is fine. HBAC and SUDO is the additional value. T is not allowed by policy but proxy is fine. People can just connect systems to AD but that would not give them SUDO or HBAC. So having IPA as simple LDAP proxy + SUDO + HBAC would resonate with a lot of deployments and would make IPA more relevant in more environments.
Related work: #4951
I'm not sure I completely follow the details, so I guess I'll ask a dumb user question.
If I have a DMZ controlled by IPA to which I add servers, and AD supports an outbound trust to IPA, can AD users SSO to IPA controlled servers?
Replying to [comment:10 bnordgren]:
I'm not sure I completely follow the details, so I guess I'll ask a dumb user question. If I have a DMZ controlled by IPA to which I add servers, and AD supports an outbound trust to IPA, can AD users SSO to IPA controlled servers?
With one way trust IPA will trust AD but AD would not trust IPA. Users from IPA would not be able to access resources managed by AD but users from AD will be able to access resources managed by IPA. Your use case will work. The reason we need to do this is because right now the trust is two way but IPA users can't access AD resources anyways because we do not have global catalog. Once we add GC IPA users would be able to access AD resources. Before this happens we want to give existing deployments ability to convert the trusts into one way trusts so that if they really do not want IPA users to have access they can prevent it consciously.
master:[[BR]] 2dd5b46 trust: support retrieving POSIX IDs with one-way trust during trust-add[[BR]] 5025204 trusts: add ACIs to allow AD trust agents to fetch cross-realm keytabs[[BR]] a9570e8 ipa-pwd-extop: expand error message to tell what user is not allowed to fetch keytab[[BR]] d5aa1ee trusts: add support for one-way trust and switch to it by default[[BR]] 14992a0 ipa-adtrust-install: allow configuring of trust agents[[BR]] aa21600 ipa-sidgen: reduce log level to normal if domain SID is not available[[BR]] 47e1de7 trusts: pass AD DC hostname if specified explicitly[[BR]] 03c2d76 ipa-adtrust-install: add IPA master host principal to adtrust agents[[BR]] 785f659 add one-way trust support to ipasam[[BR]]
Metadata Update from @abbra: - Issue assigned to abbra - Issue set to the milestone: FreeIPA 4.2
Login to comment on this ticket.