You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.adoc
+30-17Lines changed: 30 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,22 +75,27 @@ The content of the configuration file is as follows:
75
75
|service_password
76
76
|Service user password
77
77
78
-
|ldap_naming_attribute
79
-
|Use this setting if you need to change your naming attribute from the usual cn=
78
+
|filter_template
79
+
|template for searching in LDAP, explanation further in this readme, defaults to `(cn=%s)`
80
80
81
81
|auth_cache_enabled
82
82
|relevant for Cassandra 3.11 and 4.0 plugins, defaults to `false`
83
83
84
+
|consistency_for_role
85
+
|consistency level to use for retrieval of a role to check if it can log in - defaults to LOCAL_ONE
86
+
84
87
|auth_bcrypt_gensalt_log2_rounds
85
88
|number of rounds to hash passwords
89
+
90
+
|load_ldap_service
91
+
|defaults to false, if it is true, SPI mechanism will look on class path to load custom implementation of `LDAPUserRetriever`.
86
92
|===
87
93
88
94
89
95
## Configuration of Cassandra
90
96
91
97
If is *strongly* recommended to use `NetworkTopologyStrategy` for your `system_auth keyspace`.
92
98
93
-
94
99
Please be sure that `system_auth` keyspace uses `NetworkTopologyStrategy` with number of replicas equal to number of nodes in DC. If it is not
95
100
the case, you can alter your keyspace as follows:
96
101
@@ -145,7 +150,15 @@ For fast testing there is Debian OpenLDAP Docker container
145
150
The `ldap.configuration` file in the `conf` directory does not need to be changed, and with the above `docker run` it will work out of the box. You just
146
151
have to put it in `$CASSANDRA_CONF` or set respective configuration property as described above.
147
152
148
-
## How It Works
153
+
## Explanation of filter_template property
154
+
155
+
`filter_template` property is by default `(cn=%s)` where `%s` will be replaced by name you want to log in with.
156
+
For example if you do `cqlsh -u myuserinldap`, a search filter for LDAP will be `(cn=myuserinldap)`. You
157
+
may have a different search filter based on your need, a lot of people use e.g. SAM or something similar.
158
+
If you try to log in with `cqlsh -u cn=myuserinldap`, there will be no replacement done and this will be
159
+
used as a search filter instead.
160
+
161
+
## How it Works
149
162
150
163
LDAPAuthenticator currently supports plain text authorization requests only in the form of a username and password.
151
164
This request is made to the LDAP server over plain text, so you should be using client encryption on the Cassandra
@@ -165,14 +178,8 @@ the operator still has a possibility of logging in via `cassandra` user as usual
165
178
Users meant to be authenticated against the LDAP server will not be able to log in but all "normal" users will be able to
166
179
login and the disruption of LDAP communication will not affect their ability to do so as they live in Cassandra natively.
167
180
168
-
In case there are two logins of same name (e.g. `admin` in LDAP and `admin` in C*),
169
-
in order to distinguish them, if you want to login with LDAP user, you have to
170
-
specify its full account name, e.g.
171
-
172
-
cqlsh -u cn=admin,dn=example,dn=org
173
-
174
-
In case a user specifies just `admin` as login name (or any other name, for that matter), it will try to
175
-
authenticate against database first and if not successful against LDAP, adding all details (cn= etc. ...) to username automatically.
181
+
In case a user specifies just `test` as login name (or any other name, for that matter), it will try to
182
+
authenticate against database first and if not successful against LDAP using filter `filter_template` which defaults to `(cn=%s)`
176
183
177
184
It is possible to delete administration role (e.g. role `cassandra`) but if one does that, all administration operations are only able to
178
185
be done via LDAP account. In case LDAP is down, the operator would not have any control over DB as `cassandra` is not present anymore.
@@ -184,21 +191,27 @@ If you delete `cassandra` user, there is suddenly not such user. You have to res
184
191
185
192
Where `dba` is _new_ superuser which is able to write to `system_auth.roles` and acts as Cassandra admin.
186
193
194
+
Upon login via LDAP user, this plugin will create a dummy role just to be able to play as a normal Cassandra role
195
+
with all its permissions and so on. Passwords for LDAP users are not stored in Cassandra, obviously.
196
+
197
+
Credentials are cached for implementations for Cassandra 3.11 and 4.0 so that way we are not hitting LDAP server
198
+
all the time when there is a lot of login attempts with same login name. An administrator can increase
199
+
relevant validity settings in `cassandra.yaml` to increase these periods even more.
200
+
187
201
## SPI for LDAP server implementations (advanced)
188
202
189
203
In order to talk to a LDAP server, there is `DefaultLDAPServer` class in `base` module which all modules are using.
190
204
However, it might not be enough - there is a lot of LDAP servers out there and their internals and configuration
191
205
might render the default implementation incompatible. If you have special requirements, you might provide your
192
-
own implementation by extending `DefaultLDAPServer` and overriding what is necessary. You might as well
193
-
extend and implement `LDAPPasswordRetriever` class. `DefaultLDAPServer` just extends it.
206
+
own implementation by implementing `LDAPUserRetriever`. You have to have `load_ldap_service` set to `true` as well.
194
207
195
208
To tell LDAP plugin to use your implementation, you need to create a file in `src/main/resources/META-INF/services`
196
-
called `com.instaclustr.cassandra.ldap.auth.LDAPPasswordRetriever` and the content of that file needs to
209
+
called `LDAPUserRetriever` and the content of that file needs to
197
210
be just one line - the fully qualified class name (with package) of your custom implementation.
198
211
199
212
After you build such plugin, the SPI mechanism upon plugin's initialisation during Cassandra node startup
200
213
will pick up your custom LDAP server connection / authentication logic.
201
214
202
215
## Further Information
203
-
- See blog by Kurt Greaves https://www.instaclustr.com/apache-cassandra-ldap-authentication/[Apache Cassandra LDAP Authentication]
204
-
- Please see https://www.instaclustr.com/support/documentation/announcements/instaclustr-open-source-project-status/ for Instaclustr support status of this project
216
+
- See blog by Stefan Miklosovic about https://www.instaclustr.com/the-instaclustr-ldap-plugin-for-cassandra/[Apache Cassandra LDAP Authentication]
217
+
- Please see https://www.instaclustr.com/support/documentation/announcements/instaclustr-open-source-project-status/[Instaclustr support status] of this project
0 commit comments