We have set up an SPN on the Domain Controller. Actually our DB Admins did this.
We have 3.1 installed on 3 servers:
Framework services on one
App Services on another
Web services (Tomcat) on a 3rd
We have gone thru all the setup steps for SSO such as the CMC settings, creating a service account and the SPN as mentioned, creating the krb5.ini file and the bscLogin.config and edited the web.xml files.
We are now able to manually authenticate into Infoview using Windows AD; however, SSO will not work and the error says the following when we try to use the logon URL in Internet explorer:
description The server encountered an internal error (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: Successfully matched service principal "BOSSO/BOESvrSrvAcct.scfbins1.com@SCFBINS1.COM" but not key type (23) + KVNO (2) in this entry: Principal: BOSSO/BOESvrSrvAcct.scfbins1.com@SCFBINS1.COM Type: 1 TimeStamp: Wed Dec 31 19:00:00 EST 1969 KVNO: -1 Key: [3, c2 cb b 43 dc f8 2 8f ] )) that prevented it from fulfilling this request.
It seems to recognize our SPN and service account but gets some sort of key type error.
Are we supposed to create the same SPN on the Web services machine as well? - or is this error something to do with encryption/decryption? We only use DES encryption since we are not on native Windows Server 2003.
You only do the SPN once.
If you are using a keytab, the problem seems to be with the keytab. What command did you use to create it? Sounds like there is a conflict with how you created it and what it is expecting. The command should have been something like:
It may also be a problem with the type of SPN you created. One SPN (BOSSO/BOESvrSrvAcct.scfbins1.com@SCFBINS1.COM) is used for Kerberos/AD authentication, the other (HTTP/…) is used for SSO from the web client.
Thanks for your reply.
I’m pretty sure we created the SPN on the Domain Controller using the ktpass command with the parameters you listed… testing it returns the
BOSSO/BOESvrSrvAcct.scfbins1.com@SCFBINS1.COM we expected.
You mention another type of SPN starting http://…
Can you elaborate on this? Using the example of our service acct SPN BOSSO/Boe…etc. what would it look like? Where would it be created and how - since we did get manual Windows AD to authenticate us into Infoview thus far - I guess we need something different for SSO?
Some instructions we came across indicated that "Client side SPN’s had to be configured for App servers. This is why i posed the previous question.
What else is returned when you test it? In your post, the log had: “Successfully matched service principal… but not key type (23) + KVNO (2) in this entry” which tells me there is some conflict with how it was defined.
If you execute “ktpass -in c:\winnt\bosys.keytab”
It should return an Existing keytab and you should see the SPN defined:
Also, I did see the post you refer to about client-side SPNs. I don’t know what they refer to and I don’t think anything is necessary outside of the SPNs you define at the server.
The SPN that starts with HTTP is a service type SPN. The one you created as BOSSO… is an arbitrary SPN, which is used to securely check the credentials of the service account (for the CMS) trying to do the AD look ups. The HTTP SPN serves the same purpose but works with the HTTP calls to enable the SSO for HTTP traffic.
To help you troubleshoot, you may try WireShark to catch different and/or more detailed kerberos errors.
Thanks for the reply. We ran a check against our keytab file using the ktpass command. I have attached the results in the attached .jpg file. I hope you can open.
It appears to have returned the desired results; however, it gave a warning:
“No Principal name Specified”
Not sure what this means unless it should have been specified in the command line.
This key seems fine, the warning msg is ok to ignore.
My concern is that the key was created with the SPN “BOSSO/…” when it should have been created with the SPN “HTTP/…”
It is the latter that works with HTTP traffic for SSO.
In the end, you should have two SPNs defined: one arbitrary type “BOSSO/…” for delegating the logons to AD, the other service type “HTTP/…” for web traffic to use SSO.
Thanks for your reply. We made some progress since last post. We had to comment out our Keytab file in the Web.xml so it would not be used. Since we are using DES encryption and not RC4 since we are not Native Windows 2003 Server, we think the problem may have been the encryption.
So, We put our password back in the Java tab on Tomcat configuration so that it could be used from there in lieu of the keytab, then executed the following three commands for the client side SPN’s:
setspn -a HTTP/SCFBI0D0BOEWEB1 BOESvrSrvAcct
setspn -a HTTP/SCFBI0D0BOEWEB1.scfbins1.com BOESvrSrvAcct
setspn -a HTTP/10.161.52.24 BOESvrSrvAcct
We can now authenticate all the way through to Infoview from a client machine using the following URL:
From your notes earlier, the encryption looked okay. If you care to try the keytab again, you should run ktpass to create the keytab using the HTTP SPN. The “HTTP” may have been the “key” it was looking for earlier because it was HTTP traffic that was trying to call the keytab.
Regardless, I’m glad to hear it’s working. Congratulations!
I have seen this error earlier as well with BOE 3.1 SP2 Windows 2008 64x bits only. I could get the SSO to work with the password in the Java configuration but not when encoded on the keytab file and web.xml!
I just removed (un-checked) the DEC encryption from the service account, set the file path c:\winnt in the web.xml file, removed the password from the Java configuration and restarted my tomcat and my SSO start to function properly again. So it looks like it was an encryption problem.
Hope that helps
