Microsoft PKI / CERTSVC_DCOM_ACCESS Group

Oh my... a CA at every site instead of just using the MMC... wow...  thank you - that just made my day!  req's are req's, gotta love em!  

Please tell me there is at least a common root CA... something tells me that there is not.  This would be a bad thing with an org with dozens of CAs floating around if they want to import dozens of root certs into each office so they all trust each other.  Keep in mind the MS cert store will give you problems if you add about 60 root certs or so, and your performance will lag hard.  Cross certification between all of these would have to be the way to go if they want cross-ca trust without a common root:
http://technet.microsoft.com/en-us/library/cc787276.aspx

This one gets kind of fun.. first things... in addition to adding DC group to the CERTSVC_DCOM_ACCESS DL group, also add teh Domain Users and Domain Computers groups.  Also, if there are that many CA servers, are there just a bunch of DC's for one domain, or a number of domains?  You may need to add DC group from each domain into that group.

In the CA MMC, you may need to go into the properties of the CA and security - add the same with permissions to request certs (unless otherwise restricted - this assumes that computers can autoenroll machine certs and users can at least request their own certs, regardless of Cert Mgr approval step or not).

Add DC's group to permissions for \Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA -- note this should NOT be set to Everyone once private key is generated - this is both a bad idea and it doesn't work.  May also need to add System and local admin group.

Open CA management console from "Administrative Tools". Right-click the server name and select "Properties". Select security and add group "Domain Controllers". Select checkbox "Request Certificates" and click OK.

I'm not sure how this goes after you already have a few installed with more to go, but try this once and see if that helps, you may need to run after each new install...  I believe this might prevent the rest of them but not positive - been awhile since i dug around the guts of this one, usually this just comes up with one CA server and helps alot, I forget the details for usage in multiple CA enviroment.

certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc.

Getting time for lunch, I'll call that good for now, let me know whatever you need more info on.

Hi there

Its not as bad as you might think in terms of root certs. There is a common offline root, and the certificate for that is published via Active Directory, and pushed around via GPO (belt & braces aproach), so only one common root in a 3 domain AD forest, where the majority of the CA requirements are in just one of those domains, and that domain has both issuing subordinates and autoenroling clients

I'l try and provide answers to your points above:

- Domain Computers and Domain Users are already members of the CERTSVC_DCO_ACCESS group by default, so I don't need to add those.
- I have tried running certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG, then restarting certsvc, but this makes no difference, because by that stage the damage has already been done at the CA install stage which must be be prior to running this command

Just got a coule of questions on your points too:

Where you say "Open CA management console from "Administrative Tools". Right-click the server name and select "Properties". Select security and add group "Domain Controllers". Select checkbox "Request Certificates" and click OK.", is this liley to make a diffference, because provided the Domain Controllers group has been made a member of the CERTSVC group, the clients are able to autoenroll fine from the issuing CA (which is a domain controller).

I haven't repermissioned the RSA folder at this point, because everything works fine if group membership is right. Really it's just how to prevent the group being recreated that I'm after. I've tried some wild crazy ideas like removing permissions inheritance on that group and turning off SSTEM permission (all in a test environment) but none of tat works, beause inheritance is turned back on, and SYSTEM as added back, along with the fact that it then allows the group to be recreated.

I'd like to simplfy the overall design, becasue I think I could do it by putting Certificate Manager Restrictions in place, allowing members of some groups to only issu and revoke some certs, but my customer won't allow that, so I'm having to find an alternative solution.

Check to see what the forest functional level is - if it is at 2000 see if you can update it to 2003.  However, I'm not sure that this would help.

From http://support.microsoft.com/kb/932457
Certificate Services cannot automatically update the DCOM security settings for client computers from outside the certification authority's domain if the following conditions are true:
" The certification authority is installed on a domain controller.
" The enterprise consists of more than one domain.

Hi,

Sorry, should have added that first off. Its Windows 2003 mode.

Just to clarify, its not the updatng of DCOM permisions that I want (thats all fine under the right circumstances), its just how to stop the CERTSVC_DCOM_ACCESS group from being deleted/recreated every time i sinatll a new CA (if indeed it can be done at all)

I got that, like I said, it was worth a shot, but I didn't think the forest mode was going to do it.  The second part pointed more to that the issue is caused by the CAs being in different domains in the same forest.  Each one must create its own DL group when done on a DC.  If it was done on a member server, then they would each be creating their own local group of the same name.

