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