What makes it possible to use a username for Windows authentication (stream) between two servers?

Question

Typical ISP setup. One server is a web server, the other is SQL SQL Server. There is a local administrator account, let XYZ be created on both machines. Therefore, when I log in remotely, I either WebServer \ XYZ or DBServer \ XYZ, depending on where I log in.

Now that I log in to SQL Server SSMS on DBServer using Windows Authentication and do "SELECT SUSER_NAME ()", I get DBServer \ XYZ. This makes sense as it picks up the fact that I logged in with these credentials.

Now let's move on to WebServer. I log in remotely as WebServer \ XYZ. I installed the client components of SQL there. When I start SSMS, select DBServer, log in using Windows Authentication and do "SELECT SUSER_NAME ()", I somehow get DBSERVER \ XYZ, instead of what I would suggest, it should be WebServer \ XYZ.

Somehow XYZ with WebServer becomes XYZ from DBServer. Why is this? How does this happen? Surely this cannot be simply because the names are the same?

I heard about trusted domains, but none of them is a domain controller, so I do not have access to this information. How can I tell if they trusted or not, without GUI tools?

The reason I ask this question is because I am trying to implement the same thing on my XP laptop (using Virtual PC), so I can simulate a production environment, but I'm out of luck.

Answer 1

The NTLM problem between machines is a little more complicated @Quassnoi points out, but it is similar. Machines can be in the same domain or trusted domains, but the accounts you use are accounts on local computers that focus only on controlling access to the local machine.

Local SAM accounts created as machine names \ userid are not distributed. When you try to authenticate external resources with this account, you will encounter a number of consistent backups:

• Skip the current token / username / password of the hash token - it will not succeed, the account will not be trusted
• Return - hash password return UserID + Password
• Return - Return to the connection as anonymous credentials.

Failures can also be disabled through configuration, very often to prevent anonymous authentication.

As @Quassnoi points out, in this case you managed to log in using reserve # 2.

To enable account credentials, you need the following:

• machines must be members of domains with at least one-way trust among themselves (they need not be members of the same domain).
• using domain accounts rather than accounts on the local computer will look something like this: domainname \ userid. A special case is the network service account, which has a proxy account in the domain script - domainname \ machinename $.

How do you know if your machine is a member of a domain? This is pretty easy if you have an interactive login. There are several strategies.

• interactively, the system control panel displays membership in a workgroup or domain. (Right-click properties on the computer in the Start menu)
• the IPCONFIG /ALL command line will also display the default DNS prefix, which usually matches your domain name.

I suspect your ISP will create a domain to simplify the management and monitoring of their computers. Whether they will allow you to create domain accounts is another matter.

Answer 2

Your XYZ accounts seem to have the same passwords on both machines, and they are not part of the domain.

WebServer sends only XYZ as a username and successfully responds to all password problems as the passwords match.

DbServer , of course, thinks of you as DbServer/XYZ , because he does not know others.

Likewise, when you try to access one stand-alone computer from another using SMB . If your usernames and password match, you succeed.