Update 14.03.2013: added workaround information

SYMPTOMS

Consider the following scenario. You install and configure Certificate Enrollment Web Service (CES) against a Certification Authority (CA) that has spaces and other disallowed by HTML URL scheme characters in the certificate name. When you attempt to use the service for certificate enrollment, the following message appears:

Updated 20.06.2018: clarified the purpose of NTAuthCertificates DS container.

Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.

Intro

All ADCS related containers are stored in configuration naming context under Public Key Services container:

CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}

Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.

Here is a screenshot from ADSIEdit.msc tool:

Hi again! Recently I faced an issue with my Test-WebServerSSL function which is also available in my Powershell PKI module.

Issue

In certain cases, the function returns certificate chain errors, while Internet Explorer (as well as other web browsers) works normally and do not report anything wrong. For example, you can open https://www.nic.lv/ web site without any issues in your web browser. When you run Test-WebServerSSL function against this web site, you get the following:

Hello folks, CryptoGuy is here again. Today I’ll talk about the most common ways to violate default SRP configurations and how to protect SRP against them.

System folders with write access

It is generally correct that regular users haven’t write permissions on system folders and we can safely allow to run any program from these folders (C:\Windows). However this statement is not fully correct. This is because there are folders where regular users have write and execute permissions. There are at least two default folders:

1. System temp folder: C:\Windows\Temp
2. Print spooler folder.

Here is a screenshot of Temp folder ACL:

Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.

When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).

Multiple policies

The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins: