@fraxx @marcosegat @emanuele
Would you check your LDAP settings in .env.local against the following detailed explanations of each of them, to make sure they’re what the LDAP login framework (of the version Suite is using) is expecting, and post back your results:
type: string default: ldap
This is the name of your configured LDAP client. You can freely choose the name, but it must be unique in your application and it cannot start with a number or contain white spaces.
type: string default: null
This is the base DN for the directory
type: string default: null
This is your read-only user’s DN, which will be used to authenticate against the LDAP server to fetch the user’s information.
type: string default: null
This is your read-only user’s password, which will be used to authenticate against the LDAP server to fetch the user’s information.
type: array default: []
This is the default role you wish to give to a user fetched from the LDAP server. If you do not configure this key, your users won’t have any roles, and will not be considered as authenticated fully.
type: string default: null
This is the entry’s key to use as its UID. Depends on your LDAP server implementation. Commonly used values are:
sAMAccountName (default)userPrincipalNameuid
If you pass null as the value of this option, the default UID key is used sAMAccountName.
type: array default: null
Defines the custom fields to pull from the LDAP server. If any field does not exist, an \InvalidArgumentException will be thrown.
type: string default: null
This key lets you configure which LDAP query will be used. The {uid_key} string will be replaced by the value of the uid_key configuration value (by default, sAMAccountName), and the {username} string will be replaced by the username you are trying to load.
For example, with a uid_key of uid, and if you are trying to load the user fabpot, the final string will be: (uid=fabpot).
If you pass null as the value of this option, the default filter is used ({uid_key}={username}).
To prevent LDAP injection, the username will be escaped.
The syntax for the filter key is defined by RFC4515.
Authenticating against an LDAP server can be done using either the form login or the HTTP Basic authentication providers.
They are configured exactly as their non-LDAP counterparts, with the addition of two configuration keys and one optional key:
type: string default: ldap
This is the name of your configured LDAP client. You can freely choose the name, but it must be unique in your application and it cannot start with a number or contain white spaces.
type: string default: {username}
This key defines the form of the string used to compose the DN of the user, from the username. The {username} string is replaced by the actual username of the person trying to authenticate.
For example, if your users have DN strings in the form uid=einstein,dc=example,dc=com, then the dn_string will be uid={username},dc=example,dc=com.
type: string default: null
This (optional) key makes the user provider search for a user and then use the found DN for the bind process. This is useful when using multiple LDAP user providers with different base_dn. The value of this option must be a valid search string (e.g. uid="{username}"). The placeholder value will be replaced by the actual username.
When this option is used, query_string will search in the DN specified by dn_string and the DN resulted of the query_string will be used to authenticate the user with their password. Following the previous example, if your users have the following two DN: dc=companyA,dc=example,dc=com and dc=companyB,dc=example,dc=com, then dn_string should be dc=example,dc=com.
Bear in mind that usernames must be unique across both DN, as the authentication provider won’t be able to select the correct user for the bind process if more than one is found.