Andreas Hasenack writes:

I was just wondering if this is expected behaviour.

It's intended behavour that rootdn can be the name of an entry and you can use that entry's password.

When both an entry and rootpw exist, backends are currently inconsistent about which one is used. (Which backend are you using? I thought it happened just with the LDIF backend.)

I find this a bit unexpected. Suppose someone manages to create an entry matching rootdn. Then this person would be able to become rootdn, bypassing the rootpw setting in slapd.conf.

I'll note that as an argument for having rootpw override the entry's dn:-)

However note that the rootpw is only used if the rootdn is in the database's naming context (i.e. ends with its "suffix"). That's because the password is checked during Bind, which looks in the the Bind DN's database for the entry and password to bind as.

I guess we could try to give a warning or error if one has a rootpw which would not be used, but subordinate databases and some overlays make that a bit complicated.

Andreas Hasenack wrote:

I find this a bit unexpected. Suppose someone manages to create an entry matching rootdn. Then this person would be able to become rootdn, bypassing the rootpw setting in slapd.conf.

If you're scared about the power of rootdn switch it off.

Ciao, Michael.