Kerberos SSO with IE8

[Former Member]

Hi,

I have configured Java SSO for BOE XI 3.1 (with SP2) using Kerberos.

However, the SSO is only working on one client computer, regardless of who logs on. The stdout.log file on the server demonstrates that the authentication and SSO process is working.

However, for all other client machines, the InfoView logon page appears (the user can then enter their AD details manually at this point and it logs them in)

Both the working client machine and the non-working client machine have IE8 and the internet settings are identical (with the windows authentication enabled checkbox checked, and the Infoview site added to the trusted sites)

The update KB974455 has not been installed on any client machine.

Do you know what the reason could be for the SSO process not being enforced on these client machines?

[Former Member]

One further point to add to this error message.

We have two old (disabled) service accounts that have SPN's attached to them.

Not sure if this is a problem, gven they are disabled accounts

[BasicTek]

There is no way to setup SSO for some users it's all or nothing on the server side. All the SSO settings on the BO side do is force a 401 when users access the URL. If you are experiencing failures from some browsers then it is likely a browser issue. Ensure if the user is a member of many AD groups and policies that the maxhttpheadersize on the server is set to 16384 or higher. Make sure your browser settings are the same.

A duplicate SPN issue would affect all users unless you are using multiple web/app servers

Regards,

Tim

[Former Member]

Thanks Tim.

This error has now been resolved.

However, on the machines that do not work using IE (yet work with Firefox), we are getting a new error:

668.756> Kerb-Warn: Failed to read credentials from the cred mgr 0xc000000d.

668.756> Kerb-Warn: KerbCallKdc: error 0x7

668.756> Kerb-Warn: Failed to get TGS ticket for service 0xc000018b :

HTTP <FQDN>:8080

668.756> Kerb-Warn: d:\nt\ds\security\protocols\kerberos\client2\kerbtick.cxx, line 3469

668.756> Kerb-Warn: Failed to get outbound ticket: 0xc000018b

668.228> Kerb-Warn: Failed to read credentials from the cred mgr 0xc000000d.

668.228> Kerb-Warn: SPN not found

HTTP <FQDN>:8080

668.228> Kerb-Warn: Failed to get outbound ticket: 0xc000018b

668.228> Kerb-Warn: Failed to read credentials from the cred mgr 0xc000000d.

668.228> Kerb-Warn: SPN not found

HTTP <FQDN>:8080

668.228> Kerb-Warn: Failed to get outbound ticket: 0xc000018b

[Former Member]

It appears IE is requesting the SPN with the port number. There are two possible fixes.

1. Register the non-service-default port number as part of additional SPNs. (HTTP/hostname.domain.tld:8080 and HTTP/hostname:8080)

or

