Problem with XIR2 Windows AD authentication - number of password attempts

[Former Member]

We enabled Windows AD authentication about a month ago and for the most part it works well. However, it is not forgiving on the number of times you can mistype your AD password. Our domain policy allows a user to mistype their password 5 times before the domain account is locked. However, when logging into Business Objects InfoView using AD authentication the user only gets one chance to get it right. If you mistype your password when logging into InfoView, your AD account is locked.

When I look at the Tomcat stdout.log file when this happens I see (5) entries for the failed authentication and then the lockout message.

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)

If the user is only trying once, why is BO trying the wrong password against the domain controller 5 times?

You can imagine that this is a huge burden for us. When this happens they call us, and we have to conference in the helpdesk to get them to unlock the user's AD account. Any help that anyone can provide would be most appreciated. If you know some methods for troubshooting, monitoring or logging what the kerberos plugin is doing, let me know.

[Former Member]

Update: We upgraded to JDK 1.5.0_16 and XIR2 SP4 in our test environment and I am happy to report that Windows AD authentication is now functioning as we expect. Logging into InfoView with Windows AD authentication allows the user 5 mistyped password attempts before it locks the domain account. Prior to upgrading to SP4/JDK 1.5 Business Objects would attempt authentication against the domain twice for every single mistyped password attempt. This was proven through monitoring of the tomcat stdout.log file with debug turned on in the bscLogin.conf file.

Our plan is to move forward with upgrading our production environment to SP4 / JDK 1.5.

[BasicTek]

Thanks for that update Jim,

JDK 1.4.x has caused us several issues with various kerberos implementations. It appears this may be yet another. Thanks again for letting us know.

-Tim

[Former Member]

Business Objects Enterprise : XIR2, SP2, FixPack 2.4

Tomcat : 5.0.29

JDK : j2sdk 1.4.2_08

- I have not yet set "debug=true" in the bsclogin file. I will do that today.

- I set the UDP preference on all servers last week per KB article 1231879 which forces all traffic to TCP. This did not seem to have any affect on the problem.

- All users who use a wrong password once when logging into InfoView in production are locked out of the domain on the first attempt. When attempting to replicate this issue in the test environment, we get three attempts with a wrong password before the account is locked by domain policy.

- In our test environment we upgraded to XIR2 SP4, Tomcat 5, JDK 1.5.0.11. However, we are still only getting the three attempts. When looking at the stdout log file in test, it shows 5 attempts against the domain and then the account lockout code.

[BasicTek]

that's strange, do you have a message open with support? I don't think we ever had a bug that did this, not on 2.4.

I think we need more info from the std.out with at least that debug=true, normally user logon attempts are not logged without debug=true or verbose tracing enabled, are you using everbose tracing? If so turn it off and switch to debug=true maybe it's causing this.

Regards,

Tim

[BasicTek]

Hi Jim,

I don't believe I can reproduce this behavior in house. I need to know some info.

full version and patch info for XI, tomcat, and JDK

To verify JDK from a command prompt find the BOinstall\javasdk\bin directory and run java -version

by default c:\program files\business objects\j2sdk1.4.2_08\bin

Is debug=true set in the bsclogin?

com.businessobjects.security.jgss.initiate { 
com.sun.security.auth.module.Krb5LoginModule required debug=true; 
};

Do you have UDP preference set in the krb5.ini?

[libdefaults] 
default_realm = MYDOMAIN>COM
dns_lookup_kdc = true 
dns_lookup_realm = true
udp_preference_limit = 1

debug = true simply shows the user logon attempt (including username)

udp forces TCP so there are no retransmits at the network level

1 last question is this all users, or just one/some?

In my std.out, with those settings I see only 1 attempt per AD login (pass or fail). XIR2 SP4 tomcat 5 JDK 1.5.0.11

Regards,

Tim

Edited by: Tim Ziemba on Sep 17, 2008 7:41 PM