lesmydad
asked on
Problem with subordinate ca issuing Certs in Windows 2000 domain
Hi having a problem with my CA infrastructure...Parent-ch
I created a Root CA on the DC in the parent domain, and a sub CA on the child DC. All was fine. AD was looking good. Both of course installed as enterprise CA's. Clients (other servers) begain to obtain certs. Parent clients had no problem, child clients got access denied. This was tried using the certsrv virtual directory and clients using Internet explorer.
I created a Root CA on the DC in the parent domain, and a sub CA on the child DC. All was fine. AD was looking good. Both of course installed as enterprise CA's. Clients (other servers) begain to obtain certs. Parent clients had no problem, child clients got access denied. This was tried using the certsrv virtual directory and clients using Internet explorer.
ASKER
isnt it automatic by def?
Autoenrollment is only available on Enterprise CA's if you use one of the certificate "templates"... nothing is automatic by default.
The idea is this... using a template (and granting appropriate users read access to that template) provides the Enterprise CA enough information (combined with the account data from the Active Directory) to issue a certificate. That's why stand-alone CAs don't support autorenollement.. they don't have enough information on what the certificate is to be used for. I presume you're also using the "web enrollement" feature?
I'm betting that the issue is something more simple... like a broken root. The Enterprise root CA "points to itself" for it's authority (kinda strange when you think about it) so, it's path really can't be broken. The Enterprise subordinate CA must be configured to point to the Enterprise root CA for it's authority. (Otherwise you've got a broken root).
Remember too, that you can't rename the server after installing Certification Services...
Let's eliminate the simple stuff, before we get too deep.
The idea is this... using a template (and granting appropriate users read access to that template) provides the Enterprise CA enough information (combined with the account data from the Active Directory) to issue a certificate. That's why stand-alone CAs don't support autorenollement.. they don't have enough information on what the certificate is to be used for. I presume you're also using the "web enrollement" feature?
I'm betting that the issue is something more simple... like a broken root. The Enterprise root CA "points to itself" for it's authority (kinda strange when you think about it) so, it's path really can't be broken. The Enterprise subordinate CA must be configured to point to the Enterprise root CA for it's authority. (Otherwise you've got a broken root).
Remember too, that you can't rename the server after installing Certification Services...
Let's eliminate the simple stuff, before we get too deep.
ASKER
Thax so much for the help. Im testing it out on the Thursday 11th Dec with my class (Network Infrastructure would you believe!!!). The scenario is kind of the same but there is no child domain. I will build the child CA however. I am slightly confused over the use of AD here. I think I read that on a stand alone CA it does obviosly not use AD, but a Stand Alone CA on a DC would infact make use of it if its available. This might sound strange but im sure i read it somewhere!!! I really need some good references. By the way I am using the /certsrv.
ps can you issue these user certs through a GPO? It seems you can with machine certs. Is this what client mappings are for?
ps can you issue these user certs through a GPO? It seems you can with machine certs. Is this what client mappings are for?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I did get the chance to test a root-sub infrastructure using stand alones (on a single subnet) and root-sub infrastructure using enterprise CA's (on another subnet). Seemed ok. The only problem I found was that when machines acquired certs using the client cert mmc, 'request new cert' wizard, certs were being given by the enterprise root domain, not the subordinate.
If you could answer this one i would be grateful? I will post more when I get the chance to run the scenario again but next time use parent child domains across networkA--Router--networkB
you get the points with gratitude from a tired out MCT
If you could answer this one i would be grateful? I will post more when I get the chance to run the scenario again but next time use parent child domains across networkA--Router--networkB
you get the points with gratitude from a tired out MCT
You've created a Enterprise Root CA... and a Enterprise Subordinate CA. I assume that you're issuing certification only from the Subordinate (Is that true?) The certificate path is not "broken"... each certificate can "find it's way back" to the root.
At the certificate console (on the subordinate CA), you've selected the automatic feature for issuing certifcates?