User has no profile in this organization message received when user authenticates in AM (All versions)

Last updated Jan 16, 2023

The purpose of this article is to provide assistance if you receive a "User has no profile in this organization" or "Profile not found" error when a user authenticates in AM. This issue may affect you if you use either an LDAP or Active Directory® authentication module.

2 readers recommend this article

Symptoms

The following message is shown when the user successfully authenticates to AM:

User has no profile in this organization

An error similar to the following is shown in the Authentication log:

amAuth:04/08/2015 14:17:45:076 PM UTC: Thread[http-apr-7077-exec-53,5,main] ERROR: Profile not found

Recent Changes

Implemented an LDAP or Active Directory authentication module.

Made configuration changes to your Authentication modules or user store.

Moved a user to a different Organizational Unit (OU) in Active Directory.

Deleted and then re-added a user in Active Directory.

Causes

AM cannot find the user and associated user profile in the user store once the user has authenticated. This can be caused by one of the following:

Misconfiguration of the authentication module and/or user store - this is likely to be the cause if the error appeared after implementing an authentication module or making configuration changes to an existing authentication module or user store.
Authentication module and user store have conflicting attributes - this is likely to be the cause if the error appeared after setting iplanet-am-auth-ldap-return-user-dn=true in your authentication module.

Example conflicting attributes are: iplanet-am-auth-ldap-return-user-dn=true sun-idrepo-ldapv3-config-users-search-attribute=uid iplanet-am-auth-alias-attr-name=uid

When iplanet-am-auth-ldap-return-user-dn is set to true, AM uses Active Directory as the source for the user Profile Store, which means the Active Directory authentication module will return the DN, not the User ID. See the Solution and Active Directory module properties (Return User DN to DataStore) for further details.

Caching - this is likely to be the cause if the error appeared after moving or deleting/re-adding a user in Active Directory.

Note

This error only occurs if the profile is set to required in the core authentication service. You can change this if you do not rely on user profile information for authentication by navigating to: Realms > [Realm Name] > Authentication > Settings > User Profile > User Profile and selecting Ignore.

Solution

The solution depends on the cause.

Misconfiguration of the authentication module and/or user store

You should check your Authentication module and user store configuration is correct. In particular, you should check the following specific properties:

Search and Naming Attributes - The Search and Naming Attributes specified in your LDAP or Active Directory authentication module configuration must match your user store configuration, otherwise you will see this error. A common cause is changing AM to use a different search attribute without updating your authentication module to use the alternate search attribute.
Search Scope - The Search Scope determines what level to search at for a matching user profile in the user store. This should be set to SUBTREE, which searches the base DN and all levels below as this ensures it will find the user profile assuming it exists. Other settings are OBJECT (only searches the Base DN) and ONELEVEL (only searches the single level below, but not the Base DN).

Note

AM will search all user stores for a matching user profile. If you have multiple user stores, it is recommended that you use different naming attributes for each user store as AM merges user attributes if multiple user stores contain the same naming attribute=value combination. If you update naming attributes in a user store, you will need to make corresponding changes to the relevant authentication module.

You can check the Search and Naming attributes in the user store using the AM admin UI or ssoadm:

AM admin UI: navigate to: Realms > [Realm Name] > Data Stores > [Data Store].
ssoadm: enter the following command: $ ./ssoadm show-datastore -e [realmname] -m [datastorename] -u [adminID] -f [passwordfile] replacing [realmname], [datastorename], [adminID] and [passwordfile] with appropriate values.

The values you are looking for are: LDAP Users Search Attribute (sun-idrepo-ldapv3-config-users-search-attribute) and Authentication Naming Attribute (sun-idrepo-ldapv3-config-auth-naming-attr). You can use the update-datastore ssoadm command to change these properties if needed.

You can check the Search and Naming attributes, and the Search Scope in the LDAP or Active Directory authentication module using the AM admin UI or ssoadm:

AM admin UI: navigate to: Configure > Authentication > LDAP or Active Directory.
ssoadm: enter the following command: $ ./ssoadm get-attr-defs -s [servicename] -t Organization -u [adminID] -f [passwordfile] replacing [servicename], [adminID] and [passwordfile] with appropriate values, where [servicename] is iPlanetAMAuthLDAPService (LDAP) or sunAMAuthADService (Active Directory).

The values you are looking for are: Attributes Used to Retrieve User Profile (iplanet-am-auth-ldap-user-naming-attribute), Attributes Used to Search for a User to be Authenticated (iplanet-am-auth-ldap-user-search-attributes) and Search Scope (iplanet-am-auth-ldap-search-scope). You can use the set-attr-defs ssoadm command to change these properties if needed.

Note

You can also check your LDAP server access logs to see exactly how AM searches the entries in the user store upon successful authentication. You can then enable message level debugging in AM and check the IdRepo debug log to see what AM is searching for and compare these searches. See Debug logging (AM 7 and later) or How do I enable Message level debugging in AM 6.x debug files? for further information.

Authentication module and user store have conflicting attributes

The DN is returned when the iplanet-am-auth-ldap-return-user-dn property is set to true in your authentication module, which means the value of the RDN is used to search the user profile.

You can resolve this behavior using the AM admin UI or ssoadm:

AM admin UI: navigate to: Realms > [Realm Name] > Authentication > Modules > LDAP or Active Directory and disable Return User DN to DataStore.
ssoadm: enter the following command: $ ./ssoadm update-auth-instance -e [realmname] -m [modulename] -u [adminID] -f [passwordfile] -a iplanet-am-auth-ldap-return-user-dn=falsereplacing [realmname], [modulename], [adminID] and [passwordfile] with appropriate values.

Caching

You should check your caching settings to make sure caching is correctly enabled. In particular, this error can occur if persistent search is incorrectly configured, which means your changes are not being picked up.

Within the Active Directory authentication module configuration, you should check the following specific settings:

DN Cache Enabled (sun-idrepo-ldapv3-dncache-enabled) - this should be enabled if Active Directory allows move/rename operations (Mod DN) and AM uses persistent searches to obtain notification of such updates. This is disabled by default.
Persistent Search Scope (sun-idrepo-ldapv3-config-psearch-scope) - this must be changed as SCOPE_SUB is the default, but you should not use SCOPE_SUB for Active Directory as this causes performance issues.

You can use the AM admin UI navigation instruction and/or ssoadm commands detailed above for Active Directory to check these settings.

See Tune caching, FAQ: Caching in AM and Active Directory authentication module for further information.

Related Training

N/A

Related Issue Tracker IDs

N/A