Username, email, first and last name and other mapped attributes will be unchangeable.
{{book.project.name}} will show an error anytime anybody tries to update these fields.
Also, password updates will not be supported.
WRITABLE::
Username, email, first and last name, other mapped attributes and passwords can all be updated and will be synchronized automatically with your LDAP store.
UNSYNCED::
Any changes to username, email, first and last name, and passwords will be stored in {{book.project.name}} local storage.
The global truststore for the {{book.project.name}} can be configured with Truststore SPI. Please check out the link:{{book.installguide.link}}[{{book.installguide.name}}] for more detail.
If you don't configure truststore SPI, the truststore will fallback to the default mechanism provided by Java (either the file provided by system property `javax.net.ssl.trustStore`
or the cacerts file from JDK if the system property is not set).
There is configuration property `Use Truststore SPI` in the LDAP federation provider configuration, where you can choose whether the Truststore SPI is used.
By default, the value is `ldaps only`, which is fine for most of deployments. The Truststore SPI will only be used
if the connection to LDAP starts with `ldaps`.
==== Sync of LDAP users to {{book.project.name}}
LDAP Federation Provider will automatically take care of synchronization (import) of needed LDAP users into the {{book.project.name}} local database.
As users log in, the LDAP Federation provider will import the LDAP user
into then {{book.project.name}} database and then authenticate against the LDAP password. This is the only time users will be imported.
have been authenticated at least once by {{book.project.name}}. It is implemented this way so that admins don't accidentally try and import a huge LDAP DB of users.
If you want to sync all LDAP users into the {{book.project.name}} database, you may configure and enable the `Sync Settings` of the LDAP provider you configured.
then set up a periodic sync of changed users. The configuration page for your LDAP Provider has a bunch of options to support you here.
[[_ldap_mappers]]
==== LDAP/Federation mappers
LDAP mappers are `listeners`, which are triggered by LDAP Federation provider at various points and provide another extension point to LDAP integration.
They are triggered when a user logs in via LDAP and needs to be imported, during {{book.project.name}} initiated registration, or when a user is queried from the Admin Console
When you create an LDAP Federation provider, {{book.project.name}} will automatically provide set of builtin `mappers` for this provider.
You are free to change this set and create new mapper or update/delete existing ones.
User Attribute Mapper::
This allows you to specify which LDAP attribute is mapped to which attribute of {{book.project.name}} User.
So, for example, you can configure that LDAP attribute `mail` to the attribute `email` in {{book.project.name}} database.
For this mapper implementation, there is always one-to-one mapping (one LDAP attribute is mapped to one {{book.project.name}} attribute)
This allows to specify that the full name of user, which is saved in some LDAP attribute (usually `cn` ) will be mapped to `firstName` and `lastname` attributes in the {{book.project.name}} database.
Having `cn` to contain full name of user is common case for some LDAP deployments.
Role Mapper::
This allows to configure role mappings from LDAP into {{book.project.name}} role mappings.
One Role mapper can be used to map LDAP roles (usually groups from particular branch of LDAP tree) into roles corresponding to either realm roles or client roles of specified client.
It's not a problem to configure more Role mappers for same LDAP provider.
So for example you can specify that role mappings from groups under
`ou=main,dc=example,dc=org` will be mapped to realm role mappings and role mappings from groups under
`ou=finance,dc=example,dc=org` will be mapped to client role mappings of client `finance` .
Hardcoded Role Mapper::
This mapper will grant specified {{book.project.name}} role to each {{book.project.name}} user linked with LDAP.
Group Mapper::
This allows to configure group mappings from LDAP into {{book.project.name}} group mappings.
Group mapper can be used to map LDAP groups from particular branch of LDAP tree into groups in {{book.project.name}}.
And it will also propagate user-group mappings from LDAP into user-group mappings in {{book.project.name}}.
MSAD User Account Mapper::
This mapper is specific to Microsoft Active Directory (MSAD). It's able to tightly integrate the MSAD user account state
into the {{book.project.name}} account state (account enabled, password is expired etc).
It's using the `userAccountControl` and `pwdLastSet` LDAP attributes. (both are specific to MSAD and are not LDAP standard).
For example if `pwdLastSet` is `0`, the {{book.project.name}} user is required to update their password
and there will be UPDATE_PASSWORD required action added to the user. If `userAccountControl` is
`514` (disabled account) the {{book.project.name}} user is disabled as well.
By default, there is set of User Attribute mappers that map basic {{book.project.name}} user attributes like username, first name, lastname and email to corresponding LDAP attributes.
You are free to extend these and provide additional attribute mappings.
Admin console provides tooltips, which should help on how to configure corresponding mappers.
