Open victron opened 2 years ago
Hi, I think it was done like that because admin is the one who is performing search. We first seach in ldap to filter a user. Then we use that user (its name) together with password on cqlsh to try to authenticate. For that reason, that we search first, I think we need somebody with admin rights who is able to scan ldap tree. It is not automatically given that you can scan the tree under every "ordinary" user. But admin can.
I think we need somebody with admin rights who is able to scan ldap tree.
yes, exactly.
but I still don't understand why it need to do search at all?
we can create filter in config like this cn=%s,dc=example,dc=org
and using it format string based on username. This string will be a dn.
Then during login user test
pluging will request auth. directly cn=test,dc=example,dc=org
.
I understand that we need admin to manipulate with system_auth
keyspace. But
My main question why pluging doing search in LDAP at all? Why not to allow LDAP replay with error if there are no such dn?
Not sure to be honest, I ll try it when I have time. Thanks for the idea.
below simple patch to test idea, now in logs only what I expected. Hope it helps. May be it reasonable to add some additional config option to keep compatibility. Some people could really have complicated LDAP tree, but mostly have simple.
[vic@cOs2 cassandra-ldap]$ git diff master
diff --git a/base/src/main/java/com/instaclustr/cassandra/ldap/auth/DefaultLDAPServer.java b/base/src/main/java/com/instaclustr/cassandra/ldap/auth/DefaultLDA
index 461aa1d..d244ccc 100644
--- a/base/src/main/java/com/instaclustr/cassandra/ldap/auth/DefaultLDAPServer.java
+++ b/base/src/main/java/com/instaclustr/cassandra/ldap/auth/DefaultLDAPServer.java
@@ -182,9 +182,10 @@ public class DefaultLDAPServer extends LDAPUserRetriever
@Override
public User retrieve(User user) throws LDAPAuthFailedException
{
- try (final LDAPInitialContext context = new LDAPInitialContext(properties))
+ try
{
- final String ldapDn = context.searchLdapDN(user.getUsername());
+ final String filterTemplate = properties.getProperty(LdapAuthenticatorConfiguration.FILTER_TEMPLATE);
+ final String ldapDn = format(filterTemplate, user.getUsername());
logger.debug(String.format("Resolved LDAP DN: %s", ldapDn));
diff --git a/conf/ldap.properties b/conf/ldap.properties
index b6091e8..0ba4d3d 100644
--- a/conf/ldap.properties
+++ b/conf/ldap.properties
@@ -14,7 +14,7 @@ service_dn: cn=admin,dc=example,dc=org
service_password: admin
# filter used for searching in LDAP, "%s" is placeholder, it will be replaced by login name
-filter_template: (cn=%s)
+filter_template: cn=%s,dc=example,dc=org
# True by default, tells whether internal cache of user -> password combination will be used
# This option is irrelevant for Cassandra version <= 3.0
A property in config to turn this on would be nice. Feel free to complete the patch with introducing a flag so we do not need to search.
Please answer these questions before submitting your issue. Thanks!
What version of Cassandra are you using?
3.11
What version of Cassandra LDAP are you using?
v3.11.11-1.0.0
What LDAP server you are using? Any specifics?
osixia/docker-openldap
What did you do?
simple authentication for user
test
What did you expect to see?
in ldap server logs I expect to see only this logs
What did you see instead?
before expected logs I see this logs
I suspect this is related to this line in README:
My question:
admin
user beforetest
user authentication? For me it looks like an additional load to ldap server and could have some hidden security issue.