Re: Windows authentication in domain

From: Dave Busch (DaveBusch_at_discussions.microsoft.com)
Date: 08/17/04 

Date: Mon, 16 Aug 2004 15:19:02 -0700

Hi Steve

The way I understand the Integrated Security setting on a connection string,
setting it to true or SSPI will cause SQL to use the credentials of the
current user. My question really is why doesn't SQL attempt to use credman
credentials if the current user's credentials fail?

Using credman credentials works for example if you log off the workstation
and log in as Administrator to the local machine account. If the credentials
for the local account on the SQL box are cached using credman, SQL will
indeed attempt to use those credentials and the connection can be made.

SQL seems to be saying in the case where the domain user is logged in, "OK I
know your identity, and you don't have rights". Why doesn't it behave that
way when the current user is <local machine>\Administrator?

"Steve Thompson" wrote:

> "Dave Busch" <Dave Busch@discussions.microsoft.com> wrote in message
> news:81C5E126-190A-4634-807F-455941781161@microsoft.com...
> > In a domain, where a user is logged in as Foo@SomeDomain.com, an attempt
> is
> > made to connect to a SQL server on the domain using integrated security
> using
> > the connection string:
> >
> > Initial Catalog=Northwind;Data Source=SomeServer;Integrated Security=SSPI
> >
> > User "Foo" is not registered as a valid SQL login on "SomeServer", so the
> > connection fails. So far so good.
> >
> > Now, let's say a local user is added to SomeServer called "SomeLocalUser",
> > and this windows account is added to the SQL Server as a valid login.
> Back
> > at the workstation where Foo@SomeDomain.com is logged in, the credentials
> are
> > added to that workstation for SomeServer\SomeLocalUser. When the
> connection
> > is attempted, it fails indicating that Foo@SomeDomain.com is not a valid
> user.
> >
> > I guess I would have expected SQL to attempt all credentials found on the
> > workstation rather than just the user who is currently logged in. What is
> > the expected behavior? Is there some way I can force SQL to use alternate
> > credentials manually?
> >
>
> I'm not sure I completely understand your example. If you are using SSPI,
> then only the credentials of the user making the connection to SQL Server
> will be used, none other... The only other alternate way (I can think of) is
> to use the RunAs to start the application under another user security
> context.
>
> Steve
>
>
>

Relevant Pages

  • Re: Cached Logon
    ... Your browser is caching the credentials, ... be accessed (it's just the ASP page -> SQL Server that doesn't work, ... are you using a common connection string across all three pages (eg is ...
    (microsoft.public.windows.server.general)
  • Re: Cached Logon
    ... Your browser is caching the credentials, ... be accessed (it's just the ASP page -> SQL Server that doesn't work, ... are you using a common connection string across all three pages (eg is ...
    (microsoft.public.sqlserver.connect)
  • Re: Cached Logon
    ... Your browser is caching the credentials, ... be accessed (it's just the ASP page -> SQL Server that doesn't work, ... are you using a common connection string across all three pages (eg is ...
    (microsoft.public.sqlserver.server)
  • Re: Cached Logon
    ... Your browser is caching the credentials, ... be accessed (it's just the ASP page -> SQL Server that doesn't work, ... are you using a common connection string across all three pages (eg is ...
    (microsoft.public.win2000.networking)
  • Re: Cached Logon
    ... Your browser is caching the credentials, ... be accessed (it's just the ASP page -> SQL Server that doesn't work, ... are you using a common connection string across all three pages (eg is ...
    (microsoft.public.inetserver.iis)