Kerberos authentication

stmoore1

What does the "Enforce Kerberos Authentication" registry key actually do? I can't find it documented anywhere.

Migrateduser

FAQ: WorkSite Trusted Login with Kerberos Authentication
________________________________________________________________________________________________
Technote Number: 62007-2087
Category: WorkSite Server, DeskSite, FileSite, OffSite
Product: 8.2
Created: 07/06/2007
Last Modified: 09/07/2007
________________________________________________________________________________________________
What is WorkSite Trusted Login with Kerberos Authentication?

WorkSite Trusted Login with Kerberos Authentication a robust authentication mechanism for desktop clients to securely authenticate in an Active Directory environment. This new implementation of the 'Trusted Login' feature leverages the Kerberos network authentication protocol when authenticating an ADS user.


Why use Kerberos Authentication for Trusted Login?

Previous versions of WorkSite utilized trusted login mechanisms that relied on NT domain based architecture. These authentication mechanisms have security vulnerabilities and are not optimal for environments like ADS which provide a higher level of security. Based on feedback received from customers Interwoven has invested in building a trusted login mechanism specifically for ADS environments.


What versions of WorkSite Server, FileSite, DeskSite and WorkSite Web use Kerberos Authentication for Trusted Login?

Kerberos Authentication for Trusted Login is available with WorkSite Server/WorkSite Server with Caching 8.2 Patch 3 or later, FileSite/DeskSite 8.2 Patch 4 or later and WorkSite Web 8.2 SP1 P1 or later.


Can WorkSite clients that do not use Kerberos Authentication connect to WorkSite Server 8.2 Patch 3 or later?


Yes. By default, WorkSite client versions prior to 8.2 Patch 4 can connect to Kerberos-enabled WorkSite Servers using either Trusted Login or Explicit Login. These legacy clients do not utilize Kerberos Authentication when making a Trusted Login connection. Explicit login is not affected by Kerberos Authentication. Refer to the following section on "Enforce Kerberos Authentication" for an exception to this rule.


Are WorkSite clients that use Kerberos Authentication supported with WorkSite Server versions prior to WorkSite Server 8.2 Patch 3?


No. WorkSite client versions 8.2 Patch 4 or later are not backwards compatible. These clients are not supported with any version of the WorkSite Server prior to WorkSite Server 8.2 Patch 3.


Can Trusted Login via Kerberos Authentication be disabled?

Yes. WorkSite client versions 8.2 P6 and later can be configured to use the 'Classic' Trusted Login instead of Kerberos Authentication for Trusted Login. For more information, refer to technote 82007-2181 Client Setting-Trusted Login Authentication Method


What does the WorkSite Server registry key "Enforce Kerberos Authentication" do?

The "Enforce Kerberos Authentication" registry option (available on the WorkSite Server 8.2 P3 or later) controls whether or not the WorkSite Server will allow non-Kerberos Trusted Login connections. When this setting is disabled (the default on install), legacy clients (pre-8.2 P4) can connect via Trusted Login to the WorkSite Server. When this setting is enabled, only clients that use Kerberos Authentication (8.2 P4 or later) are able to authenticate with the server via Trusted Login. Legacy clients will only be able to use Explicit Login. Kerberos-enabled clients configured to use 'Classic' will be unable to perform a Trusted Login. For more information, refer to technote 82007-2227 Server Setting: Enforce Kerberos Authentication.

See the tables below:

Enforce Kerberos Authentication Disabled (default):

Trusted Login-Kerberos Trusted Login-Classic Explicit Login
8.2 P4 or later clients Yes Yes Yes
pre-8.2 P4 clients No Yes Yes


Enforce Kerberos Authentication Enabled:

Trusted Login-Kerberos Trusted Login-Classic Explicit Login
8.2 P4 or later clients Yes No Yes
pre-8.2 P4 clients No No Yes


For more information on Kerberos Authentication, refer to the following technotes:

