- Q. Can I use AM to manage users?
- Q. Why can’t I see a user on the Identities page (previously the Subjects tab)?
- Q. How can I check how many users are being protected by AM?
- Q. Can I specify the exact DN/container that the user is to be stored on when creating a new user?
- Q. What is the default search attribute used when searching for users on the Subjects tab (Pre-AM 6)?
- Q. What is the Universal ID shown against a user or group on the Identities page?
- Q. Why can the admin user (called amAdmin by default) log in to AM when no other users can?
- Q. Why can't I log into a sub-realm with amAdmin?
- Q. How can I be certain that a user is logging in to the top level realm?
- Q. Can I prevent the default anonymous user logging in to the top level realm?
- Q. What happens to users' sessions when I deactivate a realm?
- Q. Can I warn a user that their session is about to expire?
- Q. Is it possible to create read-only users in AM?
- Q. Can I create an admin user who has similar access rights to the amAdmin user?
A. AM is not designed to be a fully featured user administration tool; the user functionality is intended to be used for validating connectivity to your identity repository. You should use a dedicated tool for managing users such as IDM or DS, depending on your use case.
AM 7 and later (Identities page)
By default, 10 users are shown per page but you can increase this up to 50 users per page using the drop-down option at the bottom of the page on the left-hand side. If you cannot see the user you require, you can search for them.
AM 6.x (Identities page)
By default, 10 users are shown per page but you can increase this up to 50 users per page using the drop-down option at the bottom of the page on the left-hand side. You cannot search for identities in AM 6.x: OPENAM-13219 (Implement a search box in the Identities page), but this is possible as of AM 7.
You can navigate to a specific user or group via a direct URL, for example:
- To find a user called jdoe in the top level realm: http://host1.example.com:8080/openam/XUI/#realms/%2F/identities/edit/jdoe
- To find a user called user1 in the employees realm: http://host1.example.com:8080/openam/XUI/#realms/%2Femployees/identities/edit/user1
- To find a group called managers in the internal realm: http://host1.example.com:8080/openam/XUI/?#realms/%2Finternal/identities/groups/edit/managers
AM 5.x (Subjects tab)
One possible reason is that you may have more than 100 users. Only the first 100 users are shown on the Subjects tab by default; therefore, you should search for a user if you have more than 100 users.
In AM 5.x, you can increase the number of users shown by editing the schema directly using an LDAP browser such as the DS control panel or Apache™ Directory Studio as follows:
- Navigate to the following DN: ou=1.0,ou=iPlanetAMAdminConsoleService,ou=services,dc=example,dc=com
- Search for "iplanet-am-admin-console-search-limit" in the editor box for the schema XML and change the default value from 100 to your desired value.
Increasing the number of users shown on the Identities page may slow the loading time of users.
A. You can query your LDAP user store to find the number of users. See How do I count the number of users in my ForgeRock deployment? for further information.
A. No, AM does not allow end-users to specify the exact DN/container for newly created users; AM will just utilize the configured LDAP people container name/value setting. The DN value provided for the /json/users REST endpoint is essentially ignored by the underlying code and the entry will be created based on the data store settings (which again is only able to work with a single container).
Q. What is the default search attribute used when searching for users on the Subjects tab (Pre-AM 6)?
A. The default search attribute is cn. This can be changed as described in How do I change the search attribute used to search for users in AM 5.x and OpenAM 13.x console?
A. The Identities page displays identities from the configured data stores. As AM abstracts the underlying data store technology (for example, directory server, database, NoSQL database, external web service etc) away from the "identity" concept, no assumptions are made about the underlying data.
When AM displays the user or group "identity", it displays generic information such as the user's name or the group members. It also displays the Universal ID, which is not to be confused with the actual DN of the entry in your configured LDAP based data store. The Universal ID is used by AM to differentiate identities, and is in the following format:id=[identity name],ou=[identity type],[realm DN]
- [identity name] is the name of the identity.
- [identity type] is the type, which can be user, group, role or filteredrole.
- [realm DN] is the identifier of the realm the given identity belongs to (which contains the configuration store's root suffix).
A. The admin user is stored in the configuration repository in AM, whereas other users are stored in your identity repository. If there are connection issues to your identity repository, these will prevent other users logging in but the admin user will still be able to log in.
See Login to AM console (All versions) fails for amAdmin user for further information if the amAdmin user cannot log in.
A. amAdmin is only available in the top level realm; sub-realms use the same identity repository as the top level realm by default, but because this user isn't in the identity repository they are not available in sub-realms. You can use the demo user in sub-realms as this user is stored in the identity repository.
See Authentication and Single Sign-On Guide › Authenticating (Browser) for further information.
A. The default anonymous user is used in conjunction with the Anonymous Authentication module. It is safe to deactivate this user if you do not use this module and this will prevent them logging in to the top level realm.
See How do I deactivate the default anonymous user in AM (All versions)? for further information.
A. Users who are currently logged in and have a valid session will be unaffected; their session will remain active. However, other users will not be able to authenticate to that realm once it is deactivated. This is also true if you are using SAML federation and AM is the IdP. If AM is acting as the SP, SAML based SSO will fail as AM will be unable to process assertions issued by the IdP.
You cannot end all user sessions by deactivating a realm.
A. You cannot configure this on a per user basis but you can make a whole data store read-only in AM. See How do I make a whole user data store read-only to users in AM (All versions)? for further information.
There is an RFE, which may address this in the future: OPENAM-5714 (Add support for more granular delegation privileges).
A. Yes you can. You can create admin users with different access rights (privileges) according to your needs. See How do I add privileges to identity groups in AM (All versions)? for details on how you assign these privileges to a user and Security Guide › Delegating Privileges for details on the different privileges that are available.
There is an RFE for additional privileges: OPENAM-5714 (Add support for more granular delegation privileges).