2. Disable port numbers as part of SPNs in IE. Read more: [http://support.microsoft.com/kb/908209]

Thanks!

Kyle

[Former Member]

We are now in a position where half of the machines tested work using IE (yet all machines tested work using Firefox)

The machines that work are either the Citrix environment (Windows Server 2003) or Windows XP machines with more XP updates than the standard SOE.

However, on machines that do not work using IE, we are getting the following error:

HTTP Status 500 - com.wedgetail.idm.sso.ProtocolException: com.wedgetail.idm.spnego.server.SpnegoException: GSSException: Failure unspecified at GSS-API level (Mechanism level: com.dstc.security.kerberos.KerberosException: Could not decrypt service ticket with Key type 23, KVNO 3, Principal &quot;HTTP/<machine name>@<FQDN>&quot; using key: Principal: HTTP/<machine name>.<FQDN>@<FQDN> Type: 1 TimeStamp: Thu Jan 01 09:30:00 CST 1970 KVNO: -1 Key: [23, c1 f9 35 31 51 c0 a2 55 9c 6e eb c6 cd 80 8b 22 ] Exception for this key was: com.dstc.security.kerberos.CryptoException: Integrity check failure[Note: principal names are different; this may or may not be a problem] [Note: KVNO used wildcard match, not exact match; perhaps the password used to generate this key is not the most recent password?] )

The only issue I can think of is that may be related to this is the functional level of AD was changed from 2000 to 2003 recently -however I cant see why this would be causing problems on some machines and not others.....

[BasicTek]

Make sure you are not using DES encryption anywhere (service account(s)) or the keytab (if using it)

Regards,

Tim

[Former Member]

Thanks Tim.

I have set IE settings to bypass proxy server and have been told that the proxy server settings have been set to anonymous access for the Infoview site - yet still getting these errors in the IE logs

Are you aware of anything else that could be causing IE to try and authenticate with the proxy server?

[Former Member]

Thanks Seb

Yes - there is a proxy server between client and server, but it has been explicity configured to bypass the Infoview page.

What I find strange is that it is working on one machine but no other machines.

The only thing that is different about the working machine is the Java plugins. Could this be related to this issue?

I found this on the Java web site:

WEB-BROWSER INTEGRATION

An important class of applications that should be able to capitalize on Java single sign-on are applets. For this discussion we assume that the browser JRE has all the required packages or the Java plugin is used with a Merlin JRE installed by the user.

One complication in using applets arises mostly out of the fact that before an applet can use Java GSS-API, it must perform a JAAS login. The main problems with this are (a) an increase in the effort required on the part of the applet developer (b)unnecessary repeated login by the same user each time he or she starts an applet.

A good model to solve this problem would be to have the browser (or the Java plugin) perform a JAAS login once at startup. This would provide a Subject that could always be associated with the access control context whenever any Java code was run. As a result, the applet code would not need to perform a JAAS login prior to using Java GSS-API, and the user login would occur just once.

In the absence of this login functionality in the browser (or Java plugin), applets can still avoid having to perform a JAAS login themselves. To do so, the applets would have to set the javax.security.auth.useSubjectCredsOnly system property to false and use a GSS-API mechanism provider that is capable of obtaining credentials from sources other than current Subject. When using a Sun JRE with a Sun Kerberos GSS-API provider, expect the mechanism to perform a JAAS login to obtain new credentials as explained in the previous section. The applet deployer would only need to ensure that the appropriate modules and options are listed in the entry "other" in the JAAS configuration used by the JRE. This saves the applet developer from calling into JAAS API's directly, but it does not stop the repeated JAAS login that might happen with each applet the user runs. However, by configuring the login modules to read a pre-existing native cache, the deployer can both hide the login from the user, and minimize the overhead in the multiple logins. (See how this is done for the the JAAS configuration entry "SampleClient" in Figure 1.)

[BasicTek]

you shouldn't be trying your initial config of SSO through a proxy until tomcat is working 1st before introducing other points of failure

Regards,

Tim

[Former Member]

Hi Tim,

I've been watching this post closely as I think we are having a similar problem or at least at a similar stage. I hope this is not bad forum ettique, cutting in like this, but we have just setup BOE Windows AD successfully on a Windows 2003 Server R2 and XP client environment running IE7. I have followed your Distributed Environment doc to the letter (as far as I can see). I can run kinit successfully on the report server, I can see Vintela load up in the stdout.log file (well it says Credentials Obtained) but I cannot get SSO to work. What we see is the log on page appear. We can then log on using AD just fine but that's not what we're after.

I've never used kerbtray or Wireshark before so was trying to cover all bases before going there. However would you say this is my only option now, to run Wireshark from the client and try to analyse the packets?

One thing that may or may not be of interest, the envrionment has two DCs, one primary and an email server running as the secondary. I've only run ktpass and the setSPN commands on the primary DC. Everytime I fire up Tomcat and read the stdout.log file I see it trying to authenticate from the primary DC but then only succeeding by going to the email server. The primary DC is what I have set my KDC = in the krb5.ini file. I've done a port scan using portQry on both servers and port 88 is open and listening on both servers.

I'm willing to do whatever it takes to get this working so any suggestions would be greatly appreciated.

Thanks,

Michael.

[BasicTek]

I've never used kerbtray or Wireshark before so was trying to cover all bases before going there. 
However would you say this is my only option now, to run Wireshark from the client and try to analyse the packets?

Yes this is the only option as SSO does not occur in BO or on any of the BO servers it occurs on the client workstation. The browser requests the URL from tomcat which is enabled for SSO (as you said the credentials are obtained). The client is presented a 401 on the HTTP layer. The client negotiates and should choose spnego which will initiate a 3 ticket exchange with AD/DC from the client. Wireshark and kerbtray will show what portion of this occurred/did not occur.

After the client receives the 3 tickets then the BO server will authorize which is usually not an issue especially if you can logon manually with AD (which is why we test that 1st)

Regards,

Tim

[Former Member]

Hi Tim,

I've installed KerbTray and Wireshark on a client PC. I purged the tickets with Kerbtray and then kicked off Wireshark tracing. I then opened IE and navigated to our InfoView page. It obviously displayed the login page and did not let me in via SSO. I closed IE and stopped Wireshark. On examining the trace file I noticed that after the web server sends the client the 401 the client tries to authenticate, via kerberos with one of the secondary domain controllers, not the primary DC. And each time an AS-REQ is sent from the client to the secondary DC, an AS-REP is sent back from the Secondary DC to the client , then a TSG-REQ from the client followed by a KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN sent from the secondary DC back to the client.

What I can't understand is why can I run the kinit command successfully from the Web/BOE server but it doesn't work via the client? Also I have specified the KDC in the krb5.ini file to be the primary DC by FQDN. Should I switch this to IP address to be more specific to stop the secondary DCs being used? Finally do I need to force propagation of the SPN to the other DCs, is that what I'm missing? Or is there something else?

Thanks,

Michael.

[BasicTek]

kinit has nothing to do with SSO, it only submits the AS req which you noticed is already working.

SSO uses the URL to construct an HTTP/URL or HTTP URLFQDN request.

The value should be visible in the wireshark log. The Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN means that the client workstation could not find the SPN for HTTP/URLFQDN. that is why SSO is not working. It's an AD issue. You can open a case if you need an authentication engineer to trace down why this is, or you can also pursue the issue with your Microsoft admin or Microsoft itself.

Common issues are redirector/load balancers changing the URL, duplicate SPN, typo/missing SPN, etc.

Regards,

Tim

[Former Member]

Thanks.

I currently have a message open with support - has been very hard to nail the issue down!

We built a new desktop environment with XP SP2 and no updates and it still would not work in IE.

Interestingly, I am getting the following error in IE logs:

HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )..Via: 1.1 <proxy server name>..Proxy-Authenticate: Negotiate..Proxy-authenticate : Kerberos.)

