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

Simo Sorce simo at redhat.com
Fri May 31 15:42:12 UTC 2013


On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > 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.
> 
> Note that AFAIK there is no option in slapi-nis to look at nss. It is 
> probably safe to assume that the sssd loop protection will suffice.
> 
> This may be quite a change too, as slapi-nis won't be able to rely on 
> watching for MOD to update itself and instead will need to be a 
> general-purpose cache, or ALWAYS look up the entry (or entries) in nss 
> and rely on the local sssd cache to prevent performance issues.

My initial proposal was to always lookup via NSS and rely on sssd fast
cache to avoid costly operations, at least for individual lookups.
for enumerations it will be sorta expensive, but that is fine IMO.

Simo.

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




More information about the Freeipa-devel mailing list