On a related subject, with a Windows 2008 R2 native domain Certificate Authority (Enterprise CA with offline root) I can use the certificate MMC snapin to generate CSR and submit to the enterprise CA, with no problem. But on Windows 2003 R2 systems in same domain I can't use the Certificates Snapin to generate a CSR to submit for certificates for RDP encryption. But I can use IIS on Windows 2008 R2, Windows 2008 and Windows 2003 to generate certificate request to the same CA and it works flawlessly.
The error is following: The wizard could not be started because one or more of the following conditions NO trusted Certificate Authorities available (That isn't true, I see the root CA certificate in my trusted certificate authorities and the enterprise EA is trusted by the Root CA therefore trust chain is correct) You do not have permissions to request certificates from the available CA's. (Again I can do this as my login account in the child domain, even though the CA is in the root domain, on windows 2008/windows 2008 R2) therefore that doesn't add up either. The available CA's issue certificates for which you don't have permissions ( again if I can do it as me in Windows 2008 and R2) then there really shouldn't be a difference to the same member servers in same child domain. Any ideas: This looked promising, but not sure if will fix the problem. http://blogs.technet.com/b/askds/archive/2007/11/06/how-to-troubleshoot- certificate-enrollment-in-the-mmc-certificate-snap-in.aspx Anyone run into this in their CA deployements and operations that could shed some light on it? I am sure the permissions are right since I can do it with no issues on Windows 2008/2008R2 with a Windows 2008 R2 CA, but it seems Windows 2003 R2 is throwing a hissy fit and won't generate the CSR which I usually do via the certificate snapin. Any ideas, I would be appreciative, Z Edward E. Ziots, CISSP, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org -----Original Message----- From: David Lum [mailto:david....@nwea.org] Sent: Wednesday, July 25, 2012 11:00 AM To: NT System Admin Issues Subject: RE: Certificates Our issue was one of the SUB-DC02 certs expired and hosed the RADIUS server because it couldn't auto-renew it. At least that's what it looked like when I troubleshot and resolved the issue. -----Original Message----- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Tuesday, July 24, 2012 7:03 PM To: NT System Admin Issues Subject: RE: Certificates All the certs issued by SUB-DC02 are still valid for use, as long as the receiving system still trusts SUB-DC02 (e.g. Client1 connects to Server1, and because Client1 has Sub-DC02 in their Trusted Enterprise CAs or Trusted Intermediate CA or Trusted Root CA store, it will still trust the Server1's certificate) You should revoke SUB-DC02's signing certificate on ROOT-DC02 (assuming that is your root CA, and SUB-DC02 is an issuing CA). As long as your clients can connect to the revocation list published by ROOT-DC02, then they will stop trusting certs issued by SUB-DC02 You can also do the metadata clean-up in AD for references to SUB-DC02, which will stop various Windows wizards attempting to connect to it, as it will no longer be advertised in AD as an enterprise AD-integrated CA Cheers Ken -----Original Message----- From: David Lum [mailto:david....@nwea.org] Sent: Tuesday, 24 July 2012 11:43 PM To: NT System Admin Issues Subject: RE: Certificates " What are you trying to achieve -- just clean up the stale enrollment publication data in the directory and make the error go away? " Yes. I'm tempted to just blow away any cert in the "Issued Certificates" folder on the CA that says SUB-DC02, but I don't know certs enough to know if there would be unintended consequences. I ran the " certutil -dcinfo deleteBad" command and it did remove some references, but not all. Actually this article looks like it's what I need: http://support.microsoft.com/kb/555151 " I have a tool kicking around somewhere that'll scan AD for published certs and reports on their validity, issuer, etc. Give me a yell if you think this would be handy here." Yell!! Dave -----Original Message----- From: Steve Kradel [mailto:skra...@zetetic.net] Sent: Monday, July 23, 2012 6:43 PM To: NT System Admin Issues Subject: Re: Certificates What are you trying to achieve -- just clean up the stale enrollment publication data in the directory and make the error go away? The KB article should largely suffice (the metadata in AD aren't too complicated), just proceed with caution. I've done this on numerous occasions when tidying up customers' ADCS cruft. If you know that there are certs out there using a particular template, and you want to reissue them cleanly, you could supersede the template. Of course it's a bit tricky to know for sure as the old certificate database is toast. I have a tool kicking around somewhere that'll scan AD for published certs and reports on their validity, issuer, etc. Give me a yell if you think this would be handy here. --Steve On Mon, Jul 23, 2012 at 5:23 PM, David Lum <david....@nwea.org> wrote: > We have a DC that we rebuilt and apparently it was running certificate > services and we didn't know about it until after the server was rebuilt. > > > > Details: > > 1. Running an MS tool it returns the result that "A certification > authority is inaccessible" and it tells us SUB-DC02 is the cert > authority that cannot be reached. > > 2. We rebuilt a SUB-DC02 a few months ago (old one died due to > hardware failure) and we didn't know it was a certificate authority > > 3. The resolution suggested by the MS tool is this > http://support.microsoft.com/kb/889250 > > 4. The CA server we DO use and know about is ROOT-DC02. The > instructions in step 3 make it look like I am to do the steps on > ROOT-DC02, but I read is as "this is how you decommissions the CA > gracefully" and not "this is how you fix the removal of a CA that's already gone" > > > > Thoughts? > > David Lum > Systems Engineer // NWEATM > Office 503.548.5229 // Cell (voice/text) 503.267.9764 > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
