LDAP
How to log into fylr with accounts of your LDAP service.
LDAP is an authentication service that you might already have, to hold your users' accounts centrally. It is part of Microsoft Active Directory (predecessor to Azure Active Directory) and available as a separate service (OpenLDAP).
You need a fylr licence including Authentification to use LDAP. To enable fylr users to log in with LDAP accounts, scroll the User Management page to LDAP, above SAML:
Here is an example configuration with the public test provider ldap.forumsys.com:
URL: Do not forget the protocol, in this case, ldap://. This could also be ldaps://.
Allow insecure connection: Can be safe if security is done by other means, e.g. fylr and LDAP server are running internally.
Bind User: An LDAP user, which fylr uses to search for other users and groups. Does not need administrative privileges.
Bind Password: Password of the Bind User.
User Base DN: Organizatinal Unit or whole organization, in which to search for users. All users who shall be able to log in must be inside this unit. Bind User does not have to be inside this unit. Example: OU=Users,DC=example,DC=com .
User filter: Which LDAP attribute shall be compared to the login string (which is entered during fylr login)? For example if I am Albert Einstein and my login username ist einstein: Which LDAP attribute contains the string einstein? In the example above: the attribute uid is compared to the login given by the user. So if I enter einstein and my password, fylr then searches for LDAP objects which have the attribute uid with value einstein in that attribute. If one is found, the password of that LDAP object is also checked and if correct, this LDAP object is considered logged in. fylr creates a fylr user (if not already existing) that is considered connected to this LDAP object. For this scenario, the user filter (uid=%(login)s) is enough. To reduce search time and number of objects searched, the example in the screenshot additionally restricts the search to only LDAP objects of objectClass = person.
USER MAPPING
+: Add another mapped Attribute. We suggest Display Name and EMail.
Target: Choose one, at least Login.
Value: Enter one or more LDAP attributes, each given between %( and)s. Upper case / lower case is important here, even if it is not important inside your LDAP Directory!
If in doubt, which LDAP attributes can be used between %( and ) during User Mapping, set fylr's log level to at least debug and pick attributes from the log output after a LDAP search. It looks like:
So, usable attributes in this example are DN, objectClass, cn, sn, uid, mail and telephoneNumber.
Group settings
We recommend to only configure group settings after the above settings are working to log in. Group settings are optional.
Group Base DN: Organizational Unit or whole organization, in which to search for groups. Example: OU=Groups,DC=example,DC=com .
Group Filter: Here, entere a search expression to find the LDAP objects to look at when deciding group membership. You can use attributes of the user here, e.g. cn, in the syntax %(cn)s - but you have to use it in an evaluation. In other words, compare it to another attribute with =.
Example: To compare all attributes named member, use as Group Filter: (member=%(cn)s). This will result in all objects that have the user's cn in an attribute called member.
For the context of ldap.forumsys.com, the distinguished name (usable as DN) is in the group attribute uniqueMember.
So (uniqueMember=%(DN)s) could work. But to not evaluate all objects, or in other words, to evaluate only groups, we add the object class: (&(objectClass=groupOfUniqueNames)(uniqueMember=%(DN)s)). This was successfully tested with ldap.formusys.com.
Another example, from a different LDAP installation:
(&(member=%(distinguishedName)s)(objectClass=group)) .
Now you have narrowed the comparison to a few objects, likely groups. Next step: Which attribute of these objects shall be compared during matching of fylr groups to LDAP groups? This is determined in Group Mapping:
Group Mapping: Which attribute to look at when matching groups. Look at the (final) next step for an example. To use e.g. the group's common name, use %(cn)s here, which works with ldap.forumsys.com.
If in doubt, which LDAP attributes can be used between %( and ), set the log level of fylr to at least debug and pick attributes from the log output after a LDAP search. It looks like:
So, usable attributes in this example are DN, uniqueMember, cn, ou and objectClass.
Final step: Matching an LDAP group to a fylr group:
In a fylr group's settings, enter a string that matches one LDAP group. For the example of ldap.forumsys.com, we created the fylr group
scientistsand since we chosecnabove in Group Mapping, we now have to use the stringScientists, as this is the value in that group's common name (cn). In the fylr frontend this is done here:So now, when the ldap.forumsys.com's user
einsteinornewtonlogs into this fylr, they will be automatically in the fylr groupscientistsand enjoy all the group's system rights and permissions in fylr.
Walk the chain of ancestry
In case your group filter does not give the results you expect, you can try to use LDAP_MATCHING_RULE_IN_CHAIN in the group search filter.
Example:
The string 1.2.840.113556.1.4.1941 specifies LDAP_MATCHING_RULE_IN_CHAIN. This applies only to DN attributes. This is an extended match operator that walks the chain of ancestry in objects all the way to the root until it finds a match. This reveals group nesting. It is available only on domain controllers with Windows Server 2003 SP2 or Windows Server 2008 (or above).
Usually, this is not needed, but it was needed for customers that are used to how Cumulus does LDAP group search.
Last updated
