Section A.4.1, iChain Single Sign-on is Not Compatible With iManager 2.5
Section A.4.2, Users Prompted to Authenticate Twice When Accessing Password Management Servlet
Section A.4.5, Certificate Revocation Checking (revocationcheckmethod = )
Section A.4.6, OSCP ‘Unknown' Response Lets Certificate Authenticate User
Section A.4.7, Certificate Authentication Problems When the CRL Is Invalid
Section A.4.9, NMAS RADIUS Update Required for iChain RADIUS Token Authentication
Section A.4.10, Use the Latest NetIdentity Client With iChain 2.3
Section A.4.11, Using an iChain Accelerator for WebDAV Connections to NetStorage
Section A.4.12, Do Not Use NetIdentity with LDAP/RADIUS ANDing
Section A.4.13, iChain is Unable to And LDAP with XTier Based Profiles
Section A.4.14, OLAC Authentication Profile Parameters Still Passed When OLAC Is Disabled
iChain's single sign-on functionality (including forward authentication, OLAC, and Form Fill) is not compatible with iManager 2.5. To log in, iManager 2.5 requires a username, password, and treename. This prevents forward authentication and OLAC from working. With Form Fill, the Exit button in iManager directs you back to the initial login form.
When you set up an additional accelerator, your users might be required to authenticate again to the second accelerator. This occurs when the password management server is a separate accelerator in a CDA setup that requires authentication. And when the authentication profile names for the accelerator you are authenticating to and the password management accelerator have different names.
If you disable authentication on an accelerator, the user is still prompted to supply their user certificate. This continues until a purge cache is done. You can cancel the certificate until the cache can be purged.
Time restriction, intruder lockout, and login disabled are checked only if you are using Novell's NMAS Radius server in the same tree as the iChain Authorization tree. Also, the LDAP does the checks if the Radius Token authentication is ANDed with an LDAP authentication.
Certificate revocation is checked in the URL of the certificate. The certificate revocation method is set using the following setting:
revocationcheckmethod=method
The method is the type of certificate revocation checking performed during mutual authentication. The following Certificate Revocation checks are available depending on the value of the revocationcheckmethod parameter:
OCSP only. This method checks only the online certificate status protocol (OCSP). The CRL is checked in the URL and overrides the client certificate. The certificate does not pass if it is revoked or there is a miscommunication.
CRL only. This checks only the Certificate Revocation list.
OCSP- CRL. This method checks the OCSP first, then checks the CRL. The CRL protocols include HTTP, LDAP, and X.500 directory name (provides only the directory name).
The Certificate Revocation Lists (CRL) is checked when the following conditions exist:
The client certificate contains a CRL Distribution point (CDP).
The client certificate contains a CRL CDP but not an Authority Information Access (AIA) extension for OSCP.
The OCSP configured sources is disabled.
If you have your certificate revocation method set to OCSP-CRL, the certificate is allowed to authenticate the user if an unknown response occurs and the client certificate does not contain a CRL distribution point. If you do not want the certificate to authenticate the user under these circumstances, you need to set your revocation method to OCSP only.
An invalid Certificate Revocation List (CRL) prevents mutual or certificate authentication from working properly. The CRL includes a dated time stamp indicating when the CRL is invalid. The Certificate Authority (CA) needs to update the CRL periodically with a new expiration date and time. If the CA does not update the CRL, perhaps because the CA is down or for any other reason, the CRL becomes invalid. During certificate or mutual authentication, the iChain Proxy Server compares the time stamp of the CRL with its own time and if the CRL time stamp has expired, then the authentication fails.
If you are using Mutual SSL Authentication, a certificate error might occur if the user attempts to access the site while their user ID is in the 0 TTL state. During this state, the user's session times out. However, there is a 60 second window where the user ID is still registered with the IAGENT database.
If you are using NetWare 5 with Support Pack 6 or higher, or NetWare 6 with Support Pack 3 or higher, you need to update these versions in order for the NMAS RADIUS Server to do iChain RADIUS token authentication. See the Novell Technical Information Novell Technical Information document for the download and details.
If you are using NetIdentity for iChain authentication, you must use NetIdentity client 1.2.1 or later. Also, NetIdentity-aware server components that released with NetWare 6.5 that are accessed through iChain, such as NetStorage, Virtual Office, and iManager, must be updated with NetWare 6.5 SP1 or later for full functionality.
If you are using an iChain accelerator for WebDAV connections to NetStorage, the Allow authentication through HTTP authorization header and Use basic/proxy authentication options must be enabled in the Authentication Profile used by the accelerator. Users are required to provide login credentials both for iChain and for NetStorage authentications; however, if the workstation has the NetIdentity client installed and configured to trust the NetStorage CA, the user will not be prompted for the additional login to NetStorage.
The Authentication profile option, Allow authentication through NetIdentity, might give unexpected results if you enable it in addition to basic/proxy authentication. If you enable the Allow authentication through NetIdentity option, the workstations with the NetIdentity client installed are unable to make WebDAV connections through the accelerator. This problem occurs because the WebDAV OPTIONS header is a non-redirectable request. In this case, iChain returns a 409 Conflict error, resulting in a failed authentication and connection.
NetIdentity authentication does not work if you have configured an LDAP profile, created a RADIUS profile, and have ANDed the two profiles together.
If you attempt to And LDAP with XTier, you lose the auth profile that was added last.After you apply the settings to the server, only one of the profiles appears.
You can configure an accelerator and initially enable OLAC with authentication profile parameters using a query string. If you then disable OLAC, the authentication profile parameters are still passed in the query string for existing users who are logged in.