Unable to logon to Java InfoView using AD

[Former Member]

Hello,

I followed all the steps in the Vintela SSO white paper for configuring Java InfoView with AD on XI 3.1, (twice actually), but get the following error when trying to log on to InfoView...

Account Information Not Recognized: Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserName@DNS_DomainName, and then try again. (FWM 00006)

However the same user account works with Deski, and kinit produces a ticket. Only InfoView fails, and it also fails with the full UPN format.

The second time through, I recreated the service account and SPN in all uppercase and matched everywhere else to avoid any case issues. The only thing that might matter that I can think of, is that the CMS is located on a SQL server in another Windows domain. Would that matter? What else could be wrong?

Thanks,

Brett

[BasicTek · Accepted solution]

we need the error in the tomcat logs with kerberos tracing turned on. In the bsclogin add the parameter debug=true after the word required before the 1st semicolon. Then restart tomcat.

com.businessobjects.security.jgss.initiate {

com.sun.security.auth.module.Krb5LoginModule required debug=true;

};

Are you using [this doc|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0f6ac3c-b3ac-2b10-1b95-c9bd46194977]. It was designed with extra troubleshooting per each step to insure everything was set properly

The most common cause if kinit works and the login to clients works is the default domain in the CMC > Authentication > Windows AD

does not match the default realm in the krb5.ini. when performing kinit the realm is appended to the user account from the krb5.ini when using infoview it is pulled from the CMC default domain. Case and FQDN are needed in the CMC as in the krb5.ini

The corrosponding error with debug=true is KDC for REALM not found. If the error is different then let us know.

Regards,

Tim

[Former Member · Accepted solution]

Yes, I'm using the same doc you linked, (very helpful by the way). The troubleshooting steps were all successful until the InfoView logon. I cleared out the Tomcat logs and restarted with the following settings (company name changed)...

C:\WINNT\bcsLogin.conf

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

CMC > Authentication > Windows AD:

AD Administration Name: TEST\BOTESTSERVICE 
Default AD Domain: TEST.MINIBOSS.COM 
Service principal name: BOTESTSSO/BOTESTSERVICE.TEST.MINIBOSS.COM

C:\WINNT\krb5.ini:

\[libdefaults\]
default_realm = TEST.MINIBOSS.COM
dns_lookup_kdc = true
dns_lookup_realm = true
udp_preference_limit = 1
\[realms\]
TEST.MINIBOSS.COM = {
kdc = IDMTEST.TEST.MINIBOSS.COM
default_domain = TEST.MINIBOSS.COM
}

After restarting Tomcat, I located the end of the stdout.log, then made another attempt at an InfoView logon. There were no additional log entries added after a failed attempt. Here's the most relevant debug lines during Tomcat startup...

\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Found name servers using JNDI
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ad-red-1.prod.miniboss.com (10.1.19.29)
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ad-red-2.prod.miniboss.com (10.1.19.30)
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ** requesting initial ticket .. **
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ** creating AS request .. **
 for client: BOTESTSSO/BOTESTSERVICE.TEST.MINIBOSS.COM
 at realm: TEST.MINIBOSS.COM
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ** Sending request to KDC .. **
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Resolving KDC for realm: TEST.MINIBOSS.COM
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: 
 UDP attempt #0 to DNS server ad-red-1.prod.miniboss.com/10.1.19.29

The above log entries seem to indicate that some of our production AD servers were found (with "prod." before the domain name), so perhaps that is the problem? I'm testing on a separate AD domain, but the production servers are also found on the same network.

Nothing in the rest of the log seems like an error or warning, and the correct test KDC host named IDMTEST.TEST.MINIBOSS.COM (10.2.40.31) is found.

\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: 
    Record
      Name: idmtest.test.miniboss.com
      Class: 1
      TTL: 3600
      Type: A
      IP Address: 10.2.40.31
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Available KDC found: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Sending message to KDC: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Sending TCP request: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     connected;  sending length and request...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     sent request;  reading response length...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     read length;  reading 322-byte response...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: --- got 322-byte response, initial byte = 0x7e
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Message sent sucessfully to KDC: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ** KDC requires pre-authentication **
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 11
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 2
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 15

