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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
