Specifying Non-Kerberos Authentication in Visual Studio Projects
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
In working with Visual Studio 2005, some authentication mechanisms require additional steps to set up. For example, Kerberos authentication requires Service Principal Name (SPN) registration and other related steps. For more information, see Registering Kerberos Service Principal Names by Using Http.sys.
HTTP endpoints configured to use the Integrated authentication can respond to clients using either Kerberos or NTLM as the authentication scheme. The actual scheme selected and used by the server, either Kerberos or NTLM, is based on whichever scheme the client uses in requesting authentication. For more information, see Endpoint Authentication Types.
This topic provides details about how to modify a Visual Studio 2005 project so that the Web services client application will request an authentication scheme other than Kerberos when Integrated authentication is selected as the authentication type on the server.
Typically, when you write a client application in Visual Studio 2005, you must set up credentials for use with your Native XML Web Services in SQL Server implementation. Assuming you are using Integrated authentication, you could use something like the following in your code:
myServer.sql_endpoint proxy = new myServer.sql_endpoint(); proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
However, if Kerberos authentication has not been correctly set up to work from other computers (SPN registration, and so on), Visual Studio 2005 will always try to use Kerberos as the authentication scheme, unless you explicitly disable Kerberos as an allowed authentication scheme on the HTTP endpoint (sql_endpoint) by selecting either NTLM, BASIC, or DIGEST as the authentication type. You might want to specify that Visual Studio 2005 use another supported scheme such as NTLM instead.
The following code shows how you can override the authentication scheme that Visual Studio 2005 uses and have the client application request NTLM be used instead as the authentication mechanism:
mattm1.sql_endpoint proxy = new mattm1.sql_endpoint(); System.Net.CredentialCache myCreds = new System.Net.CredentialCache(); myCreds.Add(new Uri(proxy.Url), "NTLM", System.Net.CredentialCache.DefaultCredentials.GetCredential(new Uri(proxy.Url), "NTLM")); proxy.Credentials = myCreds;
Although you can force Visual Studio 2005 to use NTLM instead of Kerberos on an INTEGRATED endpoint by using the previous code sample, we recommend creating an endpoint configured with AUTHENICATION=NTLM as the way to use NTLM when Kerberos cannot be used because of SPN issues.
Additional Configuration Requirements for the Development Environment
The modifications to your code mentioned in the previous section will allow the client application to specify and use an authentication scheme other than Kerberos, but additional tasks are required to support your application when you are running and testing it in the development environment.
Note, by default, the add Web reference functionality in Visual Studio always uses Kerberos when it tries to retrieve the WSDL response from the Web service. To avoid this, you can do the following workaround steps:
Set up Kerberos authentication correctly for your development environment. This involves registering Kerberos SPNs for you as a single user or, if applicable, for a domain group of developers. For more information, see Registering Kerberos Service Principal Names by Using Http.sys.
Temporarily disable Kerberos on your endpoint. By using the following ALTER ENDPOINT procedure to switch to DIGEST mode you can correctly obtain the WSDL response.
ALTER ENDPOINT endPointName AS HTTP ( AUTHENTICATION = DIGEST )
Add the Web reference in your Visual Studio 2005 project.
Switch the endpoint back to INTEGRATED mode as follows:
ALTER ENDPOINT endPointName AS HTTP ( AUTHENTICATION = INTEGRATED )
Alternatively, you could follow these steps:
Retrieve the WSDL response through another mechanism, such as by using Internet Explorer and saving the WSDL response to a file.
Add the Web reference in Visual Studio from the file instead of as a URL, such as: http://MyServer/sql_endpoint?wsdl.