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.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
