While ldapsearch doesn't seem to mind, apps like keycloak seem to have
issues with adding multiple attributes with different values. While
the resulting ldif in ldapsearch is indistinguishable there seems to
be a slight different on the protocol level.
If adding multiple attributes with the same name and different values,
keycloak will only see the last entry. But adding a single attribute
a slice of values is seems to handle it correctly.
This adds support for more hash algorithms. Also a stored password will
be updated to SSHA512 upon a successful bind. It will also automatically
hash a cleartext password if the `userpassword` field is modified with
a cleartext one.
Hashes supported:
* SSHA
* SSHA256
* SSHA512
The problem was the encode in `name += string(alphabet[])`
It takes only 1 byte but the characters like 'è','@' are encoding
on several bytes (1 to 4 bytes).
The better solution was to create a slice of string, like this
we don't have problem about take only one byte instead of 2,3 or 4
bytes.
V2 the test end-to-end,
Tests made similar to V1.0,
Add the possibility to pararellize the tests,
Create an environnement for easy integration of news test,
Tests wrote in golang without framework Testing on the Bottin's behavior
Tests made:
- crated random Users and Group - LDAP ADD
- check the match between Consul's data and Test's data- LDAP
Search
- modify attributes and check them -
LDAP Modify
- DNs are always used in canonical form: lowercase, no spaces. This is
how they are internally handled and stored in paths and fields such as
member and memberof
- Attribute names now can have any combination of lower/uppercase and
stuff should work
- When modifying an attribute with a name that hase a different
lower/upper combination than the previously stored value, keep the
previous attribute name
- Trim spaces from values and do not store empty values
