We recently switched over to using Windows AD as the the default authentication option on the InfoView login page. During testing everything worked great and the users could login to InfoView with their Windows AD credentials without any problems. However, once we opened it up to the wider community we started seeing problems. If the user mistypes their password once, then Business Objects will submit the wrong password 5 times to the domain resulting in a locked domain account. The error message that the user gets is:
Account Information Not Recognized: Active Directory Authentication filed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again.
You can imagine how frustrating it is for a user to get locked out the domain after one password attempt. If I go in and look at the tomcat logs I’ll see something like this:
10770032 [http-8080-Processor23] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Pre-authentication information was invalid (24)
10770251 [http-8080-Processor23] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Pre-authentication information was invalid (24)
10770298 [http-8080-Processor23] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Pre-authentication information was invalid (24)
10770329 [http-8080-Processor23] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Pre-authentication information was invalid (24)
10770376 [http-8080-Processor23] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Pre-authentication information was invalid (24)
10781595 [http-8080-Processor15] ERROR com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication - Authentication failed. Clients credentials have been revoked (18)
It is interesting to note that for one login attempt that the plugin tries to authenticate 5 times against the domain. Our domain policy allows 5 attempts.
A contractor friend of mine has suggested that this may be due to the non-hierarchical nature of how we setup the groups in the domain. He suggested that we should create one large parent group (Everyone) and then put our departmental groups under that. His theory was that BO might be trying to scan all the groups and getting timed out.
I’d be interested to hear of anyone else has run into this issue or has any insight or best practices around setting up the groups in the domain.[/b]
Update: I opened a case with SAP on this and their suggested fix was to upgrade our Java SDK to ver 1.5_14 from 1.4_08 to resolve this issue. I’ll let you know how it goes.
The way our company does it is we have only one group in AD that is mapped to Business Objects to allow for AD authentication. BO users are added as members of the group. And we refresh the group periodically via CMC. We do not use the BO Enterprise Authentication for Infoview. All other security is maintained in BO via the CMC. Also using some type of Single Sign on method will prevent resetting passwords.
The upgrade to Java JDK 1.5_16 did not work. We’re still seeing users getting locked out after 1 to 3 attempts to login. Does anyone have any suggestions for troubleshooting this issue as far as which logs or tracing can be enabled? I already know to go look at Tomcat’s stdout.log file. I thought that there was a way to turn on verbose logging for Kerberos.
There is a way to turn on tracing for the CMS by adding -trace at the end of the command line for the CMS service. I think you can add -verbose to the command line for Tomcat. Not sure about Kerberos. BO has a way to do SSO via AD using a jakarta isapi redirector to authenticate via internet Info server and passing credentials to Tomcat. One of the techs told me about it but I don’t see much documentation referring to it.
I am familiar with with the SSO method using the jakarta redirector. I believe that the Vintella plugin is now the preferred method of doing SSO with XIR2 SP2. However, what I am afraid of is that even if I implement SSO, that my current problems with AD (random lockouts, lockout after 1 password attempt) will bleed over into Vintella. I’m curious to know how many of you out there have successful implementations of Vintella SSO.
We have two servers in the test environment and five servers in production. Our domain policy allows 5 password attempts before it locks the account.
Within the test environment it will consistently lock us out after three bad password attempts:
2 servers X 3 attempts = 6 bad password attempts against the domain controller.
Within the production environment it will consistently lock us out after one bad password attempt:
5 servers X 1 attempt = 5 bad password attempts against the domain controller.
If this theory is true, then is the solution to turn off Windows AD authentication on 4 out of the 5 servers in the cluster? Does anyone have experience around this issue. My plan is to turn off AD auth on one of the test boxes and give it a try. If the theory holds true, I should be able to attempt a login 4 times with a bad password and not get locked out.
(BOB member since 2006-01-04)