I'm having issues with the "enterprise CA" option being grayed out during installation of the ADCS role for a 2008 R1 Enterprise Edition server (for a new Ent. Sub. CA). The account I was using had Enterprise Admin rights in the root domain and Domain Admin rights for the child domain that the CA will be installed into (I don't need root domain admin since I have enterprise admin, right?). The server is already joined to the domain. I verified Enterprise Admins have full control for Public Key Policy container and all child containers. I have not tried to re-create this as another CA (2003) is online within the same domain/forest - I would prefer not having to do this if at all possible. I tried moving the capolicy.inf out of windir in case it was getting in the way. I believe I have the firewall cleaned up - is there an official resource that documents how to configure the firewall for just the CA? I'm not installing web services or anything else - this is a dedicated box. Thanks in advance...

Check out the c:\windows\certocm.log file. It will give you details on what went wrong when it tried to enumerate your membership in the Enterprise Admins group. For an enterprise CA, your account only needs to be a member of the Enterprise Admins group and a member of the local Administrators group. Due to the Universal group status of Enterprise Admins, I typically try and use a root domain account that is a member of the local Administrators group on the local server (rather than a child domain account added to Enterprise Admins Brian

Hi, Besides the above suggestions, this article might be helpful: http://support.microsoft.com//kb/938613 The containers are same in Windows Server 2008. Hope this helps.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Keep getting ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS I did some asking around - it sounds like they took the enterprise admins out of the schema admins group. I've never really seen it documented to need schema admin rights - which makes sense I suppose. Thanks for the help, guys!

OK, so I just tried with Enterprise Admin, Schema Admin, and Local Admin rights. Still grayed out. (yes, I logged out/back in after getting additional rights). I'm still curious if I really need Schema Admin or not, particularly since we're stifling the templates in the capolicy.inf. Our AD forest is 2003 for both parent and child, I'm unsure of the schema version but can find out if anyone cares. Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS Google gives me nothing on that one. Wow. Side note: the previous PKI was set up by a previous team with a number of customizations - I'm not sure just how typical some of these are for a very large enterprise. For example we have a separate OU for CA servers, I have put the box into that already. I guess I'm saying assume nothing about the environment, it is very customized and I cannot describe how it may or may not be special. Any ideas? Thanks again!

On Tue, 25 Jan 2011 19:30:36 +0000, Steve F wrote: OK, so I just tried with Enterprise Admin, Schema Admin, and Local Admin? rights.? Still grayed out. (yes, I logged out/back in after getting additional rights).? I'm still curious if I really need Schema Admin or not, particularly since we're stifling the templates in the capolicy.inf.? Our AD forest is 2003 for both parent and child, I'm unsure of the schema version but can find out if anyone cares. Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS Can you run whoami /groups with the currently logged in account and then post the results? Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca A CONS is an object which cares. -- Bernie Greenberg

Thanks, Paul. I already pulled myself back out of the enterprise & schema admin groups. Here's what I have left - if its necessary I can check again when I'm part of those groups again. There are a couple extra cert related groups I added myself to at the end here trying to troubleshoot stuff, probably not necessary but they shouldn't hurt anything. I'm leaving out a few groups that should have nothing to do with this to avoid clutter. Everyone BUILTIN\Users BUILTIN\Administrators BUILTIN\Certificate Service DCOM Access BUILTIN\Distributed COM Users NT AUTHORITY\INTERACTIVE NT AUTHORITY\Authenticated Users NT AUTHORITY\This Organization LOCAL CHILD_DOMAIN\Domain Admins CHILD_DOMAIN\(Our CA Team group) CHILD_DOMAIN\GPA_REPOSITORY_MANAGEMENT All groups are listed as enabled, if run from an elevated cmd box. I tried rebooting a few times. Tried logging in as child_domain\username and username@child.domain.test I turned on the software firewall logging and all logged traffic is allowed. Ran through the various event logs and nothing is jumping out at me.

On Tue, 25 Jan 2011 21:21:24 +0000, Steve F wrote: I already pulled myself back out of the enterprise & schema admin groups. You must be a member of either Enterprise Admins or Domain Admins in the forest root domain in order to install an Enterprise CA. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca That does not compute.

Per Brian's earlier request, here's more from the certocm.log 114.679.948: Begin: CCertSrvSetup::InitializeDefaults 109.7852.0: 0x80070002 (WIN32: 2) 109.7871.0: 0x80070002 (WIN32: 2) 109.7852.0: 0x80070002 (WIN32: 2) 401.1285.946: Opened Policy inf: C:\Windows\CAPolicy.inf 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 429.2157.0: 0x51 (WIN32: 81) 429.2157.0: 0x51 (WIN32: 81) 812.426.0: 0x8007003a (WIN32: 58) 429.466.0: 0x8007003a (WIN32: 58) 429.2390.0: 0x8007003a (WIN32: 58) 109.883.1838: Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS 109.1072.0: 0xe0000102 (INF: -536870654) 114.732.0: 0xe0000102 (INF: -536870654) 454.334.0: 0x80004005 (-2147467259) 454.334.0: 0x80004005 (-2147467259) 454.334.0: 0x80004005 (-2147467259) 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 454.244.0: 0x80004005 (-2147467259): AES-GMAC 454.244.0: 0x80004005 (-2147467259): SHA224 420.110.0: 0x80090014 (-2146893804): Microsoft Software Key Storage Provider 420.117.0: 0x80090014 (-2146893804): child_domain-HOSTNAME-CA 114.878.949: End: CCertSrvSetup::InitializeDefaults 114.4612.948: Begin: CCertSrvSetup::GetExistingCACertificates 114.4766.949: End: CCertSrvSetup::GetExistingCACertificates 114.3414.948: Begin: CCertSrvSetup::GetProviderNameList 114.3491.949: End: CCertSrvSetup::GetProviderNameList 114.3286.948: Begin: CCertSrvSetup::GetSupportedCATypes 114.3346.949: End: CCertSrvSetup::GetSupportedCATypes 114.3987.948: Begin: CCertSrvSetup::GetPrivateKeyContainerList 114.4098.949: End: CCertSrvSetup::GetPrivateKeyContainerList 114.4612.948: Begin: CCertSrvSetup::GetExistingCACertificates 114.4766.949: End: CCertSrvSetup::GetExistingCACertificates 114.3987.948: Begin: CCertSrvSetup::GetPrivateKeyContainerList 114.4098.949: End: CCertSrvSetup::GetPrivateKeyContainerList 114.3748.948: Begin: CCertSrvSetup::GetKeyLengthList 114.3796.949: End: CCertSrvSetup::GetKeyLengthList 114.3822.948: Begin: CCertSrvSetup::GetHashAlgorithmList 114.3963.949: End: CCertSrvSetup::GetHashAlgorithmList 114.3822.948: Begin: CCertSrvSetup::GetHashAlgorithmList 114.3963.949: End: CCertSrvSetup::GetHashAlgorithmList

One of our guys was picking up on: -2147467259 and -536870654. Not sure what he was looking at, but seems to be under the impression that it could be related to registry entries that dont' exist and cannot be created for some reason, or having to do with the server writing to registries or maybe to the sysvol? he was referencing 2008 R2, but we are running R1 - if that matters at all I don't know. For all I know this could be a total red herring or it could be right on target - any opinions? Thanks again for all your help Also (I can make a new thread for this if needed), does anyone happen to have a list of what schema changes do actually occur with a 2008 R1 Enterprise Sub. CA going into a 2003 AD? I know that v3 templates won't be available, etc. - I'm looking for what, if anything, does actually pop up. If there is a delta between 2008 R1 & 2003 R1 that would be awesome. I came across this that pointed to that the schema is actually updated in order to support v3 templates: http://www.corelan.be:8800/index.php/2008/07/14/windows-2008-pki-certificate-authority-ad-cs-basics/ I have LoadDefaultTemplates=0 in the capolicy.inf & it is a 2003 AD, so either way it shouldn't get updated anyways. However, for down the road I would like to know what specific schema changes are actually applied during this process.

No schema updates are applied during the installation. In fact, you will get V3 certificate templates even with the 2003 schema What you will not get are permissions for Read Only Domain Controllers on the KDC templates (Kerberos Auth, Domain Controller Auth, Directory Email Replication, and Domain Controllers). You also cannot install services such as HTTP-based enrollment, as these require the schema updates. Schema updates are performed by loading the LDF files only. Not by enabling ADCS. I think you may have replication issues with the DCs or something else not catching the enumeration. As Paul stated, your whoami dump does not include Enterprise Admins. Can you please try the installation with an account from the forest root domain that is a member of: - ForestRoot\Enterprise Admins - CAComputer\Administrators Thanks Brian

Sorry, Paul & Brian - I think you misunderstood me. I removed myself from those groups *after* attempting the problematic install. I'm not normally a member of Enterprise/Schema admins groups, it was just bestowed up on me temporarily (yes I logged out/back in afterwards and confirmed the group membership). By the time I could do the whoami dump for you I was already out and didn't want to request that kind of access for that kind of query unless there's some kind of nesting that you're wondering about, which I can check manually. However I was in the correct groups at install time as I attempted to note previously. When I next attempt the install I will be requesting access once again. Brian - much thanks for breaking down where the schema updates occur during the installation. I will try to dig up the LDF files to determine what is going on with web enrollment when it comes time to install that box. Right now I'm just doing the CA and nothing else.

So I guess the next question is: what does the Enterprise Admin need rights to, that may have potentially been removed? I have checked Public Key Services and the subfolders in ADSS. I have not taken a granular look at any of the contents, which I don't think there is a need to. Is there a way to enable more verbose logging that could result in better details in the logs?

This is not a change in permissions issue. The OCM log file is stating that it cannot determine if you are a member of the enterprise admins group. That is the problem that you need to solve. Brian

The devil was in the details... I omitted entering the WINS server settings, so the child domain was not able to see the rest of the directory. I got the Enterprise dot now. Thanks for all the help folks!

Um Steve, Please mark the answerers posts as answered, not your own. Brian