82007-2182 Configuring WorkSite for Kerberos Authentication
82007-2183 Troubleshooting Kerberos Authentication with WorkSite

Migrateduser

Troubleshooting Kerberos Authentication with WorkSite
________________________________________________________________________________________________
Technote Number: 82007-2183
Category: WorkSite Server, DeskSite, FileSite, OffSite
Product: 8.2 SP1
Created: 09/07/2007
Last Modified: 09/07/2007
________________________________________________________________________________________________
Sites should confirm that the following new requirements for Kerberos Authentication are met:



The WorkSite Service Account must now be a Domain User (unless the Local System Account is being used to start the WorkSite services).

The WorkSite Server must now be a member of a firm's Domain.


DmsLog.txt file on the WorkSite Server contains "DsServerRegisterSpn failed; error = 0x54b" or "DsServerRegisterSpn failed; error = 0x534" or "DsServerRegisterSpn failed; error = 0x2098" and users are unable to login from the WorkSite client using Trusted Login.



The WorkSite Server is not part of a Domain.

The WorkSite Server Service Account is not a Domain User Account (unless the Local System Account is being used to start the WorkSite services).

The Kerberos Authentication support configuration for the WorkSite Server is incomplete or incorrect.

The SPNs were not created correctly.


Users receive an "Unrecognized Exception" error on the WorkSite client.



There may be a problem with the Kerberos ticket. Log off from the current Windows session and then log back in.

Confirm that your Domain Name Server (ADS) is configured for Reverse Lookup/Reverse Lookup Zones.

Confirm that a host file with an entry for the WorkSite Server does not exist on the client machine.

Confirm that the results of an nslookup WorkSiteServerFQDN and an nslookup WorkSiteServerIPAddress on the client machine are identical.

Confirm that the results of a ping -a WorkSiteServerFQDN and a ping -a WorkSiteServerIPAddress on the client machine are identical.

In some environments SPNs may be case-sensitive. In those environments the case of the WorkSite Server Name specified in the SPN must match the case of the WorkSite Server Name returned by the DNS. You can use the Local System Account to start the WorkSite Server service and then verify that the SPN is created using the command setspn -L WorkSiteServerName or setspn -L WorkSiteServiceAccount.

If you are using DHCP rather than static IP addresses for servers, confirm that the Network Settings on all WorkSite Servers have been properly configured. The following option should configured on all WorkSite Servers: On the WorkSite Server go to Advanced TCP/IP Settings | WINS and then select "Use NETBIOS settings from the DHCP Server".


WorkSite clients returns an "SSPI Authentication for client failed." error.



This error will occur when using a Kerberos-enabled WorkSite client to connect to a WorkSite Server that does not use Kerberos Authentication.

It is likely that there is an issue with the Kerberos Ticket generated for the user. Close all applications and then download and install the KerbTray.EXE utility (KerbTray, KList, Kinit, etc. are applications that are available in from Windows Resource Kit) on the workstation in question. Launch the application and then use it to purge all Kerberos Tickets.

You can purge the Kerberos Tickets by following the procedure listed below:
After launching the KerbTray.EXE, you will notice that a green icon appears in your System Tray. Right-click on this green icon and select Purge Tickets.


WorkSite client returns an "Access denied." error and the DmsLog.txt on the WorkSite Server contains a "General Exception: 0x80090324 SSPIAuthenticate(207)" error.



Confirm that the clocks on the WorkSite clients and the WorkSite servers are synchronized with the Domain Controller clock.


Additional Resources:


Please refer to the following Microsoft guides for additional help:

Troubleshooting Kerberos Delegation: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx
Troubleshooting Kerberos Errors: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

You may also find the following Microsoft TechNet Article useful:

http://technet2.microsoft.com/windowsserver/en/library/bef202b0-c8e9-4999-9af7-f56b991a4fd41033.mspx?mfr=true