locked
What Domain Account should be used for C2WTS in SharePoint 2010? RRS feed

  • Question

  • I have installed a brand new farm, Sharepoint 2010 Standard on Windows 2008 R2.  I've configured Kerberos for SQL and SharePoint (verified that Kerberos is working with SQL and SharePoint Central Administration).  This is the start of our company's SharePoint experience (full-blown anyways, I've used WSS 2.0 and played with 3.0 in the past).

    The TechNet documentation suggests that if this is a new SharePoint farm, to use Claims-Based Authentication from the start on Web Applications.  It's also suggested to use a domain account to run the C2WTS service.

    My question is what domain account should be used for the C2WTS service?  I've already got many service accounts for different parts of SharePoint, and I wasn't sure if the C2WTS needed a special account as well, since there needs to be SPNs set on it.  Can I just use an existing account, and make sure the delegations are set right, or do I need to create a new account for just the C2WTS service?

    Thursday, September 23, 2010 2:55 PM

Answers

  • Yes. That's basically it. There are three rights needed.

    act as part of operating system
    log on as service
    impersonate client after authentication

    then the SPN and delegation setting (which of course requires a SPN on the identity of the service you wish to delegate to)

    You also need to ensure you use Delegation using Any Protocol - this is a limitation of the platform at present.

    Once you have set all this up, you must then change the service identity of the service using Manage Service Accounts wthin SharePoint Central Administration (the default identity is Local System). You must do this via CA and NOT services.msc.

    Then you must restart the service to ensure the configuration takes hold. This you can do from services.msc or the command prompt as normal.

    Also bear in mind that you must also make changes (not rights, but the SPN and delegation) to the applicaiton pool identity of the service application in play, if you are using a service application (e.g. BCS) within your solution.

    That Technet article you refer to is very confusing and badly in need of updating! Skip that, and use the vastly superior http://go.microsoft.com/fwlink/?LinkId=196600 whitepaper. Check out page 93, about half way down.

    I actually have a article in final edit on this exact topic which will be published next week.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
    • Marked as answer by TheMind Thursday, September 23, 2010 7:48 PM
    Thursday, September 23, 2010 7:37 PM

All replies

  • You can use Local System, which requires the delegation setting to be done on the computer account, and a restart.

    Or you can use a Domain Account as TechNet suggests, which avoids the setting being done on a computer account and the need for restarts. Also in a farm where more than one server is running c2wts you only need to configure one account.

    It doesn't really matter which account you use. However I would strongly recommend you create a dedicated sevice account for this as it is performing highly privileged operations (you need to grant these rights, such as impersonate a client, to the account) and you don't want other accounts to have those privileges.

    You only need to set the dummy SPN to force the delegation tab to appear in ADUC, if you configure the delegation settings in another way the SPN is not required.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
    Thursday, September 23, 2010 7:03 PM
  • You can use Local System, which requires the delegation setting to be done on the computer account, and a restart.

    Or you can use a Domain Account as TechNet suggests, which avoids the setting being done on a computer account and the need for restarts. Also in a farm where more than one server is running c2wts you only need to configure one account.

    It doesn't really matter which account you use. However I would strongly recommend you create a dedicated sevice account for this as it is performing highly privileged operations (you need to grant these rights, such as impersonate a client, to the account) and you don't want other accounts to have those privileges.

    You only need to set the dummy SPN to force the delegation tab to appear in ADUC, if you configure the delegation settings in another way the SPN is not required.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
    Thursday, September 23, 2010 7:03 PM
  • Spencer,

    So, I give the new dedicated service account the right permissions, set up a dummy SPN on this new dedicated service account, and then delegate to the SQL Server?

    I read TechNet's piece on Configuring Kerberos for the Claims to Windows Token Service, but they have more servers in their scenario, and the account labeling is different, so I don't want to get confused.

    Thursday, September 23, 2010 7:19 PM
  • Yes. That's basically it. There are three rights needed.

    act as part of operating system
    log on as service
    impersonate client after authentication

    then the SPN and delegation setting (which of course requires a SPN on the identity of the service you wish to delegate to)

    You also need to ensure you use Delegation using Any Protocol - this is a limitation of the platform at present.

    Once you have set all this up, you must then change the service identity of the service using Manage Service Accounts wthin SharePoint Central Administration (the default identity is Local System). You must do this via CA and NOT services.msc.

    Then you must restart the service to ensure the configuration takes hold. This you can do from services.msc or the command prompt as normal.

    Also bear in mind that you must also make changes (not rights, but the SPN and delegation) to the applicaiton pool identity of the service application in play, if you are using a service application (e.g. BCS) within your solution.

    That Technet article you refer to is very confusing and badly in need of updating! Skip that, and use the vastly superior http://go.microsoft.com/fwlink/?LinkId=196600 whitepaper. Check out page 93, about half way down.

    I actually have a article in final edit on this exact topic which will be published next week.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
    • Marked as answer by TheMind Thursday, September 23, 2010 7:48 PM
    Thursday, September 23, 2010 7:37 PM
  • Awesome, I got all the rest set up.  I had that Kerberos Guide already open, so I just scrolled down to page 93 and it listed the final steps.

    Knowing that I have nothing yet set up to use it, I can't verify there's any problems...but at least I know I set it up correctly.


    Thanks!

    Thursday, September 23, 2010 7:49 PM
  • Spence, first off, THANK YOU for the article you mention in your response above ("Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization"). Such a life saver!

    The white paper you reference ("Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products"), in "Scenario 5 – Identity Delegation for Excel Services," indicates the C2WTS service account--in addition to the rights you list--also needs to be a member of the local Administrators Group (bottom of pg. 97). I'm hoping you have omitted this because it's really not needed (wouldn't be the first time this white paper says to do something not necessary; just look at the revision history). I've found that adding the C2WTS service account to the local Administrators Group triggers the "Accounts used by application pools or service identities are in the local machine Administrators group" Health Analyzer rule with a warning. If this account doesn't really need local Administrators Group inclusion, I'd rather not have it there.

    From your experience and knowledge, I'm hoping you can answer: Does the C2WTS service account need local Administrators Group inclusion?

    Thanks,
       ---PaulE---

    Thursday, November 18, 2010 5:32 PM
  • Paul,

    Yes, in this case, it's required. the account you run the c2wts must be a local machine administrator of the machine(s) hosting c2wts.

    Of course this means the health analyzer will moan, but it's a hard requirement. c2wts won't work properly without the local admin rights.

    s.


    Cheers
    Spence
    www.harbar.net
    Microsoft Certified Master | SharePoint 2010
    Microsoft Certified Master | SharePoint 2007
    Thursday, November 18, 2010 6:32 PM