Troubleshooting server SIDS causes virtual machines not to join AD Domain users and cannot log on remotely

Recently set up the AD domain controller in the company, found unable to really add domain users on the computer, that is, the added users can log on locally, but cannot telnet, try a variety of methods can not be resolved, and ultimately because the virtual machine caused the server SID conflict. This article records the cause of the problem and the resolution process.

Add a domain account

Add a user to the domain user, such as:

(Fig. 1)

Add the user to the development group, and then have the user telnet to another server:

(Fig. 2)

Unable to log in, even using a domain administrator, and cannot log in, it seems necessary to go to the remote server to add a domain user to the local user group above:

(Fig. 3)

Select the Administrators group, click the Add button, select a domain user, and then add, preferably OK.
Logged in with this domain user, the result is the previous interface and cannot be logged on.
Go back to the remote server again, open the Administrators group and discover that the domain user you added previously was not added.
Repeat the above operation, the problem remains, and the domain user cannot be added to any local user group.

Go to the group inside Consulting about Daniel, gave a variety of links, some people say is a local security policy issues, some say is firewall settings, also some people say is domain controller setup problem.
The problem is that you join the previous domain user to the Active Domains Admins group and then log on to the remote server.

(Fig. 4)

Sid conflict

Finally, find the original company's OPS colleague consultation, he told me, may be a SID conflict, because the above picture in the domain user name after a string of strings:

s-1-5-21-2625116194-3287851518-1169719709-500

At the command line, enter the following command:

C:\users\administrator>whoami/user User Information----------------user name            sid================= ========================= ====================dxn\administrator s-1-5-21-2625116194-3287851518-1169719709-500

On the domain controller server, also enter the above command, and the SID value shown is exactly the same as the remote server.
It seems that the questions the colleague has said are true.

So, what is SID?

Search the next, find the following explanation:

SIDs are just abbreviations for security identifiers. The full name of the SID is "Security Identify", which is the unique ID string assigned to each account created on the domain or local computer (for example, s-1-5-21-1454471165-1004336348-1606980848-5555).

There is also a unique identifier for each object in Active Directory domain, which becomes a GUID. Guid=sid + RID. The Active Directory has a single operations master role called RID, which is to assign a RID number to each object in the domain. The final GUID is unique across all domains, and even around the world.
In fact, computers use SIDs to track each account: If you rename the Administrator account, the computer still knows which account is the Administrator account. This is because the SID differs from the name, and it never changes.

Computer accounts are associated with some computer hardware information for a higher level of security requirements. Because the Active Directory database no longer trusts the computer account, the computer account is considered unsafe, and the so-called secure channels security channel is compromised.

This is why the user who added the domain to the remote server earlier was unsuccessful.

Configuring SIDs

What is the reason for Sid duplication?

This is often the reason that the system is installed by cloning or replicating virtual machines, which, despite the rapid installation of the deployment system, is causing the problem today. The workaround is to reconfigure the system to generate a new SID. You can use the following command:

c:\users\administrator>CDc: \ >dir c:\windows\system32\sysprep the volume in drive C is not labeled. The serial number of the volume is b0d1-4221 c:\windows\system32\sysprep directory 2010/11/22  02:52    <DIR>          . 2010/11/22  02:52    <DIR>           . 2010/11/22  02:52    <DIR>          en-US2015/12/17  12:23    <DIR>           Panther2009/07/14  09:39           128,512 sysprep.exe2010/11/22  02:52    <DIR>          zh-CN               1 files        128,512 bytes                5 directories 91,940,900,864 Available Bytes C:\Windows\System32 \sysprep\sysprep.exe

Then, the following configuration program interface appears:

(Fig. 5)

After running the Sysprep.exe program, the system parameters are all reset, including the IP configuration information, after the system restarts, the server's IP will become automatically acquired, and the server's name has also been modified, so if you can not operate the server in the field, or you do not have the administrator rights of the virtual machine, do not run Sysprep . exe program.

(Fig. 6)

After a long configuration, re-enter the system, join the current server to the domain, and then configure the domain user logon rights, which is above (Figure 3), does not follow the domain user name followed by a long list of Sid characters. After this configuration, the domain user can finally telnet to the server.

Finally, thank you for your support after reading this article (Data development tool-SOD Open Source framework http://pwmis.codeplex.com).

Troubleshooting server SIDS causes virtual machines not to join AD Domain users and cannot log on remotely