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 

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

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

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

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

Reply via email to