Re: Auto Enrollment not working for one DC
- From: "Jorge de Almeida Pinto [MVP - DS]" <SubstituteThisWithMyFullNameSeparatedByDots@xxxxxxxxx>
- Date: Wed, 2 Jan 2008 09:40:14 +0100
see if the following helps:
taken from: http://support.microsoft.com/kb/889101
----
Certificate Services: Effects of security enhancements to the DCOM protocol
Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. Specifically, SP1 introduces more precise rights that give an administrator independent control over local and remote permissions for launching, activating, and accessing COM servers. For more information about the DCOM security enhancements that are introduced by Windows Server 2003 SP1, see Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1. To do this, visit the following Microsoft Web site:
http://www.microsoft.com/downloads/details.aspx?familyid=C3C26254-8CE3-46E2-B1B6-3659B92B2CDE&displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=C3C26254-8CE3-46E2-B1B6-3659B92B2CDE&displaylang=en)
Windows Server 2003 Certificate Services provides enrollment and administration services by using the DCOM protocol. Certificate Services provides several DCOM interfaces to make these services available. For correct access and usage of these services, Certificate Services assumes that its DCOM interfaces are set to permit remote activation and access permissions. However, because of the enhanced default security settings for DCOM that are introduced by SP1, you may have to update these security settings to make sure of the continued availability of these services after you install SP1. The following information explains how to do this.
By default, all DCOM interfaces in Windows Server 2003 SP1 are configured to grant remote access permissions, remote launch permissions, and remote activation permissions only to administrators. However, when you upgrade to Windows Server 2003 SP1, security configuration changes are made to the global DCOM interface and to the CertSrv Request DCOM interface. These changes are made to enable Certificate Services to work correctly.
Note that any changes that have been made to the CertSrv Request DCOM interface security settings before the installation of SP1 will be lost. The SP1 installation procedure resets all previous security settings in the CertSrv Request DCOM interface to their default settings.
During the SP1 installation process, Certificate Services automatically updates the DCOM security settings as follows: • CertSrv Request DCOM interface:• The Everyone security group is granted local and remote access permissions.
• The Everyone security group is granted local and remote activation permissions.
• The Everyone security group is not granted local or remote launch permissions.
• DCOM Computer Restriction Settings:• A new security group, CERTSVC_DCOM_ACCESS, is automatically created.
If the certification authority is installed on a member server, CERTSVC_DCOM_ACCESS is a computer local group, and the Everyone security group is added to it.
If the certification authority is installed on a domain controller, CERTSVC_DCOM_ACCESS is a domain local group. The Domain Users security group and the Domain Computers security group from the certification authority’s domain are added to it.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote access permissions.
• The CERTSVC_DCOM_ACCESS security group is granted local and remote activation permissions.
• The CERTSVC_DCOM_ACCESS security group is not granted local or remote launch permissions.
Note that if the certification authority is installed on a domain controller, and the enterprise is made up of more than one domain, Certificate Services cannot automatically update the DCOM security settings for enrollees from outside the certification authority’s domain. Therefore, these enrollees will be denied enroll access to the certification authority.
To resolve this issue, you must manually add the users to the CERTSVC_DCOM_ACCESS security group. Because the CERTSVC_DCOM_ACCESS security group is a domain local group, you can add only domain groups to it. For example, if users and computers from another domain, a domain named Contoso, have to enroll with the certification authority, you must manually add the Contoso\Domain Users group and the Contoso\Domain Computers group to the CERTSVC_DCOM_ACCESS security group.
If any enrollees that should be authorized by the certification authority are denied authorization after the installation of SP1, you can have Certificate Services update the DCOM security settings again. To do this, run the following commands at the command prompt in the following order. Press ENTER after each command.1. certutil –setreg SetupStatus –SETUP_DCOM_SECURITY_UPDATED_FLAG
2. net stop certsvc
3. net start certsvc
The DCOM_SECURITY_UPDATED_FLAG is an internal Certificate Services registry flag that indicates that the DCOM security settings were updated completely and successfully. Certificate Services checks this flag every time that it is started. The commands in the previous list reset the flag and then stop and start Certificate Services, causing it to update the DCOM security settings again.
----
also see:
http://www.eventid.net/display.asp?eventid=13&eventno=2719&source=AutoEnrollment&phase=1
--
Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto # MVP Windows Server - Directory Services
BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Baboon" <baboon@xxxxxxxxxxxxxx> wrote in message news:11F4F4B5-A3D3-4405-9B93-6C86810395F0@xxxxxxxxxxxxxxxx
I have a Windows 2003 domain with 2 domain controllers.
DC1 is running W2K3 Enterprise R2, SP2 and is an enterprise root CA.
DC2 is running W2K3 Standard R2, SP2 and is a subordinate root CA.
AutoEnrollment Requests for the domain are set to use DC1, but for some
reason DC2 is not able to get a domain controller certificate or a directory
email replication certificate. I have tried to request them manually and
that was unsuccessful as well. The Application Log records Event ID 13
saying that the request for each certificate failed due to denied access.
All computers, including DC2, had no problem getting a machine certificate,
DC1 had no trouble getting a DC or email certificate from itself, and oddly
enough the DC from the child domain was successful in getting a DC
certificate from the same CA. That DC is running the same OS version as DC2.
I checked the permissions on the DC template and everything looked normal.
What else can I look for? Does anyone have an explanation for what would
cause just this one DC to fail autoenrollment, when everything else on it
seems to function normally?
Thanks.
.
- Follow-Ups:
- Re: Auto Enrollment not working for one DC
- From: Baboon
- Re: Auto Enrollment not working for one DC
- Prev by Date: Re: copy useraccounts between dc's
- Next by Date: RE: Auto Enrollment not working for one DC
- Previous by thread: Re: Permission for user - SELF
- Next by thread: Re: Auto Enrollment not working for one DC
- Index(es):
Relevant Pages
|