Thanks again for your help.

- Brett

[BasicTek · Accepted solution]

ok your original post seemed to indicate you couldn't login manually. If you access ionfoview manually http://host:port/InfoViewApp/logonNoSso.jsp can you manually logon? (also if SSO is failing you should end up at this screen with logon.jsp as well.

If manual logon is working then you can go ahead to vintela troubleshooting but each section of my white paper builds on the previous. so if a test in section 5 fails not other configuration is possible until you resolve that.

Also since you have djcsi enabled were you able to find the credentials obtained in the end of section 7.

Regards,

Tim

[Former Member · Accepted solution]

Yes that's right, manual logon is failing. I wasn't sure if the next sections were required or not, so I just kept going to see if that would help since I none of the other section tests failed. Here's what I got for them:

SECTION 5 TEST:

D:\Program Files\Business Objects\javasdk\bin>kinit jonsmith
Password for jonsmith\@TEST.MINIBOSS.COM:password
New ticket is stored in cache file C:\Documents and Settings\jonsmith.TEST\krb5cc_jonsmith

SECTION 7 TEST:

D:\Program Files\Business Objects\javasdk\bin>kinit BOTESTSSO/BOTESTSERVICE.TEST.MINIBOSS.COM
Password for BOTESTSSO/BOTESTSERVICE.TEST.MINIBOSS.COM\@TEST.MINIBOSS.COM:password
New ticket is stored in cache file C:\Documents and Settings\jonsmith.TEST\krb5cc_jonsmith

Now that I read the "Preauthentication" comment in section 5 again, there is a log entry that seems to fit this type of issue, (it just didn't seem to look like an error):

\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Available KDC found: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Sending message to KDC: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Sending TCP request: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     connected;  sending length and request...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     sent request;  reading response length...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos:     read length;  reading 322-byte response...
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: --- got 322-byte response, initial byte = 0x7e
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Message sent sucessfully to KDC: /10.2.40.31:88
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: ** KDC requires pre-authentication **
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 11
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 2
\[DEBUG\] Fri Apr 10 06:04:37 PDT 2009 jcsi.kerberos: Acceptable PA type: 15

So I checked the suggested issues, encryption, typo and java SDK. The Java version is here:

D:\Program Files\Business Objects\javasdk\bin>java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)

I copied the password from the section 7 test above, and pasted it into the CMC > Authentication > Windows AD > AD Administration Name > Password field.

The AD MMC > BOTESTSERVICE > Properties > Account > Account options > Use DES encryption types for this account, is UNchecked. This should be using RC4 encryption, since this was used when I modified the UPN account. How would I verify that?

Thanks,

- Brett

[BasicTek · Accepted solution]

okk so you have to remove the stuff from sections 6 and 7. The logging is for vintela and we don't have manual auth working yet. The errors are completely unrelated, take the djcsi tracing out of tomcat and restart. you should see at least the username being sent to the KDC (user@ REALM.COM format)

Then a corresponding error or commit succeeded.

Regards,

Tim

[Former Member · Accepted solution]

I removed all the settings from sections 6 & 7, restarted Tomcat, and manual logon to InfoView works!

Debug is  true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
		\[Krb5LoginModule\] user entered username: jonsmith\@TEST.MINIBOSS.COM
