3

I needed to create a test environment for one of our applications that uses SQL Server as its data store. Our sysadmin cloned the existing production server to create the test server.

I can connect to SQL Server on the test server using Windows Authentication, but not the production server (I can connect to production using a SQL login). I could connect to the production server using Windows Authentication before it was cloned.

Here is the error message:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

What can I do to connect using Windows Authentication again?

SQL Server 2008 R2 version: 10.50.2550.0

Some more info...

  • All of our servers are virtual (using VMware)
  • This same situation has happened with another production SQL Server. Again, we made a clone of production for a test environment. As with this case, I'm able to connect to that SQL Server using Windows Auth.

Sean brings up a good point about invalid SPNs, but what I don't understand is why SQL Auth. would work if it was cloned improperly?

Improve this question
5
  • 1
    Sounds like it was cloned improperly and now you are getting hit by invalid SPNs - most likely from having the server names be the same even if in DNS it is different. Check AD with your AD admin. I could be wrong, but that's where I'd start given the error.
    – Sean Gallardy
    Commented Sep 24, 2016 at 1:17
  • @SeanGallardy Thanks for the suggestion. I'll have to follow up on monday at work.
    – Jeff
    Commented Sep 24, 2016 at 1:45
  • 4
    Was the machine SID changed in the clone? If not, Active Directory will only allow the most recently booted machine to authenticate users.
    – Hannah Vernon ♦
    Commented Sep 24, 2016 at 13:55
  • Agree with Max. Cloning a server and not giving it a new SID will definitely cause it to conflict with the current PROD server. I would advise doing this sort of thing in an environment separate from production.
    – Sam Partridge
    Commented Sep 26, 2016 at 9:09
  • Nope...the SID was never changed. That has to be it. If someone wants to provide an answer I'll accept
    – Jeff
    Commented Sep 27, 2016 at 13:03

1 Answer 1

Reset to default
1

If the machine SID was not changed Active Directory will only allow the most recently booted machine to authenticate users.

Cloning a server and not giving it a new SID will definitely cause it to conflict with the current PROD server. I would advise doing this sort of thing in an environment separate from production.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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