On 1/08/2023 3:46 am, Jordan Brown wrote:
On 7/31/2023 9:10 AM, Howard Chu wrote:
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
Does the RFC explicitly authorize controlling access based on the client's IP address? Does slapd allow controlling access based on the client's IP address?
Howard is being very literal in his reading of the LDAP RFCs. The RFCs define several authentication and authorization states and specific operations required to change those states. Until those specific LDAP actions occur, the states no not change. Specifically, the client's TLS layer authenticating with the server's TLS layer does not change the LDAP authentication state.
The point is that what those LDAP states MEAN is a matter of local policy.
1) If a system admin wants to give "anonymous" sessions the power to create and destroy entire databases, there is nothing in the RFC's or slapd to stop them.
2) Less dramatically, if the system admin wants to use IP addresses to determine access to database entries and ignore the authentication state defined by the LDAP RFCs, that is also allowed by the RFCs and by slapd.
3) Finally, if the system admin wants to use the TLS layer authentication state to subtly modify access rights, that is also allowed by the RFCs, BUT NOT BY SLAPD.
I find slapd's incapacity in the third case to be a bizarre inconsistency.
Sean.