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

Fri May 31 14:35:16 UTC 2013

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.

rob