[Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)?

[Rich Megginson]

On 06/19/2014 09:16 AM, Alexander Bokovoy wrote:
> On Thu, 19 Jun 2014, Martin Kosek wrote:
>> On 06/19/2014 04:58 PM, Alexander Bokovoy wrote:
>>> On Thu, 19 Jun 2014, Simo Sorce wrote:
>>>> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote:
>>>>> On Thu, 19 Jun 2014, Simo Sorce wrote:
>>>>> >> I may need to revive my sysaccounts module...
>>>>> >
>>>>> >There is one more issue though, and this one really concerns me.
>>>>> >If you need to put there multiple accounts because different servers
>>>>> >have different local accounts, then you open up access to unrelated
>>>>> >services. Because all these uids are shared on all systems.
>>>>> >
>>>>> >I think this kills my own proposal of sticking these entries in
>>>>> >cn=sysaccounts.
>>>>> >
>>>>> >However we could have something in cn=config maybe ?
>>>>> >So that each server can:
>>>>> >A) use the same name/DN
>>>>> >B) have ids that match exactly the local named account no matter how
>>>>> >many different variants we have
>>>>> >C) no management issues when the server is killed from the
>>>>> >infrastructure as cn=config is local to that server and goes away 
>>>>> with
>>>>> >it.
>>>>> >
>>>>> >What do you think ?
>>>>> This is what Petr proposed too.
>>>>>
>>>>> 389-ds autobind code searches starting from a base defined in 
>>>>> cn=config.
>>>>> IPA defines it to be $SUFFIX. If we move these entries to cn=config,
>>>>> they will not be found by the code in
>>>>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we 
>>>>> change a
>>>>> search base to something in cn=config, we wouldn't be able to use 
>>>>> user
>>>>> accounts for autobind -- something which is possible right now.
>>>>>
>>>>> I'm not really concerned about user accounts' autobind but this is
>>>>> actually a behavior change for IPA.
>>>>
>>>> And I guess we can't list multiple bases for now ?
>>>> We do not use autobind for anything now though, and I do not see it as
>>>> useful for "normal" users on an IPA server, so I would be ok with the
>>>> change, even if it breaks backward compatibility on masters 
>>>> themselves.
>>> The only thing we use is root autobind which is handled by a separate
>>> mechanism, I think.
>>>
>>> Thus, it suits me.
>>>
>>> Petr, can you please make a ticket?
>>
>> How can you be sure that people do not already use the autobind 
>> feature? IMO,
>> it is a bad move to just break it because we have no better idea how 
>> to handle
>> named autobind.
> autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it
> a violation of RFC4513

A violation even when using EXTERNAL bind?

> and if we limit who can use it I don't think
> anyone will be crying too much.

If we change it to be incompatible, we may break existing _389_ 
customers, even if they are potentially using something that violates 
RFC4513.

>
>> I would rather like to see improved autobind capability in 
>> 389-ds-base which
>> would allow us to do the autobind configuration in cn=config and do 
>> entries like:
>>
>> uidnumber=25+gidnumber=25,cn=autobind,cn=config
>> ...
>> binddn: krbprincipalname=DNS/ipa.server.test,cn=computers...
>>
>> And thus have a per-server configuration without breaking existent 
>> functionality.
> That would work too but the main ide is to simply change our, IPA,
> defaults, rather than implementing something new. If somebody relies on
> autobind to work for regular users on IPA masters without explicit
> authentication,

By explicit authentication do you mean using EXTERNAL bind?

> it is already a question of a security breach.