On 28/07/2023 12:35 pm, Howard Chu wrote:
Clients that don't Bind are, by definition, anonymous.
Yes, that is the term used in the RFCs, but the RFCs do not say what
anonymous sessions can and cannot do. This is up to the system
administrator. It is not unreasonable to base those permissions on who
by or how the connection was established.
Compare:
access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth
access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
Clearly pointless, because an external bind doesn't need access to userPassword
at all.
Think SIMPLE bind over an ldaps channel. Just because the EXTERNAL
identity is there, does not force a client to use it.
The analogy fails because "auth" access doesn't allow a user to see the values
of what access was granted to, while anyone could read the contents of the passwd
file. Granting auth access only allows clients to perform Simple Bind ops.
Not a perfect analogy, but still helpful.
You are asking to associate an identity to a session. That is what
"authenticating" is. In LDAP a Bind request is used for authentication.
You're asking for LDAP to perform some new, previously undefined operation to
do exactly what a SASL EXTERNAL Bind does.
This is not a new or undefined operation, this is as old as computers
themselves. I control who my clients are by who I allow to connect to my
system. Signing a certificate for a client is the modern day equivalent
of "plugging it in". The fact that LDAP has an explicit bind operation
does not invalidate this fundamental rule of computer networks.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
