Recently I was asked about how to read Enrollment Agent Rights and Certificate Manager Restrictions in ADCS. At first, I would like to make a little introduction about the subject.

Enrollment Agents

With Active Directory Certificate Services (ADCS) you can designate one or more enrollment agents to enroll on behalf of other users. One of the most common scenarios is smart card provisioning. Suppose, you purchased smart cards and plan to issue them to employees. You will designate one or more highly trusted persons who will:

• instruct employees about smart card usage policies;
• register smart card serial number/other data in the accounting system (some certificate lifecycle management system);
• prepare smart card for use (print labels and so on);
• install certificate for another employee.

Enrollment Agent Restrictions cover the last point in the list. Restrictions define three major parts:

About the problem

Almost everyday we hear about SHA1 deprecation policy. Many commercial CAs now sign end-entity certificates with SHA2 (actually, SHA256) and. Some of them upgrade issuing CAs to SHA2. Many security administrators  move their private CAs and certificates to SHA2 signatures. Unfortunately, not all do this migration correctly. Companies just configure their CAs to sign certificates with SHA256. Is this enough? Actually, not.

Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:

Recently I was tasked to configure SSL/TLS protocols and cipher suites for internal web servers via Group Policy. At first, we collected a list of web server and web client applications to determine the weakest possible SSL/TLS protocols. Once the list was complete, we deployed sample policy in test OU and finally applied them to the rest domain.

Now I was tasked to scan web servers to determine if they match new security policy. In order to minimize my effort in testing, I wrote a simple PowerShell script that accepts a list of web URLs and tests each host with a list of SSL protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. Here is a sample code:

SYMPTOMS

Consider the following scenario. You configured Software Restriction Policies (SRP) to allow run all applications that are signed by the specific signer by creating a Certificate Rule against the signer certificate.

When the policy is refreshed on the client, user cannot run the application, because it is blocked by Software Restriction Policies.

CAUSE

This behavior occurs when the certificate is issued by a Certification Authority (CA) which do not include or provide incorrect issuer information in the Authority Information Access (AIA) extension in the signing certificate. In addition, intermediate CA certificate is not installed in the local store. SRP reads only signing certificate in the digital signature and ignores the rest certificates.