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.

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to