Windows AD Certificate Services Family---Certificate publishing and Revocation (1)

How certificates are registered

In Windows2012, we can register a certificate for a user or computer in many ways, and the certificate is registered in a way that is relevant to the environment, for example, we want to use autoenrollment to bulk deploy certificates to a large number of users or computers, but in some cases We also need to deploy the certificate to a dedicated security principal through manual registration.

The differences between these methods are described below:

1. Automatic registration. With autoenrollment, administrators need to define permissions and configurations for certificate templates. These definitions help the requester to apply automatically, obtain and renew the certificate, and it does not need to interact with the end user. This method is used for the AD domain's computer and must be implemented through Group Policy to automate the enrollment of certificates.

2. Register manually. When manually enrolled, the device generates a private key and a certificate request, and then the certificate request is passed to the CA to generate a requested certificate, and the resulting certificate is sent back to the device and installed, which can be used to enroll the certificate if the requester cannot contact the CA directly or if the device does not support autoenrollment.

3. CA Web enrollment. We can enable a Web site CA so that users can obtain certificates, to use CA Web enrollment, we must install the IIS and Web registration roles in ADCs. Through the Web enrollment request certificate, the applicant needs to login to the website, select the appropriate certificate template, and then submit the application, if the user has permission to enroll the certificate, then the certificate will be issued automatically. Web enrollment is generally used when you cannot use automatic enrollment to issue certificates.

4. Register the agent. To use this method, the CA administrator needs to set up a registered proxy account for the user, who has the registration Agent permission and can register the certificate on behalf of other users. If you need a manager to preload a login certificate for a new employee on the smart card, you can use this method for a long time.

How does auto-enrollment work?

The most common method of deploying certificates in an AD domain environment is autoenrollment, which automates the deployment of certificates to users and computers. We can use autoenrollment in environments that meet specific requirements, such as through certificate Templates and Group Policy in the AD domain. But there's a very important place to note that standalone CAs are not able to use autoenrollment, and we must have an enterprise CA with AD integration for autoenrollment. We can use autoenrollment to automatically deploy a public key-based certificate to users and computers in the enterprise, and the Certificate Services administrator replicates the certificate template and then opens the enrollment and autoenrollment permissions for the template to the users and computers that need to obtain the certificate. Domain-based Group Policy can activate and manage autoenrollment.

Group Policy is applied by default when you restart your computer or login, and Group Policy is refreshed by default for 90 minutes on domain members, and our Group Policy setting is named "Certificate Services Client autoenrollment."

The autoenrollment task is triggered periodically every 8 hours after the last auto-enrollment activation, and the certificate template interacts with the specified user on a per-request basis, such as a request that pops up a 60s display window after the user has logged in.

Many certificates are distributed without a client, even though the registration is already known to be occurring. Most of the certificate types that are issued to compute and services are in this case, and many of the certificates issued to the user are in it.

Autoenrollment of certificates for clients in a domain environment must meet the following points:

1. Must be a member of Domain Admins or Enterprise Admins or the same level of permissions, which is the most basic requirement for setting up autoenrollment

2. To configure autoenrollment permissions for a certificate template

3. Configure an autoenrollment policy for a domain

Certificate roaming

Certificate roaming enables an enterprise to store certificates and private keys in an ad domain, which is stored separately from the application state or configuration information. Regardless of when a user logs in, certificate roaming uses the existing login and autoenrollment mechanisms to download the certificate and secret key to the local computer and, if necessary, removes the certificate and secret key when the user logs out. In addition, these certificates can maintain their integrity under any conditions, such as when a certificate is updated or when a user is logged on to multiple computers at the same time, which prevents the user from automatically enrolling for a certificate when they log on to each new computer.

Any time a private key or certificate changes in the user's local certificate store, the certificate roaming is triggered, regardless of when the user locks or unlocks the computer, and when the Group Policy is refreshed.

All communication between the local computer components and the certificate between the local computer and the ad domain is signed and encrypted, and the Win7 and later operating systems can support the certificate roaming feature.

Registration Agent

In WINDOWS2012CA, it can configure certificate enrollment on behalf of other users, to implement this, we must issue a specific certificate, which is generated based on the registration agent template. When the user obtains the certificate based on the registration agent template, he can register the certificate on behalf of other users. Unlike certificate Manager, the enrollment agent can only process registration requests, it cannot approve pending requests, or revoke issued certificates.

Note: The registration agent is a high security risk certificate, the person who has registered the agent certificate can impersonate others, because he can issue the certificate on behalf of other users, so you need to ensure that the certificate template has a good protection mechanism.

WINDOWS2012 contains the following three certificate templates, which allow different types of enrollment agents:

1. Register the agent. Used on behalf of other objects to apply for a certificate

2. Register the agent (computer). Used to represent other computer objects to apply for a certificate

3. Exchange Registration Agent (offline request). is used to request a certificate on behalf of another object and to provide the object name in the request. NDES (Network device Registration Service) uses this template as its registration agent certificate.

When you create a registration agent, you can further improve the enrollment capability of the agent, which can enroll certificates on behalf of other users through the group and certificate templates. For example, I want to deploy a restricted registration agent that can only register a smart card's login certificate, and only Hmm. This is an OU that is created for a specific office member or a security group.

In older Windows CAs, it is not possible for the enrollment agent to register only for users in a particular group, and it will only be possible for each user to have an enrollment agent certificate, and they can enroll certificates on behalf of other users in the enterprise.

The WINDOWS2008 Enterprise operating system introduces the limited enrollment agent feature. This feature allows us to restrict the user's access to the user who is designated as the registered agent, who can represent other users or enroll in a smart card certificate.

Typically, one or more individuals in an enterprise are designated as registered agents. These registration agents need to be issued with enrollment agent certificates that allow them to enroll certificates on behalf of other users. A registered agent is typically an enterprise security group, an IT security group, a member of a desktop group, because these individuals are objects that control security resources. In some enterprises, such as banks with multiple branches, desktop groups and security managers do not facilitate the local implementation of this task, in which case, we can assign the division manager or other trusted employees as a registered agent, let him go on behalf of users everywhere to apply for smart card certificate.

In Windows2012 CA, the first registration Agent feature allows one registration agent to be used for one or more certificate templates. In each certificate template, we can select the registration agent to represent the registered user or security group. We cannot constrain the objects represented by the registration agent with a specific domain OU or container, only by using security groups.

Note: The use of restricted registration agents can affect the performance of the CA, to optimize the performance of the CA, we need to minimize the number of registered agent accounts, minimize the enrollment agent's certificate template ACL account number, we recommend the use of group accounts to replace the individual user account as their account.

This article is from the "Dry Sea Sponge" blog, please be sure to keep this source http://thefallenheaven.blog.51cto.com/450907/1617121

Windows AD Certificate Services Family---Certificate publishing and Revocation (1)