From 389 Directory Server

Common Problems and Resolutions

Setting up a windows domain to support auto enrollment is particularly challenging, especially for non-expert windows administrators. In this chapter, we discuss are some troubleshooting tips that will help you figure out the problems commonly encountered during active directory environment setup with respect to auto enrollment.

It is useful first to understand what happens during each page of the MMC "Request New Certificate..."

After you click on the 'Request New Certificate...' menu item, but before the first page of the wizard comes up:

1. the machine will run an LDAP search on the Root DSE, to find the Configuration Naming Context.
2. next, it will run an LDAP search under the CN=Enrollment Services, CN=Public Key Services, CN=Services branch of the Configuration naming context. Multiple enrollment services may be here. At least one should be the Auto Enrollment Proxy
3. From the list of enrollment services found in this tree, MMC will try to find one which meets its needs. At least all of these requirements must be satisfied:

• the multi-valued certificateTemplates attribute must have a value which matches the type of certificate MMC is looking for. For example, if the machine is a domain controller, it must have the template name 'DomainController' as one of the values
• the caCertificateDN attribute must match one of the caCertificateDN's in the CN=Certification Authorities subtree.
• the matching CA must be trusted on the machine where MMC is running.
• it must chain to a CA which is self-signed. That is, the trust anchor must be a self-signed root, not a subordinate CA.

1. After doing these checks, MMC will either then show you the first page of a wizard, or the error dialog below:

If you get a dialog as shown above with the following text:

The wizard cannot be started because of one or more of the following conditions:
- There are no trusted certification authorities (CAs) available.
- You do not have the permissions to request certificates from the available CAs
- The available CAs issue certificates for which you do not have permissions

This means MMC was unable to find a listing in Enrollment Services which meets all the requirements listed above. It is important to understand that MMC has not yet attempted to reach the proxy. This happens only after pressing 'finish' at the end of the dialog.

If everything worked correctly, you will get a wizard, which looks like this:

The next pages of the Certificate Request Wizard do not usually throw any errors. When the end of the wizard is reached, and you press 'Finish', MMC attempts to submit the request to the proxy, and may show the following error dialog:

The text reads:

The certificate request failed because of one of the following conditions:
- The certificate request was submitted to a Certification Authority (CA) that is not started
- You do not have the permissions to request certificates from the available CAs.

This means that MMC attempted to connect to the hostname of the Enrollment Service found during the first steps, but that this connection failed, perhaps for one of the reasons listed below:

1. The hostname in enrollment services is incorrect. Use LDP to view the Enrollment Service, and check the dNSHostName attribute. (This value is automatically populated when you push the Auto Enrollment Proxy Option 'Populate AD' button.)
2. Try to ping the above hostname to make sure DNS resolves the hostname to an IP address correctly, and that the host is reachable.

On the machine where the proxy is running, it should have been registered as a service (Administrative Tools -> Services), "Red Hat Auto Enrollment Proxy". This service is Stopped by default, but Windows should automatically start the service on demand as a request comes in. It runs in it's own process. It is useful to check in Task Manager to see if the process was started ("rhcsproxy.exe"). However, if you encountered the dialog above, it is likely that the process was not started.

If the rhcsproxy.exe process is running, it will log events to the Application log, viewable in the event viewer. Very detailed debug info is available if you check the options on the logging panel of the configuration utility.

If you are trying to do an enrollment from a machine OTHER than the one the proxy is installed on, you will have to ensure that the permissions for the DCOM component are appropriate. To do this, you need to open up the 'Administrative Tools/Component Services', and modify the Red Hat Auto Enrollment Proxy' DCOM component. The Security tab offers options for "Launch and Activation" and "Access" permissions. (It is never necessary to modify "Configuration Permissions").

To permit Domain Controllers to enroll, you can either select the 'Domain Controllers' group, or add individual machines. (It may also be possible to add the 'Enterprise Domain Controllers' built-in principal.)

If that machine is in another domain, you also have to ensure that the domain is properly trusted in the forest.

NOTE: This is the same error dialog as is described at the top of the page - it's just in this case, it appears after you press Finish.

The text reads:

The certificate request failed because of one of the following conditions:
- There are no trusted certification authorities (CAs) available.
- The available CAs do not issue certificates based on the specified template.
- You are performing a renewal request for a template that requires an RA signature.

If you see this error dialog after you have pressed finish, it means that MMC successfully connected to the Proxy, and submitted a certificate request, but the proxy did not return a certificate. In this case, the best thing to do is to check the Application log in the Event Viewer on the system where the proxy is running. There should be detailed logging from the proxy to indicate what went wrong.

---

Some Random Notes

• Component Services - DCOM configuration for Auto Enrollment proxy
  • set auth level to none
  • Add 'everyone' to Launch/Activation , Access permissions
  • Add user thats trying to launch the proxy to the 'Distributed COM Built-in principals Group'
• Make sure your active directory domains are able to cross-trust each other. Perform validate operation.
• Use the regmon, filemon utilities to figure out whats happening during auto-enrollment
• Add computer account to the built-in group for DCOM
• Check NTLM vs Kerberos authentication in the security log ( Event viewer )
• reboot all active directory machines
• enable audit logging in group policy
• Verify DNS settings
  • use dcdiag to find out what errors are there
• use NTP across all your windows machines to make sure time/date is in sync
• make sure your import the entire chain of CA certificates under the "Trusted Root Certificates"
• create new replication agreements if you find out replication problems with dcdiag
• use kerbtray.exe and purge all tickets if you see NTLM being used for auto-enrollment instead of kerberos
• child domain proxy configuration should be run as 'Administrator of the master AD domain'

Tools to download

• Windows Server 2003 Support tools [1] - includes LDP (GUI LDAP browser) and DCDIAG (used for diagnosing domain controller, and DNS problems.
• Filemon Regmon [http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Regmon.ms - very useful tools to see what is going on under the hood.
• Wireshark [2] - network tracing. Has some kerberos support.
• kerbtray - We mostly use this to clear out any kerberos problems by purging existing tickets.
• repadmin - to fix active directory replication issues

---

Appendix: Setting up domain a domain controller

Top Level