Sooner or later, but administrators of a domain network based on Microsoft products have to deal with two similar errors: "Failed to establish a trust relationship between this workstation and main domain and "The Account Manager database on the server does not contain an entry to register the computer through a trust relationship with this workstation". In addition to these messages, there is also an inability to log into the computer under domain accounts.
We will analyze the causes of errors and methods for their treatment.
In domain Windows networks all computers and user accounts are assigned their own security identifiers (SIDs). In essence, we can say that each computer in the domain also has its own computer account. By analogy with a user account, such an account will also have a password. Given password is created and presented by the computer to the domain controller automatically. Thus, between the workstations and the domain controller, those trust relationships are formed, which are mentioned in the text of the errors.
Every 30 days, or when you turn it on for the first time after a long period of inactivity, the computer automatically changes its password. In theory, everything is beautiful, and the machine seems to be unable to make a mistake and “enter” the wrong password. However, sometimes this happens for several reasons.
Failed to establish a trust relationship between this workstation and the primary domain The most common cause is a rollback of the Windows operating system to an earlier state. Naturally, the earlier the restore point was created, the greater the likelihood of an error. In this case, after recovery, the computer will begin to show the old password to the domain controller, and the controller already contains a new one.
An error can also occur if there are two stations with the same names in the domain. This situation can arise, for example, if you give a new computer the name of a decommissioned machine, and then turn it on again. old computer forgot to rename it.
FROM possible reasons figured it out. Now about solving the problem. There are several ways, but all of them one way or another consist in reinstalling the computer account or resetting its password.
First way is to reinstall the account in .
After that, you need to go to the computer under local administrator and remove the workstation from the domain to working group(computer → properties → Extra options system → computer name → change).
The second way is to reset the password via . Let's make a reservation, however, that we need PowerShell version 3.0 and higher. We also go to the computer as a local administrator and enter the following cmdlet:
Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin
In this case, -Server is the domain controller name, and -Credential is the domain administrator account.
The cmdlet will not display any messages if it completes successfully. This method attractive in that a reboot is not required - just change the user and log into the machine under a domain account.
Third way resetting the computer password is to use the utility netdom, which has appeared in Microsoft server OS since Windows Server 2008. On client operating systems, it can be added using the RSAT package (Tools remote administration server).
As in the previous methods, this one is also performed from under the local administrator. Type in command line:
Netdom resetpwd /Server:DomainController /UserD:Admin /PasswordD:Password /SecurePasswordPromptThe principle is similar to what we saw in the PowerShell example. /Server is the domain controller, /UserD is the domain administrator account, /PasswordD is the password for the domain administrator account. You can also use the /SecurePasswordPrompt option to hide the password behind asterisks. A reboot is also not required.
Method four and the last one in our article is to use the utility Nltest, which is available by default on any workstation.
Let's run the utility on the command line and first check a secure connection to the domain:
Nltest /queryThen let's reset account computer in the domain:
Nltest /sc_reset:DomainAnd finally, reset the computer password:
nltest /sc_change_pwd:DomainUnfortunately, such great utility has its downsides. First of all, the utility does not ask for the login/password of the domain administrator and, accordingly, is executed under the user who launched it, which can lead to an access error.
There is another error related to trust relationships within a domain, which was placed at the beginning of this article. It looks like this:
In this case, the utility will again help us Nltest. Checking the secure connection to the domain again:
Nltest /queryIf an error message appears, then to fix the error, it is enough to install this patch. If the connection status is NERR_Success, then do the following:
netdom reset /d:Domain ComputerName netdom reset /d:Domain ComputerName /server:DomainController /uo:Admin /po:PasswordIn the second case, we explicitly specify the domain controller with which we want to establish a trust relationship.
The utility will please us with a message that the secure channel has been reset and a new connection has been established.
So, here are some ways to restore trust in a domain. I hope that you will have to use them as little as possible. 🙂
This topic arose due to the fact that the user edgi asked a question about creating a transitive relationship between two forests and provided another link from the forum http://sysadmins.ru/topic178164.html where users argue about the fact that it is impossible to establish a trust relationship between two forests, since supposedly a third forest is needed to ensure transitivity, and so on ....I want to say right away that in order to be aware of transitive trust relationships, we do not necessarily need a third party to provide trust transitive relationships.
But let's look at the process of establishing trust relationships between forests.
Note: Do not forget that the first created domain is and root domain and wood and forest. That is, the first created domain in our network by default should be considered both as a root domain, and as a forest, and as a tree (three in one glass ... sorry bottle)
For simplicity, we will place these root domains on the same network, since if they were located on different networks, we would need (and do so if necessary) so that these domains (or rather, the DNS of these domains, and hence, naturally, domain controllers ) saw each other in some way. If the DNS servers are located in different networks, you need to take care of how to somehow make these networks see each other (how to do this is a separate conversation and for now we will not consider it here).
Why is it so important that the DNS services of these domains see each other? But because at the heart of Windows Server, finding (recognizing) domain controllers occurs using the DNS service. That is, if the DNS service in any domain is configured incorrectly, then finding this domain controller or domain controllers (if there are many) will be impossible. That is, if you simply say - domain controllers see each other using the DNS service . I think later I will describe the process of finding domain controllers in a separate article, but for now just remember that domain controllers are "blind" (do not see anything on the network) without a properly configured DNS service.
As mentioned already, trust relationships act as a connecting link between forests, trees, domains. The snap-in is used to administer trust relationships. Active Directory- domains and trust, see figure 1.
Picture 1.
But before creating a trusting relationship, let's describe what we have. So we have two root domains and, accordingly, forests and trees, namely rk.com and xu.com, let's assume that they belong to the same company and are located on the same network. The IP address of the first domain controller with the integrated DNS service installed with Active Directory (who does not remember what it is, see here) will be 192.168.0.1 (rk.com), and the second forest root domain 192.168.0.5 (xu.com). That is, the DNS service is installed on both the first and second domain controllers. (How to install and configure DNS can be found on the site in other articles)
The first thing we need to make sure before we start creating trust relationships is that the root domains in both forests can see each other through DNS. To do this, we will use the well-known nslookup utility from the rk.com forest root domain and see what it gives us. See figure 2.
Figure 2.
In Figure 2 (damn... you probably need to write not a picture, but a figure, but forgive me generously...) you can see that we typed the nslookup command on the command line with the xu.com parameter (neighboring forest) and it gave it to us, which, in principle indicates that the DNS service is running and the DNS services see each other. The same can be done from the xu.com root domain, see Figure 3.
Figure 3
In order to set up forwarding, we go into the DNS snap-in of the domain controller that is located on the computer under the name server1, we become on it, right click mice open context menu, select properties in the context menu and click on it. The window shown in Figure 4 opens and select the "Forwarding" tab.
Figure 4
On this tab, click the "Create" button and write the domain name where we want to forward. In our case, this is the xu.com forest root domain. Right there on the tab, just below in the field "List of IP forwarders for the selected domain" - add its IP address. In our example, this is 192.168.0.5.
The same can be done on the xu.com domain controller server... the process is absolutely the same, only you need to write a different domain and a different address. In our case, this is the rk.com domain and its IP is 192.168.0.1.
So, after we figured out the DNS servers and made sure that they see each other, we move on to creating trust relationships and go to the "Domains and trust" snap-in shown in Figure 1.
Further, if we want these two forests (rk.com and xu.com) to be connected to each other through transitive trust relationships, then we need to set the forest functioning mode to the "Windows Server 2003" level (for forest and domain functioning modes see here ). Therefore, in the "Domains and Trusts" snap-in, we stand on the top inscription "Active Directory - Domains and Trusts" and open the context menu with the right button, see Figure 5.
Figure 5
In the context menu, select " Changing the Forest Operation Mode..." and click on it. A window will open with possible forest operation modes. Select the operation mode "Windows Server 2003". transfer from this mode of operation to lower modes of forest operation is impossible, see Figure 6. That is, when choosing a mode of forest operation, think carefully, since it is simply impossible to transfer to another mode of forest operation....
Figure 6
After we increased the mode of operation of the forest to the maximum possible, namely to"Windows Server 2003", for educational purposes, we will also increase the domain operation mode to the levelWindows Server 2003. To do this, we become the root domain and open the context menu, see Figure 7.
Figure 7
The same operations, that is, we raise the level of the forest and domain on the xu.com root domain controller.
When we made sure that our forests (rk.com and xu.com) and domains are working in functional mode"Windows Server 2003", let's start creating transitive forest trusts.
Attention! If at least one of the domain forests is at the functional level"Windows 2000", then domain forests can only be joined by external trusts.
In the "Domains and Trusts" snap-in, we become the name of the root domain, in our case it is rk.com and open the context menu with the right mouse button. The window shown in Figure 8 will open. Go to the "Trust" tab.
Figure 8
On this tab, click the "Create Trust" button. After clicking on this key, the "Wizard for creating trust relationships" opens, see Figure 9.
Figure 9
Figure 10.
In the "Name" field, we write the name of the domain with which we want to create a trust relationship, in our example, this is the root domain of the xu.com forest .... We press the keyboard not - Next ....
A window opens with suggestions for choosing the type of trust, see Figure 11.
Hello Dear readers of Habrahabr! In the Internet, each of us can find many separate articles about the failure of computer authentication through a domain controller, to be more precise, a computer connected to a domain loses contact with it.
So, let's start studying this problem.
Many IT engineers who work in companies large and small have computers with operating system Windows 7, 8.1 etc. and all of these computers are connected to a domain network (DC).
This problem occurs because the Kerberos network protocol cannot synchronize and authenticate with the computer (The trust relationship between this workstation and the primary domain failed) that is joined to a domain. Then we can see such an error (see photo below).
After which we are looking for third party program, download it, create bootable flash drive and the local admin, then we log in through it and exit the domain, add the computer to the Workgroup, and then reconnect this computer to the domain.
Using Windows Batch scripting I want to create a bat file and automate the process of creating and adding a local admin. The only thing we will need is after creating given file run it.
We open our text editor, enter the command shown below.
Net user admin Ww123456 /add /active:yes WMIC USERACCOUNT WHERE "Name="admin"" SET PasswordExpires=FALSE net localgroup Administrators admin /add net localgroup Users admin /delete netsh advfirewall set allprofiles state off
Let's go through all the commands point by point to eliminate unclear points.
Net user admin (instead of the word admin, you can add any name that suits you, the default is administrator, in my case it is admin).
Next, we see the password that I put there Ww123456 (you can put any password you remember).
After we see /add /active:yes - add and activate: YES
WMIC USERACCOUNT WHERE "Name="admin"" SET PasswordExpires=FALSE - this command means that the admin who is being added had permanent password no expiration date (see picture below).
The third and fourth points are interconnected by the fact that by default, when a local admin is created, the Member Of item is Users (see photo). We do not need it (Users), because we are creating a full administrator for our OS. Therefore, the fourth command - net localgroup Users admin /delete - deletes Users, and the previous command - net localgroup Administrators admin /add - adds an administrator (see photo).
The last command, netsh advfirewall set allprofiles state off, disables the Windows firewall.
Sometimes, in order to install any program or give any command in Windows-e, you need to turn off the firewall (After running the script, you can enter the command - netsh advfirewall set allprofiles state on and turn it on again. I have off by default, since I am using a third party firewall. This moment at the discretion of each individual).
Next, go to our notebook, click File, save as ... (save as ...) enter the name of our script (in my case: localadmin). Then put a dot (.) and write the format of the bat script. Choose where to save this entry and click save. Shown in more detail in the picture.
It turns out here is such a script (see photo).
This script must be opened as an administrator at startup:
Press the right mouse button and Run as administrator (see photo).
After running the script, you should see such a window (see photo).
If for some reason an error occurs, then in 90% of such cases this is due to the fact that your image from which you installed Windows is unlicensed, some kind of repack, etc. Download and use licensed and proven software.
After successfully adding a local admin, you can run this script on all workstations in your office that have Windows installed.
If you ever get this error: The trust relationship between this workstation and the primary domain failed- You will only need to do switch user and write where the login is.\admin (remember! A dot is put in the beginning before the slash!), further down enter the password you added to your script (in my case: Ww123456). After that, you go to the working OS.
It remains to remove our computer from the domain and add it to the Workgroup. Instead of Workgroup, enter any letter (see photo).
Next, the domain administrator password is entered and the computer asks us to restart.
After the reboot, we go again under our local admin and then we add the computer to our domain. The system once again requires a reboot and Voila! Our User can again connect to the domain without any problems!
P.S. This system works also for Windows server part, however if you write such a script for servers after disabling the firewall, you will need to enable it again (before - netsh advfirewall set allprofiles state off, after netsh advfirewall set allprofiles state on).
Thank you for attention!
Everyone has to deal with the error "Failed to establish a trust relationship between this workstation and the main domain" from time to time. system administrator. But not everyone understands the causes and mechanisms of the processes leading to its occurrence. Because without understanding the meaning of ongoing events, meaningful administration is impossible, which is replaced by thoughtless execution of instructions.
Computer accounts, like user accounts, are members of a domain's security. Each security principal is automatically assigned a security identifier (SID) at the level at which domain resources are accessed.
Before you grant an account access to a domain, you must verify its authenticity. Each security principal must have its own account and password, and the computer account is no exception. When a computer is joined to Active Directory, a computer account of type "Computer" is created for it and a password is set. Trust at this level is ensured by the fact that this operation is performed by a domain administrator or another user who has explicit authority to do so.
Subsequently, each time the computer logs on to the domain, it establishes a secure channel with the domain controller and tells it its credentials. Thus, a trust relationship is established between the computer and the domain, and further interaction occurs in accordance with the security policies and access rights set by the administrator.
The computer account password is valid for 30 days and is automatically changed thereafter. It is important to understand that the password change is initiated by the computer. This is similar to the process of changing a user's password. Having discovered that Current Password expired, the computer will replace it the next time it joins the domain. Therefore, even if you have not turned on your computer for several months, the trust relationship in the domain will remain, and the password will be changed at the first login after a long break.
The trust relationship is broken if a computer attempts to authenticate to a domain with an invalid password. How can this happen? The easiest way is to roll back the state of the computer, for example, with a standard system restore utility. The same effect can be achieved when restoring from an image, snapshot (for virtual machines) etc.
Another option is to change the account by another computer with the same name. The situation is quite rare, but sometimes it happens, for example, when an employee's PC was changed while keeping the name, removing the old one from the domain, and then re-entering it into the domain, forgetting to rename it. In this case, the old PC, when re-entering the domain, will change the computer account password and the new PC will no longer be able to log in, since it will not be able to establish a trust relationship.
What action should be taken when faced with this error? First of all, establish the cause of the breach of trust. If it was a rollback, then by whom, when and how it was made, if the password was changed by another computer, then again we need to find out when and under what circumstances this happened.
A simple example: an old computer was renamed and given to another department, after which it crashed and automatically rolled back to the latest checkpoint. After that, this PC will try to authenticate in the domain under the old name and will naturally receive an error establishing trust relationships. The correct action in this case would be to rename the computer as it should be called, create a new checkpoint and delete the old ones.
And only after making sure that the violation of trust was caused by objectively necessary actions and it is for this computer that you can begin to restore trust. This can be done in several ways.
Active Directory Users and Computers
This is the easiest, but not the fastest and most convenient way. Open snap-in on any domain controller Active Directory Users and Computers, find the required computer account and, by right-clicking, select Reinstall account.
Then we log in on the computer that has lost trust under local administrator and remove the machine from the domain.
Then we enter it back, you can skip the reboot between these two actions. After re-entering the domain, we reboot and log in under the domain account. The computer password will be changed when the computer is rejoined to the domain.
The disadvantage of this method is that the machine must be removed from the domain, as well as the need for two (one) reboots.
Netdom utility
This utility is included with Windows Server since edition 2008, it can be installed on user PCs from the RSAT (Remote Server Administration Tools) package. To use it, log in to the target system local administrator and run the command:
Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password
Let's look at the command options:
- server- name of any domain controller
- UserD- domain administrator account name
- PasswordD- domain administrator password
After the successful execution of the command, a reboot is not required, just log out of the local account and log in to the domain account.
PowerShell 3.0 cmdlet
Unlike the Netdom utility, PowerShell 3.0 is included with the system starting with Windows 8 / Server 2012, for older systems it can be installed manually, Windows 7, Server 2008 and Server 2008 R2 are supported. Required as a dependency net framework not lower than 4.0.
In the same way, log on to the system for which you want to restore trust as a local administrator, start the PowerShell console, and run the command:
Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin
- server- the name of any domain controller
- Credential- domain name / domain administrator account
When this command is executed, an authorization window will appear in which you will have to enter the password for the domain administrator account you specified.
The cmdlet doesn't display any messages on success, so just change your account, no reboot required.
As you can see, restoring trust in a domain is quite simple, the main thing is to correctly determine the cause of this problem, since different methods will be required in different cases. Therefore, we do not get tired of repeating: if any problem occurs, you first need to identify the cause, and only then take measures to correct it, instead of mindlessly repeating the first instruction found on the network.