Hello everyone! Another episode of Detailed Concepts has been released. In today’s article we are going to cover what is secure channel and how does it work. Not only are we going to discuss what it is happening behind a secure channel, but also the required steps to troubleshoot a broken secure channel will be explained.

Table of Contents



Introduction

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 requester 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.


Different types of secure channel

Basically there are three types of secure channels. The first one is for communication between clients in a domain and domain controllers. 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.

How Secure Channel operates?

Different credentials are used during establishing a secure channel for each type. It is a misunderstanding, believed by many, that during the establishment of a secure channel, a user account is authenticated. The only account that is used in this process is the computer account of the requester. 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 this requires 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 
HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\Domain member: Disable machine account Password changes
  • ScavengeInterval
HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval
  • MaximumPasswordAge
HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
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 than 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 re-install 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 v4.0 has a powerful CMDLET for automating this process with no need of rejoining the computer. You can run Reset-ComputerMachinePassword within a Powershell v4.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 /userd:Contoso\administrator /password:P@ssw0rd
Reboot the machine and enable the KDC service and have your broken secure channel fixed.

Conclusion

This articled explained one of the most important concepts of Active Directory known as Secure Channel. Without secure channel most of the activities related to Active Directory will not be completed including replication and computer authentication. Although there are various reasons behind a problematic secure channel, we discussed two of the most important including system time and DNS misconfiguration. The process of troubleshooting a broken secure channel with different tools is explained in order to be an easy to use troubleshooting guide in such scenarios.

Links Section