If these were all in the same domain, then this should not be occurring.  As it is, they aren't so they need to - nature of the beast.

The only thing I could think of that could possible do it would be to create a group outside of the domain, e.g. Universal Group, that would empass each domain.  I don't think this would work, but would be the only feasible chance as it has to go beyond domain boundaries.  Something MS could improve upon I think with some kind of AD extension in the PKI area of the ldap config.

Hi again

All of the CAs are in the same domain. It's an unusual setup, I'm afraid. Its a three domain model, with an empty root (and ideally this is where I would like the CAs to sit, but not easily possible I'm afraid), the first child doman is a resource domain, so it holds Exchange servers, MOSS servers, SQL, ISA etc. The second child domain is the user domain, but it is also the domain in which the resources for each site site reside. It's not like the usual centrally controlled corporate environment I'm afraid, instead its the educaion sector, and each school is in my AD, but also largely autonomous from a management perspective, which is part of the need to have their own CA.

I like the idea of assigning perms to a different group though...any idea what permissions the CERTSVC_DCOM_ACCESS group is actually given within the AD?

Thanks again for your help & advice so far...

I suppose one way could be to copy the certsrv COM object over and assign permissions that way - untested theory...  This is tied to the CertSrv service (Certificate Services) which is run from C:\WINDOWS\system32\certsrv.exe.

If it got installed prior to SP1, you could assign the DCOM manually and then upgrade it - again I'm not certain if this would really matter or not or if it is completely hardcoded.

* after doing that one would have to run this prior to full installation, so that it doesn't keep triggering the DCOM update:
1. certutil setreg SetupStatus SETUP_DCOM_SECURITY_UPDATED_FLAG
2. net stop certsvc
3. net start certsvc

Hi

Sorry, haven't had a chance to test out the alternate group theory yet. However what I have found is that using a Windows 2008 DC/CA combination (after having updated schema, PDC and all that) resolves the problem. I'll get back with the outcome of using a different group on Windows 2003, but it could be time to upgrade!

For those that might find this helpful...

I tested the Windows 2008 idea in what was originally a Windows 2003 mode forest on Windows 2003 Server, did the schema updates, then put a 2008 DC in and put a CA on it.

One more thing I've since tried,as an addition to the previous test, is to now go back and install an additional CA on a new Windows 2003 DC to test whether the group gets changed again from an install on Windows 2003. It doesn't, so part one of the answer here, is to simply put one Windows 2008 DC in, and the problem goes away. I'll get back with the results of the alternaive method, which it to use a seperate group and repermission DCOM donfig, without using a Windows 2008 DC.

Craziness.... nice find with the 2008 CA!

Forgot this one was still open, so for the puposes of putting this one to bed and closing it off, here's an extract of an internal email I sent detailing my findings on this matter:

"         For the purpose of the lab, for all CAs, read DC and CA (combined role, as per the environment in live)
"         In an environment with an existing 2003 CA, installing a 2nd or subsequent 2003 CA creates a new CERTSVC_DCOM_ACCESS group and breaks everything (as per Friday)
"         In an environment with an existing 2003 CA, installing a 2nd or subsequent 2008 CA does not modify the existing CERTSVC_DCOM_ACCESS group or create a new one
"         In an environment with a 2003 CA and a 2008 CA, where the 2008 CA was the last one to be installed, installing an additional 2003 CA creates a new CERTSVC_DCOM_ACCESS group, breaking things again
"         In an environment with a 2003 CA and a 2008 CA, where the 2008 CA was the last one installed, installing an additional 2008 CA does not modify or break the CERTSVC_DCOM_ACCESS group
"         In an environment with a 2003 CA and a 2008 CA, where the 2008 CA was the last one installed, uninstalling the 2003 CA deletes the CERTSVC_DCOM_ACCESS group entirely, breaking things again
"         In an environment with a 2003 CA and two or more 2008 CAs, where a 2008 CA was the last one installed, uninstalling a 2008 CA does not delete or modify the CERTSVC_DCOM_ACCESS group



Hope this helps someone with the same issue. Paranormastic, I'm happy to give you the points because without your help I wouldn't hve known where the certsvc group was used. Thanks!