Home > Kerberos, Microsoft, SharePoint 2007 > Kerberos – Basics – Security – Config – SharePoint – Troubleshooting

Kerberos – Basics – Security – Config – SharePoint – Troubleshooting

May 5th, 2008
Goto comments Leave a comment

I’ve been doing a reasonable amount of work lately which has involved configuration and troubleshooting of kerberos, so I thought I would throw together a post to help other who run into issues or just want a general understanding. If you would like me to expand further on any section post a comment and I’ll add some more details. Any thing thats wrong also add a comment and I’ll amend and throw you a shout out :)

Basics

A brief overview of how kerberos works at the protocol level:

Abbreviations:

  • AS = Authentication Server
  • TGS = Ticket Granting Server
  • SS = Service Server
  • TGT = Ticket Granting Ticket

Client logon process:

The client authenticates to the AS using a long-term shared secret (a shared secret is a piece of data known only to the parties involved in a secure communication, it can be a password, a passphrase, a big number or an array of randomly chosen bytes) and recieves a ticket from the AS. The client can then use this ticket to get additional tickets for the SS without resorting to using the shared secret. These tickets can be used to prove authentication to an SS.

Client based logon Steps:

  1. A user enters a username and password on the client machine
  2. The client performs a one-way function (it turns the input into a hash value which is extremely hard to reverse) on the entered password, and this becomes the secret key of the client.

