URL: https://github.com/SSSD/sssd/pull/522 Author: abbra Title: #522: Prepare SSSD to support IPA in trust to Samba AD Action: opened
PR body: """ This pull request prepares SSSD ipa provider to support IPA in trust to Samba AD but the same changes are needed for a properly working bi-directional trust against Microsoft AD as well. To make everything fully working, one needs patches against FreeIPA too but SSSD changes are isolated. @sumit-bose @jhrozek please review. 1. When IPA establishes a trust to an Active Directory forest, a number of special objects is created in a subtree of `cn=trusts,$SUFFIX`. These objects represent Kerberos principals for trusted domain objects (TDOs) used for both incoming and outgoing trusts. For bi-directional trust there is a requirement that one of them (`<REMOTE FLAT NAME>$@<OUR REALM>`) must have a POSIX identity because a remote domain controller will use it to authenticate against smbd running on IPA master. SSSD only looks for user accounts in `cn=accounts,$SUFFIX`, so an attempt by smbd to resolve this principal name as a POSIX user via `getpwnam()` will fail. And the reason why smbd behaves this way is due to the fact that a Kerberos ticket used for authentication contains no MS-PAC record, thus not allowing Samba to build a local security token it needs. This is expected for the authentication using TDO account as it is used for bootstrapping reasons (AD DC couldn't create and sign MS-PAC record for an account in IPA realm) but the side effect is that TDO object must be known as a POSIX account on IPA master. Thus, we extend user search base in IPA provider to search in both `cn=accounts,$SUFFIX` and `cn=trusts,$SUFFIX`. Changes on FreeIPA side will handle access controls and generation of the POSIX information for the TDO accounts. 2. For long time we relied on using cross-realm TGTs to talk to Active Directory domain controllers (LDAP and GC services) in case of bi-directional trust. Unfortunately, this is not something we can continue using as there are multiple reasons such access can be denied by a trusted AD side, including SID filtering and other security measurements. It also happens that right now Samba AD in Fedora has a bug in handling a cross-realm TGT generated by the FreeIPA KDC. As result, while technically IPA could establish a bi-directional trust to Samba AD, it does not work as any SSSD attempt to connect to AD DCs via LDAP with GSSAPI will fail (Samba AD DC answers error with PROCESS_TGS message on Kerberos level and authentication fails). For this reason, we should remove any distinction when using bi-directional trust and simply always use a special keytab with a TDO object as we do in uni-directional trust case. While a more generic Kerberos authentication will not work in the outbound direction, SSSD will be able to resolve users/groups. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/522/head:pr522 git checkout pr522
From a401512caac7d9d60887cc286bda215efdf68b83 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy <aboko...@redhat.com> Date: Thu, 22 Feb 2018 14:38:51 +0200 Subject: [PATCH 1/2] ipa provider: expand search base to cover trusted domain objects In case of a two-way trust between FreeIPA and an Active Directory, domain controller would use a TDO object in the trusting domain to authenticate. Due to how trusted domain objects are used in Active Directory, a domain controller from the trusted domain will synthesize a Kerberos ticket for the TDO in the trusting domain. This ticket will lack MS-PAC information because a trusted DC has no idea what to put there. On IPA master smbd process will attempt to validate successfully authenticated TDO principal by looking at its MS-PAC structure, only to find it is missing. As result, smbd will revert to a direct getpwnam(). Because TDO objects are stored under cn=trusts,$SUFFIX in FreeIPA, they couldn't be found by SSSD which uses cn=accounts,$SUFFIX by default. Add second search base to look up cn=trusts,$SUFFX to allow TDO objects to be queried. On FreeIPA side access controls are put in place so that only AD trust agents are able to see a content of the cn=trusts,$SUFFIX subtree. Signed-of-by: Alexander Bokovoy <aboko...@redhat.com> --- src/providers/ipa/ipa_common.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/src/providers/ipa/ipa_common.c b/src/providers/ipa/ipa_common.c index 2b81d7f3f..a120dbf8d 100644 --- a/src/providers/ipa/ipa_common.c +++ b/src/providers/ipa/ipa_common.c @@ -176,7 +176,7 @@ int ipa_get_id_options(struct ipa_options *ipa_opts, TALLOC_CTX *tmpctx; char *basedn; char *realm; - char *value; + char *value, *value2; int ret; int i; @@ -271,12 +271,24 @@ int ipa_get_id_options(struct ipa_options *ipa_opts, /* fix schema to IPAv1 for now */ ipa_opts->id->schema_type = SDAP_SCHEMA_IPA_V1; - /* set user/group search bases if they are not specified */ - if (NULL == dp_opt_get_string(ipa_opts->id->basic, - SDAP_USER_SEARCH_BASE)) { - ret = dp_opt_set_string(ipa_opts->id->basic, SDAP_USER_SEARCH_BASE, + /* set user/group search bases if they are not specified A caveat is that + * we need multiple bases defined for trusted TDOs accounts to be found */ + value2 = dp_opt_get_string(ipa_opts->id->basic, SDAP_USER_SEARCH_BASE); + if ((NULL == value2) || (NULL == strstr(value2, "?cn=trusts,"))) { + /* Search both cn=accounts,$SUFFIX and cn=trusts,$SUFFIX. This allows + * to catch trusted domain objects used by trusted AD DCs to talk to + * Samba on IPA master */ + value = talloc_asprintf(tmpctx, "%s???cn=trusts,%s??", + value2 ? value2 : dp_opt_get_string(ipa_opts->id->basic, - SDAP_SEARCH_BASE)); + SDAP_SEARCH_BASE), + basedn); + if (!value) { + ret = ENOMEM; + goto done; + } + ret = dp_opt_set_string(ipa_opts->id->basic, SDAP_USER_SEARCH_BASE, + value); if (ret != EOK) { goto done; } From 7f36f16d8c177e8469152564650fafd473cb558d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy <aboko...@redhat.com> Date: Thu, 22 Feb 2018 14:45:16 +0200 Subject: [PATCH 2/2] ipa provider: always use a special keytab to talk to a trusted DC When FreeIPA is set up to trust an Active Directory forest, we should be using trusted domain object credentials regardless of the trust direction. Previously, SSSD relied on FreeIPA KDC issuing a cross-realm referral towards a trusted domain. However, this does not work currently with Samba AD and in general we want to move away to use TDO in all cases as it is guaranteed to have correct permissions on AD side. Signed-of-by: Alexander Bokovoy <aboko...@redhat.com> --- src/providers/ipa/ipa_subdomains_server.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/providers/ipa/ipa_subdomains_server.c b/src/providers/ipa/ipa_subdomains_server.c index d670a156b..4c1ccf2bd 100644 --- a/src/providers/ipa/ipa_subdomains_server.c +++ b/src/providers/ipa/ipa_subdomains_server.c @@ -33,6 +33,7 @@ */ #define LSA_TRUST_DIRECTION_INBOUND 0x00000001 #define LSA_TRUST_DIRECTION_OUTBOUND 0x00000002 +#define LSA_TRUST_DIRECTION_MASK (LSA_TRUST_DIRECTION_INBOUND | LSA_TRUST_DIRECTION_OUTBOUND) static char *forest_keytab(TALLOC_CTX *mem_ctx, const char *forest) { @@ -663,11 +664,10 @@ ipa_server_trusted_dom_setup_send(TALLOC_CTX *mem_ctx, subdom->name, state->forest, ipa_trust_dir2str(state->direction)); - if (state->direction & LSA_TRUST_DIRECTION_OUTBOUND) { - /* Use system keytab, nothing to do here */ - ret = EOK; - goto immediate; - } else if (state->direction & LSA_TRUST_DIRECTION_INBOUND) { + /* For both inbound and outbound trusts use a special keytab + * as this allows us to reuse the same logic in FreeIPA for + * both Microsoft AD and Samba AD */ + if (state->direction & LSA_TRUST_DIRECTION_MASK) { /* Need special keytab */ ret = ipa_server_trusted_dom_setup_1way(req); if (ret == EAGAIN) {
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org