denetarik

The following is one of the most common error messages nowadays when trying to install roles and/or features via Server Manager: When attempting installation via Server Manager the following error message is displayed: " The WS-Management service cannot process the request. The service is configured to not accept any remote shell requests " When trying via PowerShell a similar error message is displayed. There are a number of guides out there resolving it via Local Group Policy Editor, changing netsh settings etc., but in my experience, in locked down environments where policies are set via GPO etc. some of those don't work and often it is also the case that policy changes are not properly persisted even if GUIs or PowerShell commands tell otherwise. The most reliable way of temporarily (until policies are re-applied) working around it, is as follows: If you are using Server Manager close it Open the registry editor ( regedit.exe ) and look for the following entry:      ...

Sometimes we have AD CS based standalone CAs within our environment, and those not being Active Directory integrated introduces a number of constraints. We might want, for example, to run CA database queries from a different server in the environment, for certificate tracking and reporting purposes. Since the CA is standalone and does not have any Enrollment Services object within Active Directory (even if it is created as part of the role configuration process it is probably a good idea to remove it afterwards), it is often not clear whether remote queries are possible, since running standard certutil -dump on an AD member server does not provide information about the particular CA Assuming the standalone CA runs on an AD member server and is therefore able to authenticate remote RPC/DCOM requests, it does work as long as you have the required connectivity and access rights. In order to query the CA database remotely: On the standalone CA server itself run certutil -dump , this wil...

Often it is difficult to understand which flags are available on the AD CS CA, e.g. when it comes to CA\CRLFlags In order to see all available flags including which ones are configured, run: certutil -v –getreg CA\CRLFlags That will display all flags. those that are displayed in brackets are not active (in the example above only CRLF_DELETE_EXPIRED_CRLS is enabled). As usual, CRL Flags can be enabled or disabled using certutil , with a + sign to enable and a - sign to disable, followed by the name of the flag. To enable a flag: certutil -setreg CA\CRLFlags + CRLF_PUBLISH_EXPIRED_CERTS To disable it: certutil -setreg CA\CRLFlags - CRLF_PUBLISH_EXPIRED_CERTS The same applies to other available settings for the CA, the parameter -v (for verbose) added to certutil displays all available options; try simply running certutil -v -getreg ca

Certification Authorities provide validation services (CRL/OCSP) via plain HTTP, which often raises security concerns and the "why not HTTPS?" question. The information being transferred is not sensitive (although OCSP has privacy implications), and the fact that those interfaces are exposed via HTTP instead of HTTPS is precisely due to Security concerns. This setup is coming from the Security considerations in RFC 5280 ​​​​​​​: " When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies. CAs SHOULD NOT include URIs that specify https, ldaps...