Do you know if this error could be telling me anything relating to IE authenticating correctly?

[former_member136842]

Hi,

do you have a proxy server between your client and the BOE Server ? Maybe this one if filtering something.

check with your network team to connect via LAN directly from your PC to the BO Server.

Regards

-Seb.

[Former Member]

Thanks Tim.

Yes - windows authentication has been enabled under Advanced Internet Options.

The URL does not have an .s in it, however the machine name does have a - in it (in any case http://machinename has been added to the the local intranet sites in IE)

No changes have been made to any of the SSO settings under Security - Local Intranet

The other interesting point is that when I configured Firefox, for the items network.negotiate-auth.delegation-uris and network.negotiate-auth.delegation-uris, I had to enter the full Infoview path e.g http://machinename:8080/InfoView - when I entered http://machinename.domain it did not work.

Additionally, we have got this working on one client machine in IE (the IE settings on this machine in Internet Options and Local Intranet Sites are the same as the machines that are not working) The only difference I have found with this machine compared to others is that the Windows XP updates are different.

Could any of these updates be causing an issue with IE? (I know that KB974455 has been known to cause issues, however this is not on any client machine unless it is part of XP SP2 or XP SP3)

[former_member136842]

Hello,

thats strange !

And if you try the URL from FF in IE does this maybe work ?

Maybe an idea: Some security restrictions by a GPO applied to IE causes the error.

Best would be check with your AD Team if there are any IE related GPO`s ?!

Regards

-Seb.

[BasicTek]

KB974455 is not the actual patch that causes the problem, it a sub patch inside that can also be installed seperately.

Are you receiving 500 errors because we do have a fix for that coming out in SP3. Also to note the problem should only be with SSL enabled not regular HTTP:

Open a case with the authentication team as more detailed investigation may be needed.

Regards,

Tim

[Former Member]

Thanks Tim & Seb.

I can now get SSO working with Firefox on any workstation - works perfectly.

The stdout.log file confirms it is working - I get the usual kerberos logging to indicate a successful SSO login.

However, it still only works on one workstation for IE8. I even rolled back one workstation to IE7 and I get the same problem. The 1 workstation with IE8 that works has all the same internet settings.

When I log on with IE, obviously I do not get the same logging in the stdout.log file - instead of getting all of the successful kerberos logging, I get:

INFO: Illegal access: this web application instance has been stopped already. Could not load com.crystaldecisions.thirdparty.com.ooc.OB.MinorCodes. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.

java.lang.IllegalStateException

[BasicTek]

That error is unrelated. If FF is working the your problem is IE configuration. SSO does not occur in the java app server it occurs on the client workstation. All the java/app plays is to send a 401 (which forces the browser toi identify) and sends username to the CMS after it has. If it works for 1 browser on the workstation then it should work for all. Something in IE is not set right.

Does the URL have any .s in it, if so has it been added to local intranet (not trusted sites)?

is integrated authentication enabled in IE properties - advanced?

Has anyone changed the SSO default settings under IE properties - security - local intranet - use automatic logon?

Regards,

Tim

[Former Member]

Thanks for this.

Yes, IE8 is being run in compatibility mode.

I will have a look at these tools to see if I can confirm the issue on the client machines not working.

Also, I should also mention that I downloaded Firefox 3 on the same workstation where I got the logon page with IE8 and when launching Infoview in Firefox, the Infoview logon page did not appear. Instead, I got the following error:

The request requires HTTP authentication()

Would this indicate that SSO is not failing on the workstation and that it is a browser issue?

[former_member136842]

Hi,

you have to configure Firefox correct in order to have SSO with Firefox. Check tha Admin guide on How to do that.

Regards

-Seb.

[BasicTek]

Are you running IE8 in IE7 compatibility mode? IE8 in normal mode hasn't been fully tested yet and I don't know if any new settings are needed. Getting the logon page indicates that SSO completely failed on the workstation, you cannot trace SSO on the server it has to be done on the client independant of BO. SAP KB 1261835 and others show what to look for and soem tools that can be used to verify.

Regards,

Tim

[BasicTek]

The standard.out should not be demonstrating that SSO is working, SSO occurrs on the client workstation not the web/app. If only 1 workstation is working what are the details about it? How many have you tried? Are they all IE8?

Also we have a note on setting firefox up for kerberos. You need to modify the about:config search SAP KB's for that.

Regards,

Tim

[Former Member]

As far as I know, IE8 is not supported. You need to roll it back to IE7.