Client Authentication Steps:

  1. The client sends a cleartext (form of message readable by a person without any additional processing) message to the AS requesting services on behalf of the user.
  2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
    1. Message A: Client/TGS Session Key encrypted using the secret key of the user.
    2. Message B: Ticket-Granting Ticket (includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.
  3. Once the client receives messages A and B, it decryptes message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: the client cannot decrypt Message B, as it is encrypted using the TGS’s secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization Steps:

  1. When requesting services, the client sends the following two messages to the TGS:
    1. Message C: Composed of the Ticket-Granting Ticket from message B and the ID of the requested service.
    2. Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
  2. Upon Recieving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret Key . This gives it the “client/TGS Session Key”. Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
    1. Message E: Client-to-server tocket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service’s secret key.
    2. Message F: Client/Server session key encrypted with the Client/TGS Session Key.

Client Service Request Steps:

  1. Upon receiving messages E and F from the TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:
    1. Message E from the previous step (the client-to-server ticket, encrypted using the service’s secret key).
    2. Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using the client/server session key.
  2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, the SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
    1. Message H: the timestamp found in the client’s Authenticator plus 1, encrypted using the Client/Server Session Key.
  3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
  4. The server provides the requested services to the client.

Security

Possible security related issues with kerberos:

  • All the secret keys for all users are stored on a central server, a compromise of this server will compromise all the users secret keys.
  • If kerberos constrained delegation is not used, when a user authenticates the service can access any network resource using the users identity. This can be dangerous if the service is compromised.

Config

Abbreviations:

  • SPN = Service Principal Name

Authentication Scenarios:

(Note: These are kerberos specific for scenarios see the “Troubleshooting Kerberos Delegation in Windows 2000 and Windows Server 2003″ reference.)

Kerberos Authentication:

With Kerberos authentication, when the user authenticates to the front-end server, the server transitions from running under its own service account to running under the user’s account. The front-end server can then impersonate the user and access any resources that the user is authorized to access. Furthermore, the back-end server can verify that the user is the entity who is requesting access.

Delegation enables the user’s credentials to be passed from one server to another and for the user’s identity to be preserved as services are requested from one computer to another. Thus, the front-end server illustrated in Figure 4 could be replaced by multiple middle tier servers, but the user would still need to be impersonated in communications with the back-end server.

Kerberos Authentication Using Constrained Delegation:

In Windows Server 2003, constrained delegation provides a way for domain administrators to limit which network resources an account trusted for delegation can access. (Note:
Constrained delegation is possible only if the domain is 2003 domain functional level)

In order to limit the resources that services can access on behalf of a user, you can configure constrained delegation by listing services to which an account can present delegated credentials. This list is in the form of SPNs that the user is allowed to delegate to. In constrained delegation, the Web service’s account only receives permission to delegate to the back-end server’s SPN.

Config Requirements:

  • User Account:
    • Account is sensitive and cannot be delegated is not selected on the users Active Directory Profile.
  • Service Account:
    • Account is trusted for delegation
    • SPN is registered
  • Back-end Service Account:
    • SPN is registered

Notes:

  • SPN’s can only be registered by a Domain Administrator account, if the service account is a domain user account
  • If using constrained delegation, then middle tier services and back-end services must be in the same domain

Creating SPN’s:

To create and SPN download SetSPN, for a list of commands type setspn.exe /? in a cmd window. To add an SPN for an IIS server using HTTP you would run the below substituting the parts in italic where appropriate:

setspn.exe -A HTTP/server1 server1

setspn.exe -A HTTP/server1.domain.local server1

If the service is running as an account other then network service or local service add the SPN’s for the service account like so: (Note: DO NOT DO THE PREVIOUS COMMANDS AGAINST THE SERVER IF YOU ARE DOING THE BELOW, IT WILL CAUSE KERBEROS ERRORS)

setspn.exe -A HTTP/server1 domain\serviceaccount1

setspn.exe -A HTTP/server1.domain.local domain\serviceaccount1

This needs to be done for the middle-tier server and the back-end server (back server may be a SQL server for instance or another HTTP service etc)

You must also add you service account/accounts to the following Local security Groups on all front-end and middle-tier servers:

  1. Act as part of the operating system
  2. Impersonate a client after authentication

To do this:

  1. Open the Local Security Policy by clicking Start -> Administrative Tools -> Local Security Policy
  2. Click Local Policies -> and then click User Rights Assignment.
  3. Add the service account to the two security groups

Both of these privileges give an account the ability to act as another user. The Impersonate a client after authentication privilege is similar to the Act as part of the operating system privilege except that it is not as far-reaching. That is, it will only allow a process to impersonate after authentication, whereas Act as part of the operating system privilege allows a process to impersonate before authentication

SharePoint:

Configuring Kerberos for SharePoint:

Configure IIS to Support Kerberos:

To configure IIS to support the kerberos protocol perform the following (Note: Make sure to repeat this on each IIS/SharePoint Server)

  1. Start -> Run -> cmd
  2. Locate the directory that contains the Adsutil.vbs file. By default, this directory is C:\Inetpub\Adminscripts
  3. Use the following command to retrieve the current values for the NTAuthenticationProviders metabase property:
    1. cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders (In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.)
  4. If the command in step 3 does not return the string “Negotiate,NTLM,” use the following command to enable the Negotiate process:
    1. cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders “Negotiate,NTLM”
  5. Repeat step 3 to verify that the Negotiate process has been enabled

Registering service account SPN’s:

Using Least-Privilege installation (8 separate service accounts, Plan For administrative and service accounts), I’ve assumed the accounts are already created you simply need to fill in the appropriate sections between the “%”. Please see the notes and the end of this section before planning any SPN creation as to avoid any issues further into your installation.

  • Command
    • Notes
  • Setspn.exe -A HTTP/%SHAREPOINTSERVERFQDN% %SERVERFARMACCOUNT%
    • %SHAREPOINTSERVERFQDN% = the FQDN of your SharePoint server’s NetBIOS name (local machine name)
    • %SERVERFARMACCOUNT% = Server Farm Account
    • Example: Setspn.exe -A HTTP/server.domain.local domain\serverfarm
  • Setspn.exe -A HTTP/%MYSITEURLFQDN% %MYSITEAPPPOOLACCOUNT%
    • %MYSITEURLFQDN% = the FQDN of the host header for the My Site Web Application
    • %MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses
    • Example: Setspn.exe -A HTTP/mysite.domain.local domain\mysiteapppool or Setspn.exe -A HTTP/server.domain.local domain\mysiteapppool
  • Setspn.exe -A HTTP/%MYSITEURLHOST% %MYSITEAPPPOOLACCOUNT%
    • %MYSITEURLHOST% = the host name (i.e. without the .domain.local bit) for the My Site web application
    • %MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses
    • Example: Setspn.exe -A HTTP/mysite domain\mysiteapppool or Setspn.exe -A HTTP/server domain\mysiteapppool
  • Setspn.exe -A HTTP/%PORTALURLFQDN% %PORTALAPPPOOLACCOUNT%
    • %PORTALURLFQDN% = the FQDN of the host header for the main portal or intranet Web Application
    • %MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses
    • Example: Setspn.exe -A HTTP/portal.domain.local domain\portalapppool
  • Setspn.exe -A HTTP/%PORTALURLHOST% %PORTALAPPPOOLACCOUNT%
    • % PORTALURLHOST % = the host name (i.e. without the .domain.local bit) for the Portal web application
    • %MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses
    • Example: Setspn.exe -A HTTP/portal domain\portalapppool
  • Setspn.exe -A HTTP/%SSPADMINURLFQDN% %SSPADMINAPPPOOLACCOUNT%
    • % SSPADMINURLFQDN % = the FQDN of the host header for the SSP Administration Web Application
    • % SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses
    • Example: Setspn.exe -A HTTP/sspadmin.domain.local domain\sspadminapppool
  • Setspn.exe -A HTTP/%SSPADMINURLHOST% %SSPADMINAPPPOOLACCOUNT%
    • % SSPADMINURLHOST % = the host name (i.e. without the .domain.local bit) for the SSP Administration web application
    • % SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses
    • Example: Setspn.exe -A HTTP/sspadmin domain\sspadminapppool

Trusting Service accounts for delegation:

Open Active Directory Users and Computers MMC (As a domain administrator) -> locate the account/computer and go to properties -> Navigate to the Delegation Tab -> Choose Trust this user/computer for delegation to any service (Kerberos). This needs to be done for the following accounts:

  • MOSS Server (Computer Account), if there are multiple it must be done fore each server
  • SQL Server (Computer Account)
  • FarmService (User Account)
  • MySiteAppPool (User Account)
  • SSPAdminAppPool (User Account)
  • PortalAppPool (User Account)

Enable Kerberos on your Web Application:

For a fresh install of SharePoint, as your running throught the SharePoint Products and Technologies Configuration Wizard make sure to select kerberos authentication for Central Administration. If the farm is already created follow this procedure to enable kerberos:

  1. Open Central Administration
  2. Navigation to Application Management -> Authentication Providers
  3. Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application)
  4. Click on Default
  5. Set the authentication to Negotiate (Kerberos)
  6. Perform an IIS Reset (start -> run -> iisreset)

