Hey all! Rob Greene here. We see cases around Network Device Enrollment Service (NDES) failing to successfully complete.
Please keep in mind that you can get these error messages outside of NDES installation, however we are not going to be covering those errors within this blog. This blog is going to concentrate on the assumption that everything is working fine in general with regards to issuing certificates within the environment, but the NDES configuration wizard is failing.
The most often encountered errors by customers are:
The first error message is the dreaded Access Denied error message while running through the wizard like the one below.
Or if looking at the deployment operational logs:
Event Viewer\Application and Services Logs\Microsoft\Windows\CertificateServices-Deployment\Operational
Log Name: Microsoft-Windows-CertificateServices-Deployment/Operational
Source: Microsoft-Windows-CertificateServices-Deployment
Date: [Date/Time]
Event ID: 104
Level: Error
User: [DOMAIN\USER]
Computer: [NDES Computer Name]
Description:
System.Exception:
System.Exception: CMSCEPSetup::InitializeDefaults: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.PowerShellCommandExecutor.Execute(Command command, IPowerShellEngine powerShellEngine, IRehydrator rehydrator)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.PowerShellExecutablePR`2.ExecuteCommand(CommandParameter[] parameters)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.NDES.Operations.Initialize.Execute(PostConfigurationTaskData taskData)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.AsyncOperationP`1.DoWork(Object sender, DoWorkEventArgs eventArgs)
There are several tasks that are happening when going through the configuration wizard, and most of these tasks require an elevated account. Due to this account elevation requirement, if Access Denied is being seen during the configuration, it will mean that the account running the wizard does not have the required permissions.
Here is the list of tasks that are done:
Use the CertTmpl.msc console while logged in as the account used to run the NDES configuration wizard to try and set Enroll permissions on the template. Was it able to successfully set permissions on this Template?
Use the CertSrv.msc console on the CA computer while logged in as the account used to run the NDES configuration wizard and try and add these templates to the CA. Was it able to successfully add the templates to the CA?
From the NDES Server, use Services.msc console and try and restart the AD CS service while logged in as the account used to run the NDES configuration wizard. Was it able to stop and start the AD CS Service?
If any of these tasks fail, you will see the error message of Access Denied. So, the first thing to check is to ensure that the account used to run the NDES configuration wizard can do each of these tasks independently of the wizard.
Endpoint Mapper – The endpoint mapper listens on port TCP 135. The point of the endpoint mapper is to have a database of each RPC based application (via UUID) and then know what high / ephemeral port the RPC application is listening on.
RPC application / DCOM application - When a DCOM or RPC based application starts up, it finds an available high port (also known as an ) typically in the range of 49152 – 65535. Once it finds a port it then registers its RPC application (also known as a UUID) with the RPC Endpoint Mapper and its UUID.
When an RPC / DCOM based client application wants to connect to the RPC/DCOM application it first contacts the RPC Endpoint Mapper and asks to be given the port number for the RPC/DCOM application via the UUID information. The endpoint mapper looks this information up and then returns the high port that the RPC / DCOM application gave it. Then the RPC / DCOM client application attempts to connect to the high port given to it by the RPC endpoint mapper.
For more information on RPC and how it works see this:
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/rpc-errors-troubleshooting
When not an Access Denied, this is the other most often seen error, when running the configuration wizard.
The RPC Server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE) dialog box.
The event log entry for this is going to look something like the below:
Log Name: Microsoft-Windows-CertificateServices-Deployment/Operational
Source: Microsoft-Windows-CertificateServices-Deployment
Date: [Date/Time]
Event ID: 104
Level: Error
User: [DOMAIN\USER]
Computer: [NDES Computer Name]
Description:
Microsoft.CertificateServices.Deployment.Common.NDES.NetworkDeviceEnrollmentServiceSetupException:
Microsoft.CertificateServices.Deployment.Common.NDES.NetworkDeviceEnrollmentServiceSetupException: The Network Device Enrollment Service setup failed because certification authority (CA) "[CA COMPUTERNAME]\CA NAME" could not be contacted. Make sure that the CA is properly configured and available. The error is: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.PowerShellCommandExecutor.Execute(Command command, IPowerShellEngine powerShellEngine, IRehydrator rehydrator)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.NDES.NDESPSHProviderContext.Validate()
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.Provider.NDES.Operations.SetCAConfiguration.Execute(CAConfigurationParameters caInformationParameter)
at Microsoft.CertificateServices.ServerManager.DeploymentPlugIn.DeploymentWizard.Common.ViewModels.CAConfigurationViewModel.Validate()
This type of error will come from a few different scenarios.
Run the following command from the NDES Server and target the Certification Authority that is the specific CA the NDES server will be a proxy for. If you get back Access Denied, then you will have problems with DCOM permissions.
CA Computer Name of: fab-rt-rootca01.fabrikam.com
CA Name of: Fabrikam Root CA1 G2
CertUtil -Config "fab-rt-rootca01.fabrikam.com\Fabrikam Root CA1 G2" -ping
See the following KB: KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)
https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-...
This could be from the DCOM Hardening setting being mismatched between the NDES Server and the Certification Authority.
A Firewall (hardware based or software based) is preventing RPC / DCOM communications between the NDES Server and the server running the Certification Authority Service. To see if this is an issue you can run the following CertUtil.exe command.
CA Computer Name of: fab-rt-rootca01.fabrikam.com
CA Name of: Fabrikam Root CA1 G2
CertUtil -Config "fab-rt-rootca01.fabrikam.com\Fabrikam Root CA1 G2" -ping
When things are correct you should see output like this:
Connecting to fab-rt-rootca01.fabrikam.com\Fabrikam Root CA1 G2 ...
Server "Fabrikam Root CA1 G2" ICertRequest2 interface is alive (437ms)
CertUtil: -ping command completed successfully.
If this fails with “The RPC Server is unavailable (0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE))”, then connectivity from the NDES Server to the Certification Authority needs to be investigated.
While running the above CertUtil command get double-sided network traces. Double-sided network traces means you will run a network tracing tool on the NDES Server and the Certification Authority at the same time. Look in the resultant traces and see if the required ports are leaving the NDES Server and successfully getting to the Certification Authority server.
As stated earlier, the NDES configuration wizard needs to be able to successfully stop and start the AD CS Service on the Certification Authority server. If you can stop and start the service, you can still fail to configure NDES, if the AD CS Service cannot be stopped and started within a 30-second window.
NDES stops and starts the service via the Service Control Manager (SCM) APIs. If you have ever attempted to stop/start a service and noticed it does not stop/start quickly, you might see a message stating that Service Control Manager cannot tell you if it the service was successfully stopped / started, as it did not report back in a timely fashion. Well, SCM will only wait 30 seconds for the service to return the status of the stop/start command it sent to it. SCM stops worrying about the service when it takes longer than 30 seconds.
NDES first sends the stop command to SCM for AD CS, then uses SCM to find out when the service is successfully stopped. the start command to SCM for AD CS and again uses SCM to find out when the service is successfully started.
We typically see this fail in the following two scenarios:
Depending on how long the service takes to stop and start with either or both these issues, the Service Control Manager (SCM) can be modified to wait longer than the default 30 seconds. See this WIKI content.
The Service Control Manager will generate an event if a service does not respond within the defined timeout period (the default timeout period is 30000 milliseconds). To resolve this problem, use the Registry Editor to change the default timeout value for all services.
To perform this procedure, you must have membership in the Administrators group, or you must have been delegated the appropriate authority.
Caution: Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data.
To change the service timeout period:
If you have one of these errors I hope that this was able helpful in determining what was going on and helped in resolving the issue for you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.