Re: Auto Enrollment not working for one DC

Thanks. Problem solved; I just don't know how.

I was already aware of the post SP1 problem with the CERTSVC_DCOM_ACCESS
group, because I have a child domain that needed to autoenroll with the same
CA. I added the domain users, computers and domain controllers from the
child domain to that group some time ago. This allowed the DC in the child
domain to autoenroll, as I had stated in my post. The same 3 groups from the
parent domain were already members, as you would expect, so that wasn't the
culprit.

Per the article you sent, I ran "certutil -setreg SetupStatus
-SETUP_DCOM_SECURITY_UPDATED_FLAG". The only other thing I did, per one of
the posts at eventid.net, was to change the permissions on the Root CA object
itself to grant domain controllers the "Request Certificate" permission. (It
seems that this should not have made a difference because Authenticated Users
already had that permission.) By the way, thanks for making me aware of that
web site as it looks like it can be very helpful.

This problem had existed since I installed the DC a few months ago, and
continued after many reboots, so something above definitely fixed the issue.

Cheers.

"Jorge de Almeida Pinto [MVP - DS]" wrote:

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.


.

Relevant Pages

  • Re: Auto Enrollment not working for one DC
    ... Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. ... Windows Server 2003 Certificate Services provides enrollment and administration services by using the DCOM protocol. ...
    (microsoft.public.windows.server.active_directory)
  • [NT] Flaw in Outlook 2002s Way of Handling V1 Exchange Server Security Certificates Leads To Informa
    ... Beyond Security would like to welcome Tiscali World Online ... Encryption is used to prevent parties other ... Outlook uses public key certificates to facilitate the exchange of the ... there are other certificate options including V1 Exchange Server Security ...
    (Securiteam)
  • Re: Embedding Simple MFC GUI app into website
    ... particular technology is "evil" goes beyond common sense and increases ... his denouncement of ActiveX and Java (and Flash, ... ActiveX, in particular, is an antipattern for security. ... Since you must obtain a certificate for code signing from the trusted ...
    (microsoft.public.vc.mfc)
  • Re: self-signing certificate
    ... saw that my self-signed certificate was under the ... Now warnings at all when opening with medium security set. ... And, if correct, why the warning? ...
    (microsoft.public.access.security)
  • Re: DTExec slow
    ... It was actually this way before SP1 as well. ... The thing is that when you execute a package, CryptoAPI, on behalf of the SSIS service, attempts to go out to the internet to check a certificate revocation list. ...
    (microsoft.public.sqlserver.dts)