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

Simo Sorce simo at redhat.com
Fri May 31 14:17:54 UTC 2013


On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote:
> On Fri, 31 May 2013, Simo Sorce wrote:
> >On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote:
> >> On Thu, 30 May 2013, Dmitri Pal wrote:
> >> >[...]
> >> >>>>
> >> >>>> For Lunix and older SSSD version we in fact have a problem.
> >> >>>> What I want to avoid is to have to define procedures and patches for
> >> >>>> all
> >> >>>                ^^^^^^ ?
> >> >>>> the clients. However if you use ipa-client-install it would configure
> >> >>>> sssd the old way.
> >> >>>> How to make it configured the new way? Manually? This is error prone
> >> >>>> and
> >> >>>> people will be reluctant to reconfigure SSSD. Automatically? Means
> >> >>>> patches to all the versions of the clients.
> >> >>>> How we are going to deal with the huge test matrix?
> >> >>>
> >> >>> I think rolling out patches to old sssd versions is not a good idea and
> >> >>> I think we won't have the time to prepare all the needed patches in a
> >> >>> reasonable time-frame.
> >> >>>
> >> >>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6)
> >> >>> I would suggest to add a new domain section for the AD user with LDAP
> >> >>> and Kerberos provider. This would allow IPA users to works as before and
> >> >>> add the AD users to the client. Maybe this would also be a better
> >> >>> solution for the other SSSD versions instead of multiple search bases,
> >> >>> at least it's a solution for all versions.
> >> >>>
> >> >>> Since we have the python config API for SSSD the needed changes to the
> >> >>> sssd.conf might be scriptable with a reasonable effort. Maybe this can
> >> >>> be added to ipa-client-install with a new option like
> >> >>> --enable-legacy-trust-support which can add the news section to existing
> >> >>> configuration or include it for new installations?
> >> >> Bigger question is what is simpler: write configuration instructions or
> >> >> modify/provide additional script for old SSSD?
> >> >>
> >> >> Remeber that trusts with AD are most likely established when IPA clients
> >> >> are already rolled out. Changing ipa-client-install is not helpful for
> >> >> this case since the clients are already there.
> >> >>
> >> >> Perhaps a better approach would be documentation for non-SSSD case and a
> >> >> simple snippet that can be run alone or in use with puppet/etc to deploy
> >> >> massively. The snippet would use SSSDConfig Python API to add needed
> >> >> modifications to the clients' SSSD configuration.
> >> >>
> >> >> We can even extend IPA server tools to allow generating such snippets
> >> >> based on the trusts configuration. After all, we do have control over
> >> >> IPA server in such cases.
> >> >>
> >> >>
> >> >> I have updated wiki page with discussed ideas.
> >> >
> >> >Sorry but this is not enough.
> >> >I do not see a discussion the design about the client side solutuon
> >> >procedure.
> >> >
> >> >I am looking for a session that would contain a table (or like):
> >> >
> >> >--------------------------------------------------------------------------
> >> >|   Type/Version of the client   | Action                                |
> >> >--------------------------------------------------------------------------
> >> >| Solaris/HP-UX/AIX (non sssd)   | Configure manually to recognize AD as |
> >> >|                                | a domain following following steps ...|
> >> >--------------------------------------------------------------------------
> >> >| Clients that have SSSD         | If the client is already installed    |
> >> >| before 1.9                     | and configured do X                   |
> >> >|                                | If it is a fresh install of the       |
> >> >|                                | client do Y                           |
> >> >--------------------------------------------------------------------------
> >> >| SSSD 1.9 and later             | Use the following ipa-client-install  |
> >> >|                                | flags XYZ and/or authconfig command   |
> >> >|                                | ABC                                   |
> >> >--------------------------------------------------------------------------
> >> >
> >> >Can something like this be added to wiki and corresponding tickets to provide a testable
> >> >replacements for XYZ above be filed in trac?
> >> I've added more, including three tickets to cover specific
> >> configurations.
> >>
> >> Unfortunately, we have limits in multiple search bases approach by
> >> the commercial UNIX vendors since their LDAP modules do not support
> >> multiple search bases. For all of those platforms there is PADL pam_ldap
> >> available which can be used for the same purpose.
> >>
> >> If we still want to support native pam_ldap on Solaris (which don't work
> >> with multiple search bases), we'd have to merge LDAP trees.
> >
> >Alexander, in my initial proposal I said that trusted users should be
> >put in the same tree as compat users, it was exactly to address this
> >problem.
> >
> >We do not need to cause more problems by using multiple search trees
> >IMO.
> Ok, since I wanted to re-use slapi-nis anyway, this only means adding
> one more config attribute to slapi-nis configuration that will ask it to
> look into NSS in addition to the main query.
> 
> In which order these queries should be performed? first to LDAP then NSS
> or first to NSS then to LDAP? I guess the answer depends on specific
> setup -- if all your users in AD, you'd like to look at them first.

If we cache stuff in memory I am not sure it matters much.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list