How to force usage on NTLM

Hi,
By default Windows authentication will use Kerberos to do the
authentication. Is there a way to force a SQL Server instance to use
NTLM rather than Kerberos - as a server setting?
Thanks,
-RonHi Ron,
No unfortunately, there isn't . I have filed a "Design Change Request"
on this though.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I found this question interesting and wanted to know the pros and cons of
one method over another
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:91hgbFXMFHA.560@.TK2MSFTNGXA03.phx.gbl...
> Hi Ron,
> No unfortunately, there isn't . I have filed a "Design Change Request"
> on this though.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>|||Hi Kevin,
Thanks for the reply - and the change request is a good thing to look
forward to.
In the interim, I'm wondering whether you can shed some light on what
would be needed to build a "quick-and-dirty" workaround. What I'm
trying to understand is what the fall-back looks like. For example,
what does SQLServer look for in determining whether or not it has
access to kerberos authentication? Does it send something ove rthe
network? If I were to stop it using a firewall on a certain port would
I eventually get it to use NTLM? Any reference to what actually goes on
under the covers in Kerberos authentication that can help me work
something out?
Thanks for the help,
-Ron|||Well, one thing you could try is to force the connection to use Named
Pipes. I believe the last time I tested this, Named Pipes would always
authenticate via NTLM. Whereas with TCP to make a Trusted Connection we
rely on SSPI and always try Kerberos first. Named Pipes can impersonate
the client natively, and don't need to go thru the SSPI api. Essentially,
there should be less overhead with Trusted Connections using Pipes that
Sockets in this regard.
Hope this helps,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thanks again Kevin - great idea - I'll try that.
One more question if you don't mind. I inderstand (kind of) the use of
the Windows services for the authentication and authorization piece.
However, I noticed that even when this is used the sysprocesses table
always has teh right information - e.g. PROGRAM_NAME. That means that
eventually the information is being decrypted by SQL Server itself from
the TCP/IP handshake. Is this true or is this also a service provided
by SSPI? Is there anywhere to read up on this - the more I think I
understand the mechanism the less I really do.
Thanks,
-Ron|||The Program Name is being passed from the connection parameters I believe.
Example:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;User ID=;Initial Catalog=Idea;Data Source=TestSQL;Application
Name=My Application Name Here
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.