This adds debugging statements and debugging documentation to help troubleshoot problems with ldap role establishment. This also adds ldap profiles for esvm
Original commit: elastic/x-pack-elasticsearch@a1f1cbd830
* Configuring the transport pipeline has changed due to adding profiles in 1.4
* Lots of tests needed to be changed in order to not leave thread pools around
* ApacheDs leaves a thread lingering around, thus a ThreadLeakFilter needed to be added
Original commit: elastic/x-pack-elasticsearch@de35362fc4
Also added a ShieldBuild class to return
* Shield version
* Shield build hash
* Shield build timestamp
Also added a '/_shield' endpoint which returns those fields.
Original commit: elastic/x-pack-elasticsearch@38928d1ef6
Now it logs the failure on debug and on trace it also logs the full stack trace. There's no point in logging it on info as a lot of the failures that will be logged are just fine (e.g. esusers will fail to authenticate and log the failure, but LDAP will succeed). This logging should only be applied for debugging purposes... for normal logging we have the audit logs
While at it, also cleaned up the Ldap realm code... change java.lang.SecurityException to shield's LdapException
Closeselastic/elasticsearch#281
Original commit: elastic/x-pack-elasticsearch@d5f0ad2efb
- Changed the behaviour of esusers realm so that whenever the `users` or the `users_roles` file are updated, the realm's cache expunges
- Changed LDAP realm such that when the `role_mapping.yml` file is updated, the realm's cache expunges
Also, cleaned up unused code (mainly around esusers and the different stores)
Original commit: elastic/x-pack-elasticsearch@3f093207da
Fixes a bug where the wrong exception and wrong error status code (500) were returned when the user sent the wrong username/password. This fixes this beahviour to return an `AuhthenticationException` with a 401 status code.
Fixeselastic/elasticsearch#271
Original commit: elastic/x-pack-elasticsearch@0a120caeae
We now moved from the logic of checking `indices:` and `cluster:` prefixes to determine whether an action is an indices or a cluster action... instead we use the index/cluster privielge `all` privilege to determine that (which is more accurate in the context of shield, as it enables us to move actions between the two categories while keeping their logical name intact)
Also updated the docs to reflect that template related actions are infact cluster actions.
Original commit: elastic/x-pack-elasticsearch@8027334105
Added `shield.user` setting so that the clients won't need to go through the unnatural and tedious process of configuring the `Authorization` header directly (that also requires the user to applicat the base64(username:password) logic.
Now, the user can just set the following settings to bind a user to the client:
```yaml
shield.user: 'username:password'
```
Original commit: elastic/x-pack-elasticsearch@94be3abd92
Enforcing means that cluster actions will not be evaluated (as a fallback) by Index permissions. This enables us to move what typically would be considered indices actions and put them under the cluster privileges (a good example for this are all the template management APIs... we want to enforce cluster admin privileges over them).
Original commit: elastic/x-pack-elasticsearch@ee870954f2
Also added a logstash configuration for simple performance
testing (useful for comparing different hash functions)
Original commit: elastic/x-pack-elasticsearch@c9f08fbb12
Now the passwords are hashed in-memory using SHA2 by default (instead of original bcrypt). Also, it's now possible to configure the in-memory hashing algorithm.
Original commit: elastic/x-pack-elasticsearch@e2d1b3116b
Now, there are two types of supported patters:
- wildcards (default) - simple wildcard match where `*` indicates zero or more characters and `?` indicates a single character (`\` can be used as an escape charachter)
- regular expressions - can be "enabled" by wrapping the pattern in `/` (e.g. `/foo.*/`). The regex syntax is based on lucene's regex syntax (not Java's Pattern).
Closeselastic/elasticsearch#253
Original commit: elastic/x-pack-elasticsearch@edd912122d
This lets the url be configured as a single element (the most likely usage) or as an array. This also checks that multiple urls are either all "ldaps", or all "ldap", as it is not possible to mix them.
Original commit: elastic/x-pack-elasticsearch@b5a94b1d35
The evalutation of the indices permission groups was wrong. Now, each index in the request is evaluated against all groups, such that:
1. for each index, at least one group must grant the request
2. all indices must be granted
Along the way, also changed the audit logs structures such that:
- moved the principal to "sit" next to the host
- now, if we're logging an indices request, we also log the related indices (this provides more context to the actual request)
Fixeselastic/elasticsearch#242
Original commit: elastic/x-pack-elasticsearch@95600d3148
- `BCRYPT`, `MD5`, `SHA1`, `SHA2`,
- Also removed the support for bcrypt minor version y (i.e. $2y$) as it's not supported by our BCrypt implementation
Original commit: elastic/x-pack-elasticsearch@12cf024a59
Changed URL default to ldaps and port 636. No mode now defaults to ldap.
Added miscelleneous documentation for active directory. Incorrect mode now
throws an exception
Original commit: elastic/x-pack-elasticsearch@0239380668
c-a-m
Alexander Reelsen
uboness
Paul Echeverri
Suyog Rao