• Greg Edwards-268690 (12/9/2011)


    bruce.l.pettus (12/9/2011)


    I'm in the process of implementing a solution so I'm not entirely confident I'm correct; however, I wanted to point out an issue with the SPN comment.

    To my knowledge, the ability to write an SPN to the AD requires domain admin permissions and I'm fairly sure the AD admins will have a problem with this. My solution (still in progress) is to...

    1. Specify a static IP port for the SQL instance(s).

    2. Request creation of SPNs for servers involved in the double-hop connection.

    3. Request the SQL service accounts be granted "trust for delegation" permissions.

    If you change the IP port of the SQL instance you'll need to request the SPN be updated to match the new IP port.

    Any domain admin should recognize kerberos as a much more secure method than allow anonymous.

    And far more secure than using basic on a web site too.

    The service accounts and the machines need to be allowed to delegate.

    And there is also contrained delegation, which is much more specific.

    I have never had any push back in my company on using Kerberos.

    And the domain admins were thankful for my help in setting up and troubleshooting.

    If the service is running under a domain account, the machine account plays no role in kerberos authentication.