Acquire TGT using AS Exchange
principal is jonsmith\@TEST.MINIBOSS.COM
EncryptionKey: keyType=3 keyBytes (hex dump)=0000: 70 15 D5 D3 5D E6 EF 54   
EncryptionKey: keyType=1 keyBytes (hex dump)=0000: 70 15 D5 D3 5D E6 EF 54   
EncryptionKey: keyType=23 keyBytes (hex dump)=0000: 01 15 77 1E 07 99 C2 7A   A1 C5 42 04 09 2A 74 3E  ..w....z..B..*t>
EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9E B6 B5 26 F1 F8 20 8C   19 4F CE A4 3B 54 97 75  ...&.. ..O..;T.u
0010: 98 38 3D AE F2 85 B5 04   
EncryptionKey: keyType=17 keyBytes (hex dump)=0000: 21 38 4A 67 6E 8E 58 02   5B F3 98 D0 12 7A 51 E0  !8Jgn.X.[....zQ.
Commit Succeeded 

So the end of section 5 is effectively the AD authentication stopping point without SSO? I'll try to proceed slowly through sections 6 & 7 again, and report back with my results...

Thanks,

- Brett

[Former Member · Accepted solution]

Ok, so I proceeded with section 6 only, and added the following lines to the Tomcat configuration:

-Djava.security.auth.login.config=C:\WINNT\bscLogin.conf
-Djava.security.krb5.conf=C:\WINNT\krb5.ini

And the original InfoView logon error returned. So I also added the following debug line to Tomcat:

-Dbobj.logging.log4j.config=verbose.properties

This created the following errors in the jce_verbose.log file:

<log4j:event logger="com.crystaldecisions.sdk.plugin.authentication.ldap.internal.SecWinADAuthentication" timestamp="1239394348567" level="ERROR" thread="http-8080-Processor25">
<log4j:message><!\[CDATA\[Cannot create LoginContext. Configuration Error:
	Can not specify multiple entries for com.businessobjects.security.jgss.initiate\]\]></log4j:message>
</log4j:event>
<log4j:event logger="com.crystaldecisions.sdk.occa.security.internal.LogonService" timestamp="1239394348613" level="WARN" thread="http-8080-Processor25">
<log4j:message><!\[CDATA\[doUserLogon(): failed to logon, logonCred=user:jonsmith,method:password,auth=secWinAD,aps=botest.test.miniboss.com:6400\]\]></log4j:message>
<log4j:throwable><!\[CDATA\[com.crystaldecisions.sdk.exception.SDKException$SecurityError: Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserName@DNS_DomainName, and then try again. (FWM 00006)
cause:java.lang.SecurityException: Configuration Error:
	Can not specify multiple entries for com.businessobjects.security.jgss.initiate
detail:Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserName@DNS_DomainName, and then try again. (FWM 00006) Configuration Error:
	Can not specify multiple entries for com.businessobjects.security.jgss.initiate

Any idea what this means? The contents of the bscLogin.conf and krb5.ini are the same as in my previous post.

Thanks,

- Brett

[BasicTek · Accepted solution]

yep that error indicated the bsclogin is being specified in 2 places. Some of our old docs had the bsclogin set in a java.security file or something. I can't look it up right now but there is an SAP note on this.

Regards,

Tim

[Former Member · Accepted solution]

Couldn't find the SAP note myself, but made some changes that got the InfoView logon working again!

Since the relevant path and file config in the java.security file already matched the Tomcat config, I just removed the Tomcat config line and let the Java SDK default config take over...

MATCHING configuration setting in D:\Program Files\Business Objects\javasdk\jre\lib\security\java.security:

login.config.url.1=file:C:/WINNT/bscLogin.conf

REMOVED from Tomcat config:

-Djava.security.auth.login.config=C:\WINNT\bscLogin.conf

So now I'm done with section 6 and will proceed with section 7 and check back with my results.

Thanks again,

- Brett

[Former Member · Accepted solution]

I finished up with all the section 7 steps, and was able to logon ton InfoView with SSO from another Windows box in the same test AD domain!

At first, I tried the IP address logon directly on the BO server, and that did not work. Not a big deal though, since that's not likely to be needed except for testing.

Thanks Tim for all of your help.

- Brett

[BasicTek · Accepted solution]

anytime...

make sure the IP is added to the browser intranet sites

you need to do this if using the FQDN also

Regards,

Tim