[Freeipa-devel] [RFC] Serving legacy systems cliens for trusts

[Alexander Bokovoy]

On Wed, 29 May 2013, Sumit Bose wrote:
>On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote:
>> Hi,
>>
>>
>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
>>
>> = Overview =
>>
>> Since version 3.0 FreeIPA supports cross-realm trusts with Active
>> Directory. In order to allow AD users to utilize services on IPA
>> clients, up to date version of SSSD should be configured at the IPA
>> client. In case it is not possible to install and configure SSSD > 1.09,
>> Active Directory users cannot access services on IPA clients.
>>
>> This feature is designed to bridge the gap and provide minimal
>> compatibility level that allows to log-in to IPA clients for AD users.
>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd
>> version.
>>
>> = Use Cases =
>>
>> Access to IPA client machine resources for AD users in case IPA client
>> cannot utilize up to date version of SSSD with native support for IPA
>> cross-realm trusts.
>>
>> = Design=
>>
>> Since IPA client is configured with the use of older SSSD or
>> nss_ldap/pam_ldap, all work should be performed at the IPA master.
>> Primary design decision is to provide a separate LDAP tree, similar to
>> compat tree, that has following features:
>>
>> * information about both IPA and AD users can be queried;
>> * it ispossible to enumerate members of IPA and AD groups;
>> * authentication bind to IPA LDAP as AD users should automatically
>> * trigger obtaining ticket from AD DC; in case TGT is obtained,
>> * authentication bind should be treated as successful.
>>
>> From a client perspective, use of the separate LDAP tree is viewed as
>> traditional nss_ldap/pam_ldap configuration.
>>
>> Proposed base for the LDAP tree:
>> '''cn=users,cn=trust-accounts,dc=example,dc=com'''
>
>I guess older SSSD versions, e.g. 1.8. might be the most difficult use
>cases because they already support some specific features for IPA users
>and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most
>of them depends on DNs one way or the other I think older SSSD version
>must continue to use the main tree for IPA users and groups and local
>look at the new tree for trusted accounts. Luckily multiple search bases
>were introduced in SSSD 1.7, I wonder if older version have to be
>supported as well? But if multiple search bases are used the IPA users
>and groups should not be visible in the new tree for trusted accounts.
>
>Maybe the new plugin can offer different trees like
> - cn=users,cn=trust-accounts,dc=example,dc=com
> - cn=users,cn=trust-accounts-sssd,dc=example,dc=com
>
>where the first contains IPA and AD accounts as mentioned above and the
>latter only the AD accounts? Since we are planning to do the lookups on
>the fly I think both trees can be handled in the same code path and the
>path name is just config option which switches the IPA accounts on and
>off respectively.
>
>With iyet another tree it might be also possible to support either rfc2307 or
>rfc2037bis. I assume that the plan is that the new tree will use
>rfc2307bis but I wonder if we have to support clients which only support
>rcf2307.
Yep.

Summarizing for the list discussion we had with Sumit on IRC, I think we
can re-use slapi-nis plugin for the purpose of this feature.

The way slapi-nis works for schema compatibility is that one needs to
define first a subtree to search against, with a filter, and then
additional transformations are applied to the result of search. The end
result is presented to the client.

What we need to do is to make possible to return a result of initial
'search' against SSSD instead of actual LDAP subtree. A 'search' result
is then processed according to defined transformation rules.

slapi-nis supports multiple resulting trees already, this solves the
problem Sumit raises above.

Additionally, for LDAP auth bind we need to make sure it is actually
possible to hook to in a directory server plugin for a virtual DN like
slapi-nis presents. This is something Sumit and I need to check with 389-ds
developers. We already have some support for that with new feature to
allow fallbacks for SASL auth but in this case we need to use simple
bind to get hold of the password (to kinit agasint AD DC) over secure
channel.

-- 
/ Alexander Bokovoy