Preliminary Draft: Kerberos Configuration Cerner MethodM (MOSS 2007) Implementation.

This document is to outlines the steps necessary for MOSS 2007 to use the Kerberos authentication protocol. Kerberos is required whenever something in SharePoint needs to access another service on the user's behalf (i.e. double hop) In SharePoint, 'double hops' are most commonly seen when webparts need to access other web services or databases. In MOSS 2007, the most common scenarios are around Excel Services, Data Connections and connecting to SQL Server Analysis Services cubes. (I.e. 'hopping' from the Excel services webpart to the SQL analysis cube). The definition of a 'double hop' is where a user authenticates to a web server and that web server then needs to impersonate the user against another service. When this happens, the user's authentication ticket is 'hopping' across two services; this is not allowed in NTLM and you will have to use Kerberos to do this.
Figure 1: Double Hop Illustration

The following provides the necessary steps to configure MOSS 2007 to use Kerberos authentication. Step 1: Configure SPNs The first thing you will need to do in order to enable Kerberos for SharePoint is configure Service Principle Names (SPNs) for your SharePoint service accounts in Active Directory. If SharePoint was installed properly, you should use the 'least privilege account principle'; this basically means that each distinct service inside the SharePoint farm will have its own domain user account. These accounts should have the minimum privileges that they need to perform their jobs.

Some services require the fully qualified domain name (FQDN) even if your users only use the host name, whereas some SPNs require only the host name. It has become a best practice to configure both host name and FQDN SPNs for each service account. You may have read KB articles that indicated setting the SPN on the computer account! Well, yes, that would be accurate *IF* the process handling authentication was running as SYSTEM. If the process for that service is not running as SYSTEM (or Network Service, or Local Service) then you cant set the SP N on the computer account (well you can but Kerberos isnt going to work). The whole purpose of 'least privilege account principle' is to not use built-in accounts, particularly the SYSTEM account as it has access privileges beyond what is needed by SharePoint services. An SPN should be in the format of ServiceType/NetBIOSName *and* ServiceType/FQDN and we *always* set that on whatever account is running the process that is handling the authentication. Add your customized list of SPNs here:

Command

Notes
%SHAREPOINTSERVERFQDN% = the FQDN of your SharePoint server's NetBIOS name (local machine name)

Setspn.exe -A HTTP/%SHAREPOINTSERVERFQDN% %SERVERFARMACCOUNT%

%SERVERFARMACCOUNT% = Server Farm Account HTTP/grdspwebext00.cerner.com cerner\svcMOSS_SQLadmin_extranet HTTP/grdspwebext01.cerner.com cerner\svcMOSS_SQLadmin_extranet

Step 2: Trust for Delegation

After setting the SPNs for each of the service accounts, you will also need to trust each of the computer accounts and some of the service accounts for delegation. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf. Active Directory Settings Checklist: Make sure that all the following conditions are true for the Active Directory directory service settings: Verify that SPNs are registered for middle-tier services and back-end services Verify you do not have duplicate SPNs (must be unique throughout the forest) Verify that the Account is sensitive and cannot be delegated setting is not enabled for user accounts that will be delegated. Middle- tier computer accounts must be trusted for delegation Middle- tier service accounts must be trusted for delegation Verify that the correct user rights for middle-tier service accounts are granted (e.g. step 10 below)

In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions: (NOTE: if the service account does not have the delegation tab, this mean that an SPN was not registered)

1.

In the Active Directory Users and Computers console tree, expand the Domain Name node and click Computers. In the details pane, double-click the name of the appropriate web/application Server computer. On the Delegation tab, select Trust this computer for delegation to specified services only and then
select Use Kerberos Only. (this setting indicates Kerberos Constrained Delegation) Click Add. In the Add Services dialog box, click Users or Computers. In the Select Users or Computers dialog box, enter the NetBIOS name of the web server (or names of the servers in a server farm). Click Check Names after you type each name, and then click OK.

2. 3.
4. 5. 6.

7.

In the Add Services dialog box, find http in the list of available services. Select the entry for the web server (or hold down the CTRL key and select the entries for the servers in a server farm) and click OK.

8.

On the Delegation tab, verify that http appears under Service Type and that the name of the server (or names of the MOSS servers in a server farm) appear under User or Computer, and then click OK.

9. For service accounts on the delegation tab, select Account is trusted for delegation, then click OK. 10. You must configure the following user rights only on middle-tier service accounts: o Act as part of the operating system o Impersonate a client after authentication Repeat steps 2 through 10 for each of the following (Note distinction - *User* and *Computer* account): o o o o o o MOSS Server (Computer Account) SQL Server (Computer Account) FarmService (User Account) MySiteAppPool (User Account) SSPAdminAppPool (User Account) PortalAppPool (User Account)

Step 3: Enable Kerberos on your web applications In MOSS 2007, you can switch between Kerberos and NTLM via Central Administration. Open Central Administration Navigate to Application Management > Authentication Providers Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application) Click on 'Default' Set the authentication to Negotiate (Kerberos)

Perform an IISRESET

Step 4: Enable Kerberos on your SSP In this step you enable Kerberos on your SSP. Follow these steps: Open a Command Prompt and navigate to your '12\Bin' directory (normally c:\program files\common files\microsoft shared\web server extensions\12\bin)

Run 'STSADM.exe -o SetSharedWebServiceAuthn -negotiate' Step 5: Component Services Configuration (For SQL Analysis Services and other COM+ Services) 1. Create the SPN for the Analysis Services server that is running under a domain account: o Setspn.exe -A MSOLAPSvc.3/Fully_Qualified_domainName OLAP_Service_Startup_Account Note: the service type MSOLAPSvc.3 and Fully_Qualified_domainName is a placeholder for the FQDN. o 2. Setspn.exe -A MSOLAPSvc.3/serverHostName OLAP_Service_Startup_Account

