Is your feature request related to a problem? Please describe.
When this chart gets deployed with LDAP authentication enabled, the used bind dn will get used as the initial admin user. This forces the admin to use the LDAP bind also as the first admin identity. In my use case however, the LDAP bind dn should only be allowed to read from the LDAP server and do nothing else. The initial admin user should be another user. This also clashes with the identity mapping feature of NiFi.
Describe the solution you'd like
Since there is already a value auth.admin, it should overwrite the LDAP bind dn if set and LDAP authentication is enabled. If not set, the bind dn can be used.
Describe alternatives you've considered
It would also be possible to just bind anonymously to the LDAP server and set the bind dn to the used value. But this approach would be less secure and would make it difficult to apply certain restrictions in the LDAP server.
Is your feature request related to a problem? Please describe. When this chart gets deployed with LDAP authentication enabled, the used bind dn will get used as the initial admin user. This forces the admin to use the LDAP bind also as the first admin identity. In my use case however, the LDAP bind dn should only be allowed to read from the LDAP server and do nothing else. The initial admin user should be another user. This also clashes with the identity mapping feature of NiFi.
Describe the solution you'd like Since there is already a value
auth.admin, it should overwrite the LDAP bind dn if set and LDAP authentication is enabled. If not set, the bind dn can be used.Describe alternatives you've considered It would also be possible to just bind anonymously to the LDAP server and set the bind dn to the used value. But this approach would be less secure and would make it difficult to apply certain restrictions in the LDAP server.