HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
I saw that slapd.access(5) also mentions "realusers" for the <WHO> field but using this instead of "users" makes no difference.
Ciao, Michael.
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
I saw that slapd.access(5) also mentions "realusers" for the<WHO> field but using this instead of "users" makes no difference.
Obviously that's not what it means. The "real" prefix specifies the real user when proxy authorization is in effect.
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user". Thus I had to rework all my acls to avoid ever using the "users" concept when it would have been quite useful (and had to resort to sets instead).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chuhyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user". Thus I had to rework all my acls to avoid ever using the "users" concept when it would have been quite useful (and had to resort to sets instead).
Nonsense. There's a clear difference between SASL DNs and "real" DNs - just write an ACL to deny access to any SASL DN, then only your users that were successfully mapped to real DNs will have access.
On Apr 1, 2010, at 3:22 PM, Quanah Gibson-Mount wrote:
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user".
You confuse authentication with authorization. In this case, that principal is certainly authenticated. It's just not authorized (in your case). There certainly may be cases where such users are authorized to some degree.
Thus I had to rework all my acls to avoid ever using the "users" concept when it would have been quite useful (and had to resort to sets instead).
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user". Thus I had to rework all my acls to avoid ever using the "users" concept when it would have been quite useful (and had to resort to sets instead).
What about
access to ... by dn.subtree="cn=auth" none by users read
This would blow away non-mapped users, and give mapped ones the desired access
p.
Kurt Zeilenga wrote:
On Apr 1, 2010, at 3:22 PM, Quanah Gibson-Mount wrote:
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user".
You confuse authentication with authorization. In this case, that principal is certainly authenticated. It's just not authorized (in your case). There certainly may be cases where such users are authorized to some degree.
Kurt, it's not that simple: Off course there was an successful authentication in case of SASL/EXTERNAL. Taking the term "authenticated clients" literally you're done for processing "by users".
But the user is not really *identified* in terms of an entity represented by a directory entry and therefore the behaviour looks strange to me because no-one wants to deal with SASL authc-DNs when designing ACLs. I'd prefer changing semantics of "by users" to "identified clients" or having another key-word "by identifiedusers" with that semantics.
The authorization step happens *after* identification based on the (optionally mapped) principal name.
Ciao, Michael.
--On Friday, April 02, 2010 9:30 PM +0200 Michael Ströder michael@stroeder.com wrote:
Kurt, it's not that simple: Off course there was an successful authentication in case of SASL/EXTERNAL. Taking the term "authenticated clients" literally you're done for processing "by users".
But the user is not really *identified* in terms of an entity represented by a directory entry and therefore the behaviour looks strange to me because no-one wants to deal with SASL authc-DNs when designing ACLs. I'd prefer changing semantics of "by users" to "identified clients" or having another key-word "by identifiedusers" with that semantics.
The authorization step happens *after* identification based on the (optionally mapped) principal name.
We do this elsewhere. Perhaps usersz and usersc? (Similar to authc and authz?)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Apr 2, 2010, at 12:30 PM, Michael Ströder wrote:
Kurt Zeilenga wrote:
On Apr 1, 2010, at 3:22 PM, Quanah Gibson-Mount wrote:
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chu hyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user".
You confuse authentication with authorization. In this case, that principal is certainly authenticated. It's just not authorized (in your case). There certainly may be cases where such users are authorized to some degree.
Kurt, it's not that simple: Off course there was an successful authentication in case of SASL/EXTERNAL. Taking the term "authenticated clients" literally you're done for processing "by users".
But the user is not really *identified* in terms of an entity represented by a directory entry and therefore the behaviour looks strange to me because no-one wants to deal with SASL authc-DNs when designing ACLs.
The user identity was verified. Whether they have an entry or not is not factor in authentication (excepting to the extent that entry holds credential informaiton).
What you are saying is you want authenticated users with a directory entry to have different authorization than authenticated users without a directory entry.
IIRC, if you want all authenticated users without a directory entry to be treated as anonymous, you can perform a authzid mapping through an LDAP lookup and basically force that behavior.
I'd prefer changing semantics of "by users" to "identified clients" or having another key-word "by identifiedusers" with that semantics.
Clients are always identified (generally by IP address). But they are always authenticated. Authentication is the step which verifies identity.
Users is defined as meaning "authenticated users", which is quite correct.
The authorization step happens *after* identification based on the (optionally mapped) principal name.
Actually, there's (at least) two different forms of authorization going on: Service level authorization and Information access authorization.
access statements are about the latter.
One can control the former by having authorization mappings fail, by various require statements, etc.
-- Kurt
Michael Ströder wrote:
Kurt Zeilenga wrote:
On Apr 1, 2010, at 3:22 PM, Quanah Gibson-Mount wrote:
--On Thursday, April 01, 2010 12:58 PM -0700 Howard Chuhyc@symas.com wrote:
Michael Ströder wrote:
HI!
I have some doubts about ACLs containing "by users" and the term "authenticated clients" used in the man pages: If I bind with SASL/EXTERNAL (e.g. over LDAPI) and the authc-DN does *not* map to an authz-DN of a real directory entry what does "by users" then mean exactly?
It means anyone who has successfully authenticated, by any means.
It seems that slapd grants access with clause "by users" but I feel this is wrong. I'd prefer if "users" would mean fully-identified clients mapped to a real entry.
No. Such a restriction would prevent distributed authentication from ever working.
The downside of not being able to be able to specify authenticated DNs vs DNs that actually map to an entry in the database is that for some things (like SASL/GSSAPI setups) it makes the "users" value completely worthless, as any kerberos principal in the KDB that connects to the ldap servers is considered a "user".
You confuse authentication with authorization. In this case, that principal is certainly authenticated. It's just not authorized (in your case). There certainly may be cases where such users are authorized to some degree.
Kurt, it's not that simple: Off course there was an successful authentication in case of SASL/EXTERNAL. Taking the term "authenticated clients" literally you're done for processing "by users".
But the user is not really *identified* in terms of an entity represented by a directory entry and therefore the behaviour looks strange to me because no-one wants to deal with SASL authc-DNs when designing ACLs. I'd prefer changing semantics of "by users" to "identified clients" or having another key-word "by identifiedusers" with that semantics.
That's completely wrong. "Authentication" is the process by which one party asserts their identity to another party and provides proof of that assertion. If the client has authenticated successfully, then they have, by definition, identified themselves.
The authorization step happens *after* identification based on the (optionally mapped) principal name.
Yes of course. And if you want some certain authenticated clients to be treated differently from other authenticated clients, that's your business. That's exactly what ACLs are for.
As an aside, if your authentication system identifies a large proportion of clients that you don't actually want to serve, it seems to me you're not using the right authentication system, but that's totally a side issue.
Kurt Zeilenga wrote:
IIRC, if you want all authenticated users without a directory entry to be treated as anonymous, you can perform a authzid mapping through an LDAP lookup and basically force that behavior.
Actually my slapd.conf contains a authz-regexp directive for that purpose. But although there's no authz-DN found for the technical authc-DN the client is treated as authenticated. Yes, this is described in slapd.conf(5) but IMO it's wrong.
So I have to add the work-around <WHO> field Pierangelo suggested to all those ACLs.
Ciao, Michael.
Kurt Zeilenga wrote:
IIRC, if you want all authenticated users without a directory entry to be treated as anonymous, you can perform a authzid mapping through an LDAP lookup and basically force that behavior.
Actually my slapd.conf contains a authz-regexp directive for that purpose. But although there's no authz-DN found for the technical authc-DN the client is treated as authenticated. Yes, this is described in slapd.conf(5) but IMO it's wrong.
So I have to add the work-around <WHO> field Pierangelo suggested to all those ACLs.
I wouldn't call that exactly a "workaround", since it does things the way they are intended to be done. As many pointed out, "users" means "authenticated", and they actually are. ACLs allow you to give specific privileges based on the identity, and that's the way I'd use. Any way that allows to tell, based on their DN, whether authenticated users actually correspond to an in-directory entry, is good for the purpose. Remember: it's your own rule that gives higher privileges to users with an in-directory entry. In general, this cannot be considered a generally valid rule, as it would basically prevent authenticated distributed directory operations.
p.
openldap-software@openldap.org
-
Howard Chu -
Kurt Zeilenga -
masarati＠aero.polimi.it -
Michael Ströder -
Quanah Gibson-Mount