Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

I work for a small company, owned by a bigger one. I have a user in my parent company's domain - DomainA\MyUser.

Now we have bought our own server and want our own domain. I have created a user in the new domain, with the same name as the old one - DomainB\MyUser. This user is network administrator in DomainB.

My computer is still in DomainA. When I log in there as DomainA\MyUser, I get all permissions of DomainB\MyUser on the new server (which is domain controller of DomainB and not connected to DomainA).

This even if I set DomainB\MyUser as inactive.

How is this possible??

[EDIT 2010-07-06]

Doesn't work with disabled user in DomainB. Last when I tried I forgot to kill all sessions for the user.

Screenshots when I use remote desktop:

http://www.enalog.se/files/index.html

(NEMOQ_AD is the old domain. ENALOG is the new domain. VOLDEMORT is domain controller of ENALOG. Peter is the user)

[EDIT 2010-07-08]

When I type the user as MyUser@DomainA, I cannot log in. Why does it work with DomainA\MyUser?

share|improve this question

4 Answers

up vote 3 down vote accepted

Every login in your screenshots is the user ENALOG\Peter, not NEMOQ_AD\Peter. It doesn't matter that you're typing the domain NEMOQ_AD\Peter, since NEMOQ_AD is not a domain that ENALOG trusts. Notice that you don't see "NAMOQ_AD" anywhere once you've connected to Voldemort.

NTLM supports something called pass-through authentication. The important bit of the article is here:

If the domain name specified is not trusted by the domain, the authentication request is processed on the computer being connected to as if the domain name specified were that domain name. NetLogon does not differentiate between a nonexistent domain, an untrusted domain, and an incorrectly typed domain name.

What is happening is the following:

  1. Voldemort receives a request to authenticate the user NEMOQ_AD\Peter.
  2. Voldemort sees that NEMOQ_AD is neither its own domain nor any domain that it trusts.
  3. Voldemort tries to authenticate the user ENALOG\Peter instead.
  4. Since you entered the password for ENALOG\Peter (as you said in another comment), authentication succeeds.

When you are accessing the drive share, you have to be using NTLM (any attempt to use Kerberos will fail because ENALOG doesn't trust NAMOQ_AD) using pass-through authentication, which allows you to access network shares without typing a password. This works only when you are using identically-named accounts with an identical passwords on the two machines.

When you enter a password when using Remote Desktop, it's behaving exactly as if you had tried to log in as ENALOG\Peter instead of NEMOQ_AD\Peter, and using whatever password you typed in. This way, if you type "Peter" as your username, the local computer sends "NEMOQ_AD\Peter" since that's the only domain it knows about, but the remote computer decides to try "ENALOG\Peter" instead.

I assume SQL Server Management Studio is using one strategy or the other (probably the second one), I don't know exact details of its implementation and don't have two domains lying around to test it.

share|improve this answer
So... "I don't know who you are. I don't trust you. I guess you are this one instead. Now I trust you." I'm not experienced in servers, but to me that's a very strange behavior and a security risk. Anyhow, at least this tells me why it behaves this way and if I use different passwords it shouldn't be any problems. – Palpie Jul 8 '10 at 9:25
Pass-through authentication is the equivalent of sending over the password to the remote machine (without actually having to do so), so really you are supplying Voldemort with the password for ENALOG\Peter, and you just happened to have typed it a few minutes earlier while you were logging in as NEMOQ_AD\Peter. NTLM assumes that if it can prove you have the same password on two identically-named accounts, then it's probably OK to go ahead and not make you explicitly type credentials again. So, it's more like spell-check for your username. – Stephen Jennings Jul 9 '10 at 3:28
It's not a security risk because you DO know the password for the remote computer. The only time this would be the "wrong" thing to do would be if the accounts ENALOG\Peter and NEMOQ_AD\Peter represented different people who just happen to have identical passwords. Not very likely in the grand scheme of things. – Stephen Jennings Jul 9 '10 at 3:30
up vote 0 down vote

That's not possible. Something is misconfigured.

share|improve this answer
I haven't done any configuration except adding an administrator and a couple of normal users in DomainB. – Palpie Jul 6 '10 at 5:41
Where can I configure this? – Palpie Jul 6 '10 at 6:08
Does a trust exist between NEMOQ_AD and ENALOG? Are the passwords for NEMOQ_AD\peter and ENALOG\peter identical? Are there any warnings or errors thrown in the application, system, or security event logs on the ENALOG domain controller at the time of authentication? – Stemen Jul 7 '10 at 3:17
No trust is configured. No warnings or errors. I've played some more with the passwords: Remote desktop doesn't seem to care about the domain. I can log in with NEMOQ_AD\Peter and the password of ENALOG\Peter. With UNC I cannot go to the server's folders at all if the passwords are different (only works if I log in as ENALOG\Peter, as it should be). When the passwords are identical NEMOQ_AD\Peter behaves just like ENALOG\Peter. – Palpie Jul 8 '10 at 6:59
In that case, I don't see any problems here; authentication is working as designed. If NEMOQ_AD\Peter and ENALOG\Peter should not have access to each other's resources, then either 1) their passwords need to be different, or 2) a trust needs to be created between domains. – Stemen Jul 8 '10 at 17:56
show 1 more comment
up vote 0 down vote

Can you be more specific? What do you mean you get the same permissions? Are you referring to file and folder permissions? What do you mean you set the userB account as inactive? There's no such thing as "inactive". Do you mean that you set the userB account to disabled?

share|improve this answer
Yes, I mean disabled (language issue :)). When I sit at the computer in DomainA with DomainA\MyUser, I have for example full rights in \\ServerB\c$. I have also made DomainB\MyUser a sysadmin in a MS SQL Server which also applies to DomainA\MyUser. – Palpie Jul 6 '10 at 5:46
DomainA\MyUser can also use remote desktop to connect to the new server and then gets same rights on the server as DomainB\MyUser. – Palpie Jul 6 '10 at 6:01
up vote 0 down vote

Stephen Jennings already answered it thoroughly but I'm just thinking, out of curiosity alone, what's the reason for the separate domain in this case?

There are many good reasons but generally maintaining multiple domains is a hassle and it doesn't sound like anyone will be able to manage it and instead just create the typical overhead associated with sustaining multiple domains for a group of people.

Why not incorporate the new server in the existing domain, using configuration to limit its resources to your company. Do you need to access resources at the parent company? Are the parent company administrators not trusted?

share|improve this answer
No, they are not trusted. The domains must be separate. Having two separate domains I think should be easier than not to separate them. – Palpie Jul 8 '10 at 9:18

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.