Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

One of our customers has the following configuration:

  • On the domain controller, there's an SQL Server.
  • On his PC (WinXP), he logs on with LocalPC\LocalUser.
  • In Windows Explorer, he opens DomainController\SomeShare and authenticates as Domain\Administrator.
  • He starts our application, which opens a trusted connection (Windows authentication) to the SQL Server. It works. In SSMS, the connection shows up with the user Domain\Administrator.

Firstly, I was surprised that this even works. (My first suspicion was that there is a user with the same name and password in the domain, but there is no user LocalUser in the domain.)

Then we tried to reproduce the same behaviour on his new PC, but failed:

  • On his new PC (Win7), he logs on with OtherLocalPC\OtherLocalUser.
  • In Windows Explorer, he opens DomainController\SomeShare and authenticates as Domain\Administrator.
  • He starts our application, which opens a trusted connection (Windows authentication) to the SQL Server. It fails with the error message Login failed for user ''. The user is not associated with a trusted SQL Server connection.

Hence my question: Under which conditions can a non-domain user access a remote SQL Server using Windows Authentication with different credentials? Apparently, it's possible (it works on his old PC), but why? And how can I reproduce it?

share|improve this question
    
You may be able to troubleshoot this further with Kerbtray a tool in the Windows Resource Kit that allow you to see Kerberos tickets. The other two suggestions I have are: 1. it could be UAC on the Win7 PC getting involved, try disabling UAC. 2. Was the previous WinXP computer configured as trusted for delegation? Normally Windows logon on the domain would be required using 'Run As', however in this case there is an existing Kerberos ticket in play (because the connection it to the same server) it could be reused. –  Bernie White Oct 3 '12 at 10:03

1 Answer 1

As Bernie White mentioned, this is probably due to differences in kerberos configuration. KerbTray will work on WinXP, klist is built in on W7 and above.

Barring that, if the problem you are trying to solve is being able to the SQL servier using windows authentication, you can do so by running, runas /netonly /user:DOMAIN\Administrator application.exe.

The other method I use is to have the user dial-in via VPN, even if they are sitting on the internal network. Doing so causes the network credential to be used for all open applications and has the benefit of allowing SSO for Outlook, SQL Server, LDAP and any other application they can access.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.