Unity failover sspi error"0x80040000] : Cannot generate SSPI context

[ciscoforum]

Hi

Unity failover. I am getting sspi error on enterprise manage and failover log. Please see the attachment.

[maratimer_2]

Hi, I have seen this before in many of my failover configurations. This is the fix I have:

If you open SQL's Enterprise Manager, and try to register the other Unity server, you might get "Cannot generate SSPI context." If you remove localhost, and register the actual servername or ip, you will get the same error. If either of the above is true, then see

http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en

After downloading the above executable, log on as unityinstall and do the following on the server :

setspn -L

If you see a line like this one for one server :

MSSQLSvc/SERVER_NAME.DOMAIN.TLD:1433

Do the following :

setspn -D MSSQLSvc/SERVER_NAME.DOMAIN.TLD:1433 SERVER_NAME

[ciscoforum]

Thanks very much. However I didn't get the error as you mentioned. What else should I do?

This is on 2nd serverC:\Program Files\Resource Kit>setspn -L unity01-fai

Registered ServicePrincipalNames for CN=UNITY01-FAI,OU=VOX,OU=Servers,OU=RMY

,DC=ykregion,DC=ca:

HOST/UNITY01-FAI

HOST/unity01-fai.ykregion.ca

[tonyw1538]

Just for the record - I would advise against deleting service principal names to 'solve' Kerberos authentication problems.

Deleting the SPN merely makes authentication fall back to NTLM and does nothing to solve the root problem - could be DNS, an unreachable DC, etc.

Again, just my opinion - and probably worth what you paid for it.

- Tony -

[ciscoforum]

The setspn output for the two servers are:

unity01 primary server

C:\Program Files\Resource Kit>setspn -L unity01

Registered ServicePrincipalNames for CN=UNITY01,OU=RMY,DC=region,DC=ca:

MSSQLSvc/unity01.region.ca:1433

SMTPSVC/UNITY01

SMTPSVC/unity01.region.ca

HOST/UNITY01

HOST/unity01.region.ca

ykr-unity01-fai failover server

C:\Program Files\Resource Kit>setspn.exe -L unity01-fai

Registered ServicePrincipalNames for CN=UNITY01-FAI,OU=RMY,DC=region,DC=ca:

HOST/UNITY01-FAI

HOST/unity01-fai.region.ca

Should I remove the following entries on the primary server?

MSSQLSvc/unity01.region.ca:1433

SMTPSVC/UNITY01

SMTPSVC/unity01.region.ca

I am wondering what will happen if remove it?Will it stop the sql and smtp service on the primary server? Why this will help to fix the problem, why? Thanks

[tonyw1538]

That MSSQLSvc SPN is typically registered with Active Directory when you install a SQL instance.

Removing it would help "fix the problem" because services will stop trying to use Kerberos authentication to connect - they will fall back to NTLM. Nothing connecting to such a SQL server would be able to authenticate using constrained delegation, for example. For this application you may not care - unless Cisco takes that authentication approach in some future release (unlikely).

Again, in my limited opinion based upon very little knowledge of your environment, removing the Service Principal Name (SPN) does not fix the problem, it simply makes the problem irrelevant for the time being!

Sorry to be such a curmudgeon!

- Tony -

[ciscoforum]

thanks very much for your comment here.

Here are two questions trying to get more understand.

1. If I delete it, SQL service should still be running, right? there is no impact on service at all? only is the authentication level backed down to NTLM?

2. How did this kerberos work between the 2nd sql server and primary? how should we fix it essentially?

Thanks

[tonyw1538]

I suppose this is wandering a little bit off-topic for this forum, but essentially the answer to question 1 is "yes" - the service will still work and authentication should fall back to NTLM.

As to question 2 - I suppose my first thought would be to make sure time of day is correct - everyone pointing to the same NTP server ideally.

Next check to see that DNS is configured correctly - all hosts can see and lookup all other hosts, and that the servers own their own DNS entries in Active Directory.

You have already verified that the SPN exists and is registered correctly.

Beyond those items I would recommend reading through Microsoft's KB 326985 (http://support.microsoft.com/kb/326985). Many of the suggestions are tied to making IIS work, but at the end is a fairly complete listing of Microsoft Kerberos resources.

I hope you find this helpful.

[tonyw1538]

Oh, one more thing. Sometimes just rebooting the SQL server fixes it. I know, that sounds hokey, but I have seen it work especially when the authenticating host is new to the network.