[SSSD] [sssd PR#522][opened] Prepare SSSD to support IPA in trust to Samba AD

[abbra]

   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