locked
Problems trusting Management web server for delegation RRS feed

  • Question

  • I am building an App-V 4.6 service using a distributed architecture, with the management web service on a dedicated IIS7 (Windows 2008 R2) server, and a SQL 2008 server on another (Windows 2008 R2) server. The SQL server service is running under a domain user account, NOT a built in local account.

    I am having some difficulty setting the management web server to be trusted for delegation to the MSSQLSVC service running on the SQL server. Under active directory users and computers I select the management web server, select "trust this computer for delegation to specified services only", then add my SQL server. The problem is, under the SQL server the MSSQLSVC service isn't listed, although all the other usual Windows services are there. What is really confusing me is that if I set the SPN for the SQL server to sqlservername (i.e. what you should only do if SQL is using local system account), the MSSQLSVC service IS listed OK, but the thing is, SQL is using a domain user account for the SQL service and NOT  a built in local account. I have set the SPN for the SQL server by entering setspn.exe -a mssqlsvc/servername:1433 domain\serviceaccount and also setspn.exe -a mssqlsvc/servername.fqdn:1433 domain\serviceaccount, and the MSSQLSVC service is NOT listed, but when I change the SPN by entering setspn.exe -a mssqlsvc/servername:1433 servername, the MSSQLSVC service IS listed. In other words, it seems to me that I have to set the "wrong" SPN for the service to be listed. The obvious work-around would be to reconfigure SQL server to use the built in local account, but we will be using a cluster (even though it's just one server at the moment) hence the need to use a domain service account. I have reviewed everything in

    http://blog.appvtraining.com/Blog/tabid/87/EntryId/2/Running-the-App-V-Management-Console-from-a-remote-Computer.aspx

    and

    http://blogs.technet.com/b/appv/archive/2009/04/21/app-v-4-5-remote-console-configuration-guide.aspx

    and as far as I can see I'm not soing anything obviously wrong.

    I suspect that there is a basic step I am missing,m required  when using a domain service account for the SQL service.

     

    Tuesday, June 7, 2011 3:37 PM

Answers

  • I think I've now resolved the problem. Like a lot of things, it's very obvious once you know it! If you are using a domain\serviceaccount for SQL rather than a local SQL service account, then, when setting the management web server to be trusted for delegation, you need to trust it for delegation to the SQL server's domain\serviceaccount object and NOT the SQL server object. When I do this, the MSSQLSVC service is listed as it should be.

    The instructions in the various online documents referred to above assume that you have a local SQL service account, and this is the reason they all say to set the management werb server to be trusted for delegation to the SQL SERVER rather than the SQL service account. I was following these instructions almost verbatim, without really understanding what the trust for delegation is actually doing.

    Thanks Znack and Aaron for your replies.

     

    Wednesday, June 8, 2011 12:14 PM

All replies

  • Hello,

    What problems are you experiencing if you set the SPN to the hostname ?
    /Znack
    Tuesday, June 7, 2011 3:43 PM
  • This document may have some additional information:

    How to Configure the Server to be Trusted for Delegation
    http://technet.microsoft.com/en-gb/library/ee675779.aspx



    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
    Tuesday, June 7, 2011 3:49 PM
    Moderator
  • If I set the SPN to the hostname , i.e. setspn.exe -a mssqlsvc/servername:1433 servername, it works i.e. the MSSQLSVC service is listed, but according to my understanding, it shouldn't work like this as SQL is running under domain\serviceaccount. I thought that if the SQL server was running under domain\service account, then my SPN settings should match this? Although setting SPN to the hostname makes the MSSQLSVC service appear in the list, I assume I'm going to have kerberos errors later down the track when I try to use it, due to the mis-match between SQL service account (domain\serviceaccount) and my SPN settings (servername)?
    Tuesday, June 7, 2011 3:50 PM
  • Hello,

    Have you verified by actually testing the setup that there will be a kerberos mismatch? 
    /Znack
    Tuesday, June 7, 2011 3:58 PM
  • No I haven't got far enough through the install yet to actually verify this (as I'm still still stuck on getting this bit to work). I assume that the SPN must match the account which SQL server actually uses, according to my (admittedly patchy) understanding of kerberos.
    Wednesday, June 8, 2011 7:55 AM
  • I've been following the steps listed in this document under the heading: To configure constrained delegation when the Domain Functional Level is Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

    Wednesday, June 8, 2011 8:08 AM
  • Hello,

    Since you are using a service-account - we usually recommend to grant that permissions to register the SPN on its own during startup (and unregister during shutdown).

    See this article;

    http://support.microsoft.com/kb/319723


    /Znack
    Wednesday, June 8, 2011 8:33 AM
  • I wasn't able to get the permissions working for the SQL account as described in http://support.microsoft.com/kb/319723, but as a temporary measure I deleted the existing SPNS for my SQL service account, then made this account a member of domain admins, then re-started the SQL service. The SQAL sdervice automatcially creates 2 SPNs as follws:

    MSSQLSvc/servername.fqdn:1433 domain\serviceaccount

    and

    MSSQLSvc/servername.fqdn domain\serviceaccount

    The MSSQLSVC service is still not listed under the SQL server when I try to trust the web server for delegation.

    I also tried manually adding the following SPNs:

    MSSQLSvc/servername:1433 domain\serviceaccount

    and

    MSSQLSvc/servername domain\serviceaccount

    (i.e. without the fqdn bit)

    Still no luck.

    Wednesday, June 8, 2011 10:41 AM
  • I think I've now resolved the problem. Like a lot of things, it's very obvious once you know it! If you are using a domain\serviceaccount for SQL rather than a local SQL service account, then, when setting the management web server to be trusted for delegation, you need to trust it for delegation to the SQL server's domain\serviceaccount object and NOT the SQL server object. When I do this, the MSSQLSVC service is listed as it should be.

    The instructions in the various online documents referred to above assume that you have a local SQL service account, and this is the reason they all say to set the management werb server to be trusted for delegation to the SQL SERVER rather than the SQL service account. I was following these instructions almost verbatim, without really understanding what the trust for delegation is actually doing.

    Thanks Znack and Aaron for your replies.

     

    Wednesday, June 8, 2011 12:14 PM