Novell ACCESS MANAGER 3.1 SP2 - README 2010, Руководство пользователя

Страница: 109 / 374

Configuring Local Authentication 109
n
ov
do
cx (e
n)
16
Ap
ril 20
10
3.1.3 Configuring an Admin User for the User Store
The Identity Server must log in to each configured user store. It searches for users, and when a user
is found, it reads the user’s attributes values. When you configure a user store, you must supply the
distinguished name of the user you want the Identity Server to use for logging in. You can use the
admin user of your user store, or you can create a specialized admin user for the this purpose. When
creating this admin user, you need to grant the following rights:

The admin user needs rights to browse the tree, so the Identity Server can find the user who is
trying to authenticate. The admin user needs browse rights to object class that defines the users
and read and compare rights to the attributes of that class. When looking for the user, the
Identity Server uses the GUID and naming attributes of the user class.

The admin user needs read rights to any attributes used in policies (Role, Form Fill, Identity
Injection, Authorization).
 If a secret store is used in Form Fill policies, the admin user needs write rights to the attributes
storing the secrets.

If a password management servlet is enabled, the admin user needs read rights to the attributes
controlling grace login limits and remaining grace logins.

If you enable provisioning with the SAML or Liberty protocols, the admin user needs write
rights to create users in the user store.
If your user store is an eDirectory user store, Access Manager verifies that the admin user has
sufficient rights to browse for users in the specified search contexts.
IMPORTANT: This check is not performed for Active Directory or Sun ONE. If your users cannot
log in, you need to verify that you have given the admin for the user store sufficient rights to the
specified search contexts.
3.1.4 Configuring a User Store for Secrets
Access Manager allows you to securely store user secrets. These secrets can then be used in Form
Fill and Identity Injection policies. Where and how the secrets are stored depends upon your user
store and your configuration:

“Configuring the Configuration Datastore to Store the Secrets” on page 110 .
If you want to do minimal configuration, you can use the configuration datastore on the
Administration Console to store the secrets. To increase the security of the secrets, you should
configure the security options.
 “Configuring an LDAP Directory to Store the Secrets” on page 111 .
If you are willing to extend the schema and add an attribute to your user object on the LDAP
directory, you can store the secrets in your LDAP directory.
Directory Object Class GUID Attribute Naming Attribute
eDirectory User guid cn
Active Directory User objectGUID sAMAccountName
Sun ONE inetOrgPerson nsuniqueid uid