Enable Kerberos on Your SSP:

  1. Open a Command Prompt and navigate to your ‘12\Bin’ directory (normally c:\program files\common files\microsoft shared\web server extensions\12\bin)
  2. Run STSADM.exe -o SetSharedWebServiceAuthn -negotiate

Component Services Configuration:

This must be done on each moss server if there are more then one:

  1. Open Component Services on the MOSS server (Start -> Administrative Tools -> Component Services)
  2. Navigation to Component Services > Computers > My Computer
  3. Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate
  4. Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
  5. Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
  6. Edit Launch and Activate Permissions
  7. Grant all three of your application pool accounts ‘Local Activation‘ permissions (see http://support.microsoft.com/kb/920783). In this example, these accounts would be domain\MySiteAppPool, domain\SSPAdminAppPool, domain\PortalAppPool

Troubleshooting:

I wont go into massive amounts of detail for troubleshooting kerberos as the microsoft article will work you right through a verify low level approach (Troubleshooting Kerberos Delegation in Windows 2000 and Windows Server 2003). The main things to do when your trouble shooting kerberos are to first confirm your SPN’s are set correctly, for hosts and service accounts where appropriate, you can do this by running either of these commands where appropriate:

  1. setspn.exe -L server1
  2. setspn.exe -L domain\serviceaccount1

This will list the associated SPN’s with the host or service account you enter.

The best way to move from there is then check your accounts are all allowed for delegation within active directory (this includes service accounts and servers), making sure the Account is sensitive and cannot be delegate option is not selected on any service accounts.

Then verify that the service accounts are added to the following groups on your front-end and middle-tier servers:

  1. Act as part of the operating system
  2. Impersonate a client after authentication

After verifying that then run up kerbtray (this is part of the 2003 resource kit Windows Server 2003 Resource Kit Tools) on the client computer. Then enable Failure audits on your front-end, and middle-tier servers, you can do this by doing the following:

  1. Open local security policy by clicking Start -> Administrative Tools -> and then Local Security Policy.
  2. Click Local Policies -> and then Audit Policy.
  3. Right-click Audit account logon events.
  4. Select Define these policy settings.
  5. Under Audit these attempts: be sure that both Success and Failure are selected.
  6. Click OK.
  7. Repeat steps 3-6 for Audit logon events to record both success and failures.

Once this is done attempt to login to the site, if you are authenticating with kerberos you will see a new ticket appear in kerbtray. If you fail to login check the security logs on the front-end and middle-tier servers, and verify what failure logins you are receiving. If you are note getting any failures verify you are note getting any kerberos related errors in the System and Application Event Logs. If you are there is descriptions for these errors here: Troubleshooting Kerberos Errors

If you are getting duplicate SPN errors you can use the following tool to query Active Directory for all SPN’s, once you have this you can verify if there is a dupicate assigned to another object:

  • ldifde -f C:\filename.txt -d dc=tower,dc=lan -r (objectclass=computer) -p subtree
  • LDIFDE –f filename.txt –t 3268 –d “DC=forest,DC=Root,DC=com” –l serviceprincipalname

(Note: For details around the switches and an explanation run ldifde /?)

Note: For a multi-server environment:

  • HTTP/URL, SPN’s will need to be setup for each DNS name used to access the sites.
    • On the Central Administration Server assuming you are using host names to access you will need to do:
      • setspn.exe -A HTTP/server1 domain\serviceaccount1
      • setspn.exe -A HTTP/server1.domain.local domain\serviceaccount1
    • For each additional site using a different DNS name you will need to do the following: (Note: this assumes you are using a local domain name domain.local) In the event that there are multiple front-end web servers(load balanced) you must do this you cannot assign the SPN to a server, it must be assigned to a service account.
      • setspn.exe -A HTTP/intranet domain\serviceaccount1
      • setspn.exe -A HTTP/intranet.domain.local domain\serviceaccount1
    • If the site is available via a DNS entry such as intranet.domain.local and it can be resolved via just intranet you must make sure you create an SPN for both short name and FQDN otherwise you will most likely run into authentication issues
    • Uninstall Internet Explorer Enhanced Security Configuration from Add/Remove Programs -> Windows Components. This compnent can cause login issues with SharePoint

References

Related Articles:

This posting is provided “AS IS” with no warranties, and confers no rights.

Blogged By Jason Neurohr

Share or Bookmark This Post
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Technorati
  • TwitThis
  • Live
  • Identi.ca
  • PDF
  • Ping.fm

Kerberos, Microsoft, SharePoint 2007 ,