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
