What is Secure Channel in Active Directory?

The word channel is easy to explain. Channel is a way of communicating with people or getting something done. Considering that communication can be a public process, a question will pop up that how can I secure my communication? That’s where the word secure comes into play. A combination of these two words will result in a concept which is absolutely crucial in Active Directory environment and that’s Secure Channel. The term “Secure Channel” can be defined as a way which authenticates the requestor and also provide confidentiality and integrity of data sent across the way.

In Windows Active Directory environments, secure channel provides an encrypted way of communication between clients and domain controllers. By clients I mean different editions of operating systems including client’s operating systems like Windows 7 or server operating systems which operate as Domain Controllers or member servers. You may ask me “You are keep saying that secure channel is important, but why?” To answer this question I would like to highlight the key role and responsibility of secure channel. In another word when there is no secure channel between a client and a domain controller there will be no completed Active Directory related tasks and as a matter of fact lack of secure channel existence or broken secure channel will fail everything related to domain. Group Policy and Computer authentication is case in point.

Basically there are three types of secure channels. The first one is for communication between clients in a domain and its represented domain controller. This type of secure channel is established between a client computer and a domain controller in a domain.

The second type of secure channel is responsible to establish a secure communication between domain controllers of a source domain and domain controllers of a trusted domain.

And the last one is responsible for establishing a secure path between domain controllers in the same domain.

Different credentials are used during establishing a secure channel for each type. It is a misunderstanding that many believe during the establishment of secure channel, user account is authenticated. The only account is used in this process is the computer account of the requestor. Since Active Directory has an automatic mechanism for computer accounts and their represented passwords I will cover what will happen in the background briefly.

Every computer account in Active Directory needs authentication and the very need for an authentication is a password. Once the computer is joined to a domain it will propose a password for its authentication in Active Directory. This mechanism is completely automated and Active Directory has no responsibility in this process. By default the machine account password change is initiated by computer itself every 30 days. However you can modify this value from Group Policy by navigating to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Maximum machine account password age and specify your value.It is worth mentioning that computer accounts passwords do not expire in Active Directory. They are exempted from domain password policy.

The service responsible for establishing secure channel is Netlogon. When the computer is started and as soon as the Netlogon service becomes available it will start to establish a secure channel between the computer and domain controller. There are three important parameters which Netlogon will use during this process:

  • ScavengeInterval: determines how often the NetLogon service checks the password expiration on secure channels. Default value is 15 minutes. For an overview of other responsibilities of this parameter you can refer to the Useful Links section.
  • MaximumPasswordAge: determines how often the system changes the computer account password of the local computer. Default value is 30 days.
  • DisablePasswordChange: You can prevent automatic password changes by setting the value of this entry to 1. Default value is 0.

If you need to change the above values, you can modify them using the methods below:

  • DisablePasswordChange


Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\Domain member: Disable machine account Password changes

  • ScavengeInterval


Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval

  • MaximumPasswordAge


Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\ Domain member: Maximum machine account Password age

Let’s get back to work! When the NetLogon service starts, the ScavengeInterval service checks if the password is not older that MaximumPasswordAge. Otherwise it attempts to change the computer password. After finding a domain controller, client and server will create a secure channel by exchanging and validating challenge and response. The process is as follows:

  • Client invokes the NetrServerReqChallanger() in order to request a challenge from the server. Also it sends a client challenge and computer name and domain controller name to the domain controller.

  • Domain controller receives the request from the client and replies with his server challenge with NetrServerReqChallanger() to the client.

  • At this point both client and domain controller generates a session key for secure channel.

  • The client invokes NetrServerAuthenticate3() and generate a client response and send it to the domain controller.

  • The server receives the client response and will decide whether secure channel can be established or not based on client response and session key provided by both sides.

If you are interested in the method used in generating session keys and detailed concept behind them you can refer to an excellent book written by Dobromir Todorov called Mechanics of User Identification and Authentication: Fundamentals of Identity Management.

What is a broken secure channel?

One of the most common problems indicating that you have a broken secure channel is the annoying “the trust relationship between this workstation and the primary domain failed” error. This error indicates that the machine is no longer able to establish a secure communication with a domain controller in its domain because the secret password which we talked about while ago is not set to the same value in domain controller. So as a result the authentication of computer account will fail due to this broken secure channel.

But why this happens? There are quite many reasons behind this behavior. One of them is resetting the computer account in ADUC. When you reset your account, actually you just initiate a password change request but it is not replicated to the domain controller. So that is why you will not be able to logon after you reset a computer account. Deploy predefined images to the computer accounts is another reason for this. I remember once I had a case when one of my clients told me “Every time I restore an image to one of my client they will no longer connect to domain”. I have seen many administrators who install operating system on a client and join it to the domain, and then they capture an image and save it for a rainy day. But what actually happens is they have to reinstall operating systems again due to broken secure channel because at the time when image was captured the secret hash was completely different. System time and DNS misconfigurations can lead to a broken secure channel as well.

How to fix the broken secure channel?

The the most user friendly solution in order to fix broken secure channel is to rejoin the computer into domain. It simply reestablishes the trust relationship to the domain. However it is a common solution for client computers, it is not practical when you face a broken secure channel between your CA server and domain due to impossibility of rejoining the certificate authority server. So in that case you have to choose another option.

Powershell v3.0 has a powerful cmdlet for automating this process with no need of rejoining the computer. You can run Reset-ComputerMachinePassword within a Powershell v3.0 console and have your secure channel fixed.

The last option you have for restoring a broken secure channel is to use the old powerful Netdom command. You can use this tool in order to change the computer password and as a result the password will be synced on client and domain controller and you will face no issues related to secure channel. The key point in this solution is to have Kerberos Key Distribution Center service set as Manual and Disabled. After that you must remove the Kerberos cache either using a simple reboot or KerbTray.exe tool which can be downloaded from the links section. Now you can reset the computer password using the command below:

netdom resetpwd /s:PDC Name /userd:Domain\User /password:Password

As an example the command will look like this:

netdom resetpwd /s:DC1 Name /userd:Contoso\administrator /password:P@ssw0rd

Reboot the machine and enable the KDC service and have your broken secure channel fixed.