If you must create the SPN for the Analysis Services server that is running under the LocalSystem account, run the following commands at a command prompt: o o Setspn.exe -A MSOLAPSvc.3/Fully_Qualified_domainName serverHostName Setspn.exe -A MSOLAPSvc.3/serverHostName serverHostName

Note SQL Server 2005 Analysis Services can operate as a named instance. If you are using a named instance, the same steps apply. However, you must configure the following SPN formats. Unlike with the SQL Server engine, you cannot specify a port after the colon. You must use the actual instance name for all functionality to work correctly.

3. MSOLAPSvc.3/serverHostName.Fully_Qualified_domainName :instanceName 4. MSOLAPSvc.3/serverHostName:instanceName

Make sure that all the following conditions are true for the Active Directory directory service settings: The Account is sensitive and cannot be delegated setting is not enabled for user accounts that will be delegated. The Account is trusted for delegation setting is enabled for the domain account of the middle tier that is connecting to Analysis Services. For example, if IIS is the middle tier and a domain account is used for the application pool, that application pool domain account must have the Account is trusted for delegation setting enabled.

The Account is trusted for delegation setting is enabled for the accounts of all services and COM+ components that are involved in the process. The Trust computer for delegation setting is enabled for all the computers that are involved in the process

The following is one of the lesser documented steps. You need to set various permissions in Component Services. Follow these steps: Open Component Services on the MOSS server Navigation to Component Services > Computers > My Computer Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab Edit Launch and Activate Permissions Grant all of your application pool accounts 'Local Activation' permissions.

Step 6: Configure Permissions in SQL AS This section specifically relates to using SQL Analysis Services, but similar steps will be required for normal SQL or Reporting Services. In order that users can access your SQL AS cube, you need to configure permissions inside SQL Management Studio. Follow these steps: Open SQL Management Studio Connect to Analysis Services Right-click on the server level and go to properties Go to the Security tab Give the relevant users access. If you want everyone to have access, add 'authenticated users'

This will mean that user have access to actually read the data from the AS cube. Step 7: Configure Excel Services for Delegation One of the key configuration challenges for administrators has been configuring Excel Services to use Delegation (i.e. to use Kerberos rather than NTLM). This is a setting that you can only set by using STSADM.exe; you cannot set it through the SharePoint Administration pages and it is not well documented.

Follow these steps: On your SharePoint server, open a command prompt and navigate to c:\program files\common files\microsoft shared\web server extensions\12\bin Run the following command where %SSPNAME% is the name of your Shared Service Provider: o stsadm.exe -o set-ecssecurity -ssp %SSPNAME% -accessmodel delegation

Run the following command: o stsadm.exe -o execadmsvcjobs

Now perform a IISRESET

Step 8: Create your Data Connection file Now that Excel Services has been configured, you need to make sure that the data connection has the right settings for Kerberos. Typically in this scenario, a data connection file will be created and stored in a SharePoint data connections library. This ensures that you only have to set the data connection up once and use it many times. There are several key settings that must be in the data connection file in order for Kerberos to work, these include using the FQDN of the SQL server and adding SSPI=Kerberos to the connection string. Follow these steps: Open Excel 2007 (Client) Go to the 'Data' ribbon In the 'Get external data' area click on 'From Other Sources' and choose 'From Analysis Services' Enter the FQDN of your SQL server here (i.e. server.domain.local, not just server), leave the default of 'Use Windows Authentication' and click Next Choose the database and cube that you wish to connect to and click Next; Click Finish on the following screen. Choose to show a pivot table (this is not relevant and will not be used at this stage) and click OK Once the pivot table is displayed, it is a good idea to test it out to make sure you got the right settings Go to the 'Data' ribbon and click 'Properties' Go to the 'Definition' tab of the connection properties dialog Add ';SSPI=Kerberos' (without the ') at the end of the connection string (after MDX Missing Member Mode=Error) Now Export your data connection to SharePoint by clicking 'Export Connection File'

Enter the full URL to the Data connection library that you wish to save you data connection to and click 'Save'.

You may now close Excel and disregard the spreadsheet (you have got the data connection in SharePoint which is the bit you need) Step 9: Configure your site Now that youve created the data connection, you can go ahead and configure your site. Generally one of the first things to do is to add a 'SQL Server 2005 Analysis Services Filter' webpart which uses the data connection to provide filters to other webparts on your site. This is one of the first places to test Kerberos. When you add the SQL AS Webpart, you will first need to choose the data connection. Upon doing this the Dimension drop-down should populate with dimensions from SQL. If this works then Kerberos is working!

IIS Settings Checklist Middle Tier: Make sure that all the following conditions are true for service accounts running on IIS web servers service settings: IIS account SPN created IIS account is Trusted for Delegation IIS is set to Windows Integrated Authentication. COM+ package impersonation level should be changed from Impersonate to Delegate Web application must specify a trusted connection to the SQL back end; i.e. Integrated Security=SSPI in the connection string User has appropriate permissions on the middle-tier server

SQL Server Settings Checklist Back End: SQL account SPN created Windows logons must be given permissions to database Microsoft recommends using Windows authentication rather than mix mode Must be listening on the protocol that the web server is using to connect TCP/IP or Named Pipes

Client Settings Checklist: Verify client application is configured for Kerberos protocol with these options set: o Enable Windows Integrated Authentication o Bypass proxy for local addresses o Middle-tier server Listed in Trusted sites Verify the client is indeed using Kerberos: o Check security log on middle-tier server for NTLM success audits o Use KerbTray or Klist to view Kerberos tickets after connecting o Use Network Monitor to view Kerberos traffic