Sun Java System Access Manager FAQ: Authentication
Q: Can I reset the load balancer (LB) cookie with a POST operation during authentication?
No. You can reset the LB cookie while creating Auth Context at the beginning of the authentication process only.
Q: If one of the Dist-Auth servers fails during authentication, does that server recreate the state?
Yes, the failed-over Dist-Auth server reinitiates the authentication request to Access Manager.
Q: If failover occurs between Dist-Auth servers during authentication, is the LB cookie reset?
If the primary Dist-Auth server for the request fails after the GET operation to the Access Manager server, the load balancer sends the request to another Dist-Auth server, which then reinitiates the authentication request and resets the lbcookie value to that configured for the secondary server. After successful authentication, the lbcookie value, which becomes the one that's configured for the Dist-Auth server that successfully authenticated the user, remains unchanged for the lifetime of the session.
This process is transparent to the user, who is not prompted to log in again after the primary Dist-Auth server fails.
Q: How do I configure Access Manager to display different authentication types for different resources?
Configure a gateway, as described in "To Configure Resource-Based Resource Management" in Chapter 5, "Managing Policies" in the Access Manager Administration Guide.
Q: How do I publish certificates in Sun Java System Directory Server?
Use the ldapmodify command. Follow these steps:
- As root, create an
ldif file with Distinguished Encoding Rules (DER). Type:
# openssl x509 -infile.pem -inform PEM -outfile.der -outform DER
# ldif -b "usercertificate;binary" < outfile.der > cert.ldif
Note: If the ldif command is not available in your system, you can execute it from your Sun Java System Directory Server instance at Directory_Server_install_dir/bin/slapd/server/ldif.
The cert.ldif file that is output reads like this:
usercertificate;binary::MIIE7TCCBFagAwIBAgIEOAOR7jANBgkqhkiG9w0BAQQFADCByTELMAkGA1UEBhM
CVVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MUgwRgYDVQQLFD93d3cuZW50cnVzdC5u
...
- For an existing LDAP entry, edit the
cert.ldif file and specify the entry dn for the certificate attribute.
See this example:
# entry-id: tester10
dn: uid=tester10,ou=People,dc=iplanet,dc=com
usercertificate;binary::usercertificate;binary::MIIE7TCCBFagAwIBAgIEOAOR7jANBgkqhkiG9w0
BAQQFADCByTELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MUgwRgYDVQQLFD93d3cuZW50cnVzdC
5u
For a new LDAP entry, specify the entry dn and object class for the certificate attribute.
See this example:
entry-id: tester200
dn: uid=tester200,ou=People,dc=iplanet,dc=com
sn: Tester
cn: Test200 Tester
employeeNumber: 1001
telephoneNumber: 555-555-5555
postalAddress: 555 Test Drive
iplanet-am-modifiable-by: cn=Top-level Admin Role,dc=iplanet,dc=com
mail: Test200.Tester@test.com
givenName: Test200
inetUserStatus: Active
uid: tester200
objectClass: iplanet-am-user-service
objectClass: inetAdmin
objectClass: iPlanetPreferences
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: iplanet-am-managed-person
objectClass: inetuser
objectClass: top
userPassword: {SSHA}E3TJ4DT7IoOLETVny1ktxUGWNTpBYq8tj3C1Sg==
creatorsName: cn=puser,ou=dsame users,dc=iplanet,dc=com
modifiersName: cn=puser,ou=dsame users,dc=iplanet,dc=com
createTimestamp: 20031125043253Z
modifyTimestamp: 20031125043253Z
usercertificate;binary::MIIC9DCCAdygAwIBAgICAgowDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVM
xGDAWBgNVBAoTD3JlZC5pcGxhbmV0LmNvbTEdMBsGA1UECxMUSWRlbnRpdHkgU2Vy
- Run
ldapmodify with the cert.ldif file.
- To add a certificate to an existing LDAP entry (for example, the first file in step 2 above), type:
ldapmodify -r -h -p dir_portnumber -f ldif-filename -D "cn=Directory Manager" -w password
- To add a user entry and certificate (for example, the second file in step 2 above), type:
ldapmodify -a -h -p dir_portnumber -f ldif-filename -D "cn=Directory Manager" -w password
Q: How do I authenticate users with AuthContext and obtain an SSO Token?
This code example demonstrates how to authenticate users with the user-name and password credentials and how to obtain an SSO Token. You can run this example within a stand-alone application or within a servlet.
Note: Ensure that the relevant Java archive (JAR) files—that is, amclientsdk.jar and servlet.jar—are in the classpath.
For details, see Chapter 1, "Using the Client SDK" in the Access Manager 7.1 Developer's Guide.
Q: Does the authentication process between the Dist-Auth server and Access Manager support authentication chaining with multiple steps?
Yes.
Q: How can I find out what AMAuthCookie contains?
At the time of authentication, go to Dist_auth_protocol://Dist_auth_servername:Dist_auth_portnumber/Dist_auth_deploy_URI/UI/Login.
The name of the Dist-Auth server that started the authentication process is displayed.
After successful authentication, Access manager inserts the output value into the iPlanetDirectoryPro cookie with a valid state.
Q: What happens if the Access Manager instance fails during authentication?
In case of an Access Manager failure during authentication, the request goes to the second Access Manager server, which checks whether the original server is up. If it is, the second server forwards the request to the original server. Otherwise, the second server recreates AuthContext and sets lbcookie to the value configured for the second server itself.
Q: What is stored in the HTTP session of the Dist-Auth application? Can I tune the parameters?
The HTTP session of Dist-Auth points to AuthContext. After successful authentication, the session remains active for upgrade and logout purposes. In case of logout or failure, the session is invalidated and released.
Dist-Auth contains no parameters you can tune for HTTP sessions. Any performance tuning must occur on the Web container instead. For details, see your Web server or other relevant container's tuning guide.
Q: Which Active Directory attribute populates the Kerberos Principal that is returned from authentication?
That Active Directory attribute is sAMAccountName, a single-value property that serves as the login name for clients and servers. sAMAccountName must be less than 20 characters long, and its value must be unique among all the security principal objects within the domain container.
Q: How do I resolve the Class Not Found exception that occurred while I was searching for the AMLController class?
Do the following:
- Ensure that the most recent
SUNWma, SUNWmae, SUNWamma, and SUNWammae packages are installed on your machine.
If a previous Access Manager release resided in your machine before, ensure that you've downloaded the correct version of those packages when you last installed Sun Java Enterprise System. SUNWma and SUNWmae are located in the shared component log; SUNWamma and SUNWammae, in the B install log.
- Ensure that the
/opt/SUNWma/lib/mobile_services.jar file is in classpath-suffix in the server.xml file for your Web server instance.
mobile_services.jar is the JAR file in which AMLController resides.
Q: Why do I get an error message after entering a valid user name and password on the login page?
Here are the possible reasons:
- If you are running only one Access Manager instance, you might not have set the
amldapuser password or that password is incorrect.
- If you have multiple Access Manager instances pointing to the same Directory Server, the encryption key on all the instances might not be identical. You can verify whether the keys are identical by checking the
am.encryption.pwd property in the AMConfig.properties file.
To correct the password:
- Log in to the Access Manager Administration Console with the full distinguished name for the top-level administrator, that is,
"uid=amadmin,ou=People,dc=iplanet,dc=com".
- Go to the services for the root organization and select LDAP Authentication Service.
- Set the password for
amldapuser Bind Password and save the changes.
- Log out and log in again.
Q: After entering my user name-password credentials, I got a redisplay of the login page. What should I do?
When you first reach the login page, Access Manager creates a temporary session that remains valid for 30 seconds only. If you do not successfully log in within that time, Access Manager terminates the session. Between the time you accessed the login page and when you submitted your login credentials, 30 seconds might have elapsed, hence Access Manager could not locate the session and redisplayed the login page instead.
You can reconfigure the length of the session on the Access Manager Administration Console.
Another reason for a redisplay of the login page is that the cookie domain name in the platform server list is incorrect. Check that list and verify that it contains the correct DNS domain for which the Access Manager server is configured.
Back to top
