In setting up User Federation from an LDAP provider, there are three LDAP attributes:
Username LDAP attribute
RDN LDAP attribute
UUID LDAP attribute
How does the value of each of these impact Keycloak or the sync process?
For instance, if the directory ensures unique email addresses, are there any negatives to using mail as the UUID LDAP attribute?
Where can I find details on each of these attributes--specific to Keycloak?
In Keycloak admin console, you may hover over the tooltip - a tiny question mark - next to the LDAP attribute label if you want as much info as possible about it. I checked this on Keycloak v6.0.1 but I assume it applies to most recent versions. Such tooltip will often give more info than you can find on the Keycloak documentation website. More details about these attributes:
Username LDAP attribute: Name of LDAP attribute which is mapped as Keycloak username. For many LDAP server vendors it can be 'uid'. For Active Directory it can be 'sAMAccountName' or 'cn'. The attribute should be filled for all LDAP user records you want to import from LDAP to Keycloak. So there you could use the mail attribute if you want this as username in Keycloak. Then users would log on to Keycloak with their email address. If you enable LDAP synchronization to Keycloak local database (switch on Import Users), this will be recorded there as username.
RDN LDAP attribute: Name of LDAP attribute which is used as RDN (top attribute) of typical user DN. Usually it's the same as Username LDAP attribute, however it's not required. For example for Active directory it's common to use 'cn' as RDN attribute when username attribute might be 'sAMAccountName'. For example with a conventional LDAP directory (not Active Directory) where user DNs are typically uid=XXX,ou=people,dc=example,dc=com, you would use 'uid' there.
[EDIT 2019-05-31] The RDN attribute is actually used for instance when you create a new user in Keycloak. If you have the Edit Mode option set to WRITABLE in the settings, Keycloak synchronizes it back to the LDAP directory, i.e. creates the new user entry in LDAP. For that, it needs (among other things) the RDN and the Users DN (another option below the RDN) to make the full DN of the new user LDAP entry.
UUID LDAP attribute: Name of LDAP attribute which is used as unique object identifier (UUID) for objects in LDAP. For many LDAP server vendors, it's 'entryUUID' however some are different. For example for Active Directory it should be 'objectGUID'. If your LDAP server really doesn't support the notion of UUID, you can use any other attribute, which is supposed to be unique among LDAP users in tree. For example 'uid' or 'entryDN'. Any standard LDAP v3 directory should use entryUUID (OpenLDAP, OpenDJ...).
Regarding best practices on UUID in LDAP directories, you may look at the RFC 4530 standard.
In general, I would advise against using 'mail' as UUID, because a user's 'mail' may change (see reasons down below), whereas an entry UUID - whether it is a user entry or not - is meant to be a globally uniquely generated number (or at least contain such a number), usually generated on server side, and fixed once and for all for the entry. (Furthermore, it shall not be reused ever, even after the entry is deleted, as UUIDs should be unique in time and space.) In particular, it should be independent from any of the user's variable attributes, like email address.
Indeed, a user's email address may change during his/her lifetime in the organization for various reasons, just to name a few:
Users - women typically - may get married or divorced, and therefore may change their last name.
Top management decides to rebrand the company and therefore change the mail domain.
The company is going through a merger or an acquisition with/by another company and therefore the mail domain changes again.
...
Related
The requirement is to find user password expiration time.
Now in ldap, you enforce expiration through password policy.
The password policy attribute pwdMaxAge specifies after how many seconds from the time the password was changed does the password expire.
ldap password policy
The moment you change/create user password, the operational attribute pwdChangedTime gets added with the timestamp.
Sadly, ldap does not add any operational attribute for the expiration time, it's something we need to calculate, by doing a pwdChangedTime + pwdMaxAge < current_time
In your mods-enabled/ldap file you can fetch the pwdChangedTime attribute. Cool! But how do I fetch pwdMaxAge attribute. This file only has structure for users, groups, profiles, clients but not for the password policy. raddb mods-available details here.
(I can do this programmatically, by writing code/script for fetching these attributes using cli and then doing my manipulation, but is it possible doing this through the config? Coz, if you look at it, this expiration time is something related to user attribute and there should be a way to return it along with bare minimum user data like name and organization that we return)
Thanks!
There is no such operational attribute pwdMaxAge in the user's entry.
The password expiry warning during checking the password is returned by the server in a response control if the client sends the bind request with the appropriate request control (see draft-behera-ldap-password-policy, section 6.1 and 6.2).
This means that the LDAP client (FreeRADIUS in your case) has to support this. Furthermore all intermediate components (RADIUS server, Wifi access point, etc.) have to propely handle the response and return some useful information up the chain to the user. In practice this does not really work.
Therefore I'd recommend to send password expiry warning via e-mail. There are ready-to-use scripts out there like checkLdapPwdExpiration.sh provided by LDAP Tool Box project.
We have integrated Websphere commerce with LDAP and the proper login flow is working fine.
We have a requirement that user can have an option to login using his phone number and also his membership card.
Currently we are storing the ph.no and membership card in LDAP database also.
We are unable to use these fields for login as well. Can someone give some pointers on the same?
WAS has Standalone and Federated LDAP authentication.
Standalone LDAP configs in WebSphere allow you to construct your own LDAP search that's used to map a web username to a DN. You can list multiple attributes using LDAP filter syntax (|(phone=%v)(membershipcard=%v)...
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tsec_ldapfilter.html
Modify the user filter, if necessary. The user filter is used for
searching the registry for users and is typically used for the
security role-to-user assignment. The filter is also used to
authenticate a user with the attribute that is specified in the
filter. The filter specifies the property that is used to look up
users in the directory service. In the following example, the property
that is assigned to %v, which is the short name of the user, must be a
unique key. Two LDAP entries with the same object class cannot have
the same short name. To look up users based on their user IDs (uid)
and to use the inetOrgPerson object class, specify the following
syntax: (&(uid=%v)(objectclass=inetOrgPerson)
Federated registries take a semi-colon separated list of LDAP attribute names used for the same purpose.
https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twim_ldap_settings.html :
All login properties are searched during login. If multiple entries or
no entries are found, an exception is thrown. For example, if you
specify the login properties as uid;mail and the login ID as Bob, the
search filter searches for uid=Bob or mail=Bob. When the search
returns a single entry, then authentication can proceed. Otherwise, an
exception is thrown.
Both are covered in gory detail in the manual.
I like to request an advice about the configuration options in the WSO2 Identity Server to adjust the layout of a corporate LDAP directory and reuse it as a Secondary Read Only User store in the IdP. Is there a mapping function available that correlates the WSO2 field terminology to the context of the corporate directory, mapping the mandatory WSO2 identity fields like [ First Name, Last Name, Address, Phone Number and others]?
This question is complementary to my previous question about the access locking.
WSO2 Admin Secondary User Store - Delete Icon is not Working
Thanks in advance for your advice how to integrate an external LDAP repository.
You can use claim management in WSO2 identity server. In the Identity Server, each user store attribute can be mapped as a claim. Therefore, you can use the claim management functionality available in the Identity Server and properly map your LDAP/AD/JDBC user store attributes with the claim URIs defined by the Identity Server. You can also add different claim URIs and manage them using claim management.
Please refer the below links to find how to do user attribute mapping.
https://docs.wso2.com/display/IS500/Managing+User+Attributes
https://docs.wso2.com/display/IS500/Adding+New+Claim+mapping
You can add your corporate LDAP directory as secondary user store.
You can follow the below steps to configure secondary user stores manually or using the management console:
configure the [IS_HOME]\repository\conf\user-mgt.xml file as given below.
Using management console:
Log in to the management console and click User Store Management sub menu under Configure menu.
List item
The User Store Management page opens
Click Add Secondary User Store.
In the User Store Manager Class list, select the type of user store you are creating (in here u can populate this drop-down list with custom user store manager implementations by adding them to the server.)
Enter a unique domain name with no underscore (_) characters, and optionally enter a description for this user store.
Enter values for the properties, using the descriptions in the Descriptions column for guidance. The properties that appear vary based on the user store manager class you selected, and there may be additional properties in an Optional or Advanced section at the bottom of the screen.
Ensure that all the mandatory fields are filled and a valid domain name is given and click Add.
A message appears saying that the user stores are being added. (The message does not imply that the user store is added successfully. It simply means that the server is attempting to add the new user store to the end of the available chain of stores.)
Refresh the page after a few seconds to check the status.
If the new user store is successfully added, it will appear in the User Store Management page.
After adding to the server, you can edit the properties of the new secondary user store and enable/disable it in a dynamic manner.
Using manually:
You can find the primary user store configuration in [IS_HOME]\repository\conf\ the user-mgt.xml file. When you create a secondary user store using the management console, its configuration is saved to an XML file with the same name as the domain name you specify. Alternatively, you can create this XML file manually and save it as follows:
When you configure multiple user stores, you must give a unique domain name to each user store in the <domainname> element. If you configure a user store without specifying a domain name, the server throws an exception at start up.
If it is the configuration of a super tenant, save the secondary user store definitions in <product_home>/repository/deployment/server/userstores directory.
If it is a general tenant, save the configuration in <product_home>/repository/tenants/<tenantid>/userstores directory.
The secondary user store configuration file must have the same name as the domain with an underscore (_) in place of the period. For example, if the domain is wso2.com, name the file as wso2_com.xml.
One file only contains the definition for one user store domain.
You can follow the below steps:
I have specified the LDAP filter option as uid=${username} to get the username. I also need to get other attributes such as organization, telephone no, email etc.. I have only one LDAP store configured in my system. I know all the configuration steps to acheive it. I am struck with the LDAP filter to get those attributes. That's where I am getting error.
for eg, in order to get organization, I should give something like o=${SOMETHING}
How to provide the filter?
Please let me know.
Thanks,
Aswini J
I'm assuming you have already specified in the Assertion Mapping screen that you wish to "Retrieve Additional Attributes" and that you then added your existing LDAP Data Store.
The filter is simply used to locate a single user's record that you wish to return the associated attributes from. In the previous Admin screen (LDAP Directory Search) is where you specify the user attributes you wish to return. You simply specify your LDAP Base DN and then select the attributes from the drop-down list. You can find more information in the Admin Guide -
http://documentation.pingidentity.com/display/PF73/Configuring+an+LDAP+Directory+Search#ConfiguringanLDAPDirectorySearch-2232188
After choosing the attributes, you then get to setup your LDAP Filter where something as simple as "uid=${username}" will usually suffice. It really depends on what user identifier is coming in from your IDP Adapter and how specify that lookup needs to be. If you're using the HTMLForm Adapter, then chances are your users are entering their LDAP userID values.
I'm interested in how other people code this because I'm either not understanding it properly or I'm missing something or perhaps even I'm doing it right!
First of all, this is NOT an Active Directory instance of LDAP its OpenDS which other than some syntactical differences shouldn't much matter.
So assume I have my tree structure setup something like this:
-dc=somedomain,dc=com
-uid=rootuser
-ou=Group1
-uid=username1
-uid=username2
-ou=Group2
-uid=username3
-uid=username4
In order to authenticate as the 'rootuser' I would need to pass the fully qualified Username when I create my System.DirectoryServices.DirectoryEntry object, in this case:
uid=rootuser,dc=somedomain,dc=com
but for any other user in the tree I have to know in advance what LDAP path to append to the username to have them authenticate thru. So for example this will fail:
uid=username1,dc=somedomain,dc=com
but this will work:
uid=username1,dc=somedomain,dc=com,ou=Group1
So my question is how do you handle this when you don't know at login time what specific group a user belongs to to build that path? The only way I can figure to do it is to make the initial call as 'rootuser' so I have access to the entire tree then use System.DirectoryServices.DirectorySearcher to scan it for that particular user (i.e. username1)
using (DirectorySearcher searcher = GetDirectorySearcher()) {
searcher.Filter = "(&(objectClass=person)(uid=" + userName+ "))";
SearchResult result = searcher.FindOne();
return result.GetDirectoryEntry().Path;
}
at that point I have the path for the user I want to login and I can proceed with the actual auth. Am I way off base here or is this generally how it is done?
thanks!
You build a search filter on attributes that are unique to the user, e.g. screen-name, e-mail. Make sure LDAP is configured to ensure they are unique. Then you find the corresponding entry if any, get the DN, and rebind as that user with the appropriate password. If there was no such entry you react accordingly.
You don't say what language you are using, but in JNDI that means setting the DN as the security principal, the password as the credentials, and calling LdapContext.reconnect().
SASL supports the notion of using a username to authenticate. Your directory server administrator may be able to configure the directory server to map distinguished names to identities. Given the correct mapping it is possible for a client to authenticate without knowing the distinguished name. Professional-quality directory servers support a number of different mapping mechanisms such as direct mapping, exact match, regular expression, or a custom identity mapper.