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

[Alexander Bokovoy]

On Thu, 19 Jun 2014, Rich Megginson wrote:
>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?

Howard's line of thought was that RFC4513 requires to have anonymous
bind when no credentials were provided. Autobind makes implicit
conversion to authenticated bind here. I know that at the time of
discussion (~2007) 389-ds team's approach was that LDAPI is not really
LDAP protocol wise and it could deviate here.

>
>>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?
I mean that by becoming a non-privileged user on a 389-ds server that
has anonymous bind disabled will give you non-authenticated access to
LDAP store through autobind+LDAPI. Non-authenticated in terms of not
providing any authentication data to LDAP store. So breaking a user
account is enough to get data (subject to ACIs, of course), you don't
need to have any idea of what credentials the user should have.

It is question of policies to be set and for FreeIPA masters I would
argue that the policy should be to prevent non-privileged users to do
autobind+LDAPI unless it is explicitly allowed by the configuration for
that specific user.
-- 
/ Alexander Bokovoy