Sorry if I asked about this before and forgot it... Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.) That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password. The simple way to do that is to grant access to the service's IP address, but that's not always feasible, and gets hard to maintain.

Howard Chu writes: > Hallvard B Furuseth wrote: >> Could we add an 'access ... by' variant for the client's TLS >> certificate, _without_ Bind:SASL/EXTERNAL? >> (To the cert's DN, I expect, but I don't know much about >> certificates. Maybe there are other things to look at as well.) >> >> That could be used to authenticate a service (an LDAP client) >> rather than the user it Binds as, when the service asks the user >> for password and Binds with his DN and password. >> (...) > This sounds like a special case of proxy authorization. Can't you just > use that? Not that I can see. man slapd.conf says under authz-policy: Proxy authorization (...) essentially allows user A to login as user B, using user A's password. But I want the service to authenticate the user with his own credentials and identify itself with its credentials, and use both identities for access control in a single access statement. A more general description would be, grant access based on the DN which would be used if the client were to do Bind:SASL/EXTERNAL, or possibly the DN which would be passed to authz-regexp. access to ... by self extdn=<certificate's DN> write by * read