On 4/30/22 00:53, Quanah Gibson-Mount wrote:
The only viable solution is to provide decent tooling for setting up a DB with presets. If going this route you can also setup an admin group with decent ACLs right from the start. And the setup process can run as root connecting via LDAPI and using SASL/EXTERNAL for authc. Then running the setup as system user root is the initial trust anchor for boot-strapping the directory. Well, *you* already know all this and you probably guessed it: That's how Æ-DIR setup is doing it (and all automated setups I do for customers).
Yeah, I prefer the ldapi:// + EXTERNAL route as well, but that becomes somewhat more complicated (but of course not impossible) if you're using different rootdns for cn=config vs the other databases. Some sites require a high level of separation.
In my setups the rootdn of the "admin" DB is used in ACLs of the other DBs. That's what you probably meant.
If an auditor would question that I'd argue that system user "root" already has full access to the DB files and that my ACLs simply repeat that authorization.
Yes, in a customer project an auditor already asked who the rootdn in 'modifiersName' is. And we had to explain to him that some modifications were done initially during setup or are done by overlays with that identity. And in such a case it's very nice being able to clearly state that nobody can authc as this identity from remote or from an unprivileged process.
Ciao, Michael.