Your company has an Active Directory domain.
You plan to install the Active Directory Certificate Services (AD CS) server role on a member server
that runs Windows Server 2008 R2.
You need to ensure that members of the Account Operators group are able to issue smartcard credentials.
They should not be able to revoke certificates.
Which three actions should you perform?
(Each correct answer presents part of the solution. Choose three.)
A. Create an Enrollment Agent certificate.
B. Create a Smartcard logon certificate.
C. Restrict enrollment agents for the Smartcard logon certificate to the Account Operator group.
D. Install the AD CS role and configure it as an Enterprise Root CA.
E. Install the AD CS role and configure it as a Standalone CA.
F. Restrict certificate managers for the Smartcard logon certificate to the Account Operator group.
Correct Answer: BCD
Explanation/Reference:
http://technet.microsoft.com/en-us/library/cc753800%28v=ws.10%29.aspx
AD CS: Restricted Enrollment Agent
The restricted enrollment agent is a new functionality in the Windows Server® 2008 Enterprise operating system that allows limiting the permissions that users designated as enrollment agents have for enrolling smart card certificates on behalf of other users.
What does the restricted enrollment agent do?
Enrollment agents are one or more authorized individuals within an organization. The enrollment agent needs to be issued an enrollment agent certificate, which enables the agent to enroll for smart card certificates on behalf of users. Enrollment agents are typically members of the corporate security, Information Technology (IT) security, or help desk teams because these individuals have already been trusted with safeguarding valuable resources. In some organizations, such as banks that have many branches, help desk and security workers might not be conveniently located to perform this task. In this case, designating a branch manager or other trusted employee to act as an enrollment agent is required to enable smart card credentials to be issued from multiple locations.
On a Windows Server 2008 Enterprise-based certification authority (CA), the restricted enrollment agent features allow an enrollment agent to be used for one or many certificate templates. For each certificate template, you can choose which users or security groups the enrollment agent can enroll on behalf of. You cannot constrain an enrollment agent based on a certain Active Directory® organizational unit (OU) or container; you must use security groups instead. The restricted enrollment agent is not available on a Windows Server® 2008 Standard-based CA.
http://technet.microsoft.com/en-us/library/cc776874%28v=ws.10%29.aspx
Enterprise certification authorities
The Enterprise Administrator can install Certificate Services to create an enterprise certification authority (CA). Enterprise CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) and logging on to a Windows Server 2003 family domain using a smart card.
An enterprise CA has the following features:
An enterprise CA requires the Active Directory directory service.
When you install an enterprise root CA, it uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. You must be a Domain Administrator or be an administrator with write access to Active Directory to install an enterprise root CA.
Certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards. The enterprise exit module publishes user certificates and the certificate revocation list (CRL) to
Active Directory. In order to publish certificates to Active Directory, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains. For more information about the exit module, see Policy and exit modules.
An enterprise CA uses certificate types, which are based on a certificate template. The following functionality is possible when you use certificate templates:
Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in Active Directory that determines whether the certificate requester is authorized to receive the type of certificate they have requested.
The certificate subject name can be generated automatically from the information in Active Directory or supplied explicitly by the requestor.
The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.
http://technet.microsoft.com/en-us/library/cc780501%28WS.10%29.aspx
Stand-alone certification authorities
You can install Certificate Services to create a stand-alone certification authority (CA). Stand-alone CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions) and authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).
A stand-alone CA has the following characteristics:
Unlike an enterprise CA, a stand-alone CA does not require the use of the Active Directory directory service. Stand-alone CAs are primarily intended to be used as Trusted Offline Root CAs in a CA hierarchy or when extranets and the Internet are involved. Additionally, if you want to use a custom policy module for a CA, you would first install a stand-alone CA and then replace the stand-alone policy module with your custom policy module.
When submitting a certificate request to a stand-alone CA, a certificate requester must explicitly supply all identifying information about themselves and the type of certificate that is wanted in the certificate request. (This does not need to be done when submitting a request to an enterprise CA, since the enterprise user’s information is already in Active Directory and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer’s Security Accounts Manager database.
By default, all certificate requests sent to the stand-alone CA are set to Pending until the administrator of the stand-alone CA verifies the identity of the requester and approves the request. This is done for security reasons, because the certificate requester’s credentials are not verified by the stand-alone CA.
Certificate templates are not used.
No certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards, but other types of certificates can be issued and stored on a smart card.
The administrator has to explicitly distribute the stand-alone CA’s certificate to the domain user’s trusted root store or users must perform that task themselves.
When a stand-alone CA uses Active Directory, it has these additional features:
If a member of the Domain Administrators group or an administrator with write access to Active Directory, installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as Pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.
If a stand-alone CA is installed by a member of the Domain Administrators group of the parent domain of a tree in the enterprise, or by an administrator with write access to Active Directory, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to Active Directory.
Explanation/Reference:
http://technet.microsoft.com/en-us/library/cc753800%28v=ws.10%29.aspx
AD CS: Restricted Enrollment Agent
The restricted enrollment agent is a new functionality in the Windows Server® 2008 Enterprise operating system that allows limiting the permissions that users designated as enrollment agents have for enrolling smart card certificates on behalf of other users.
What does the restricted enrollment agent do?
Enrollment agents are one or more authorized individuals within an organization. The enrollment agent needs to be issued an enrollment agent certificate, which enables the agent to enroll for smart card certificates on behalf of users. Enrollment agents are typically members of the corporate security, Information Technology (IT) security, or help desk teams because these individuals have already been trusted with safeguarding valuable resources. In some organizations, such as banks that have many branches, help desk and security workers might not be conveniently located to perform this task. In this case, designating a branch manager or other trusted employee to act as an enrollment agent is required to enable smart card credentials to be issued from multiple locations.
On a Windows Server 2008 Enterprise-based certification authority (CA), the restricted enrollment agent features allow an enrollment agent to be used for one or many certificate templates. For each certificate template, you can choose which users or security groups the enrollment agent can enroll on behalf of. You cannot constrain an enrollment agent based on a certain Active Directory® organizational unit (OU) or container; you must use security groups instead. The restricted enrollment agent is not available on a Windows Server® 2008 Standard-based CA.
http://technet.microsoft.com/en-us/library/cc776874%28v=ws.10%29.aspx
Enterprise certification authorities
The Enterprise Administrator can install Certificate Services to create an enterprise certification authority (CA). Enterprise CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) and logging on to a Windows Server 2003 family domain using a smart card.
An enterprise CA has the following features:
An enterprise CA requires the Active Directory directory service.
When you install an enterprise root CA, it uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. You must be a Domain Administrator or be an administrator with write access to Active Directory to install an enterprise root CA.
Certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards. The enterprise exit module publishes user certificates and the certificate revocation list (CRL) to
Active Directory. In order to publish certificates to Active Directory, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains. For more information about the exit module, see Policy and exit modules.
An enterprise CA uses certificate types, which are based on a certificate template. The following functionality is possible when you use certificate templates:
Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in Active Directory that determines whether the certificate requester is authorized to receive the type of certificate they have requested.
The certificate subject name can be generated automatically from the information in Active Directory or supplied explicitly by the requestor.
The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.
http://technet.microsoft.com/en-us/library/cc780501%28WS.10%29.aspx
Stand-alone certification authorities
You can install Certificate Services to create a stand-alone certification authority (CA). Stand-alone CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions) and authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).
A stand-alone CA has the following characteristics:
Unlike an enterprise CA, a stand-alone CA does not require the use of the Active Directory directory service. Stand-alone CAs are primarily intended to be used as Trusted Offline Root CAs in a CA hierarchy or when extranets and the Internet are involved. Additionally, if you want to use a custom policy module for a CA, you would first install a stand-alone CA and then replace the stand-alone policy module with your custom policy module.
When submitting a certificate request to a stand-alone CA, a certificate requester must explicitly supply all identifying information about themselves and the type of certificate that is wanted in the certificate request. (This does not need to be done when submitting a request to an enterprise CA, since the enterprise user’s information is already in Active Directory and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer’s Security Accounts Manager database.
By default, all certificate requests sent to the stand-alone CA are set to Pending until the administrator of the stand-alone CA verifies the identity of the requester and approves the request. This is done for security reasons, because the certificate requester’s credentials are not verified by the stand-alone CA.
Certificate templates are not used.
No certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards, but other types of certificates can be issued and stored on a smart card.
The administrator has to explicitly distribute the stand-alone CA’s certificate to the domain user’s trusted root store or users must perform that task themselves.
When a stand-alone CA uses Active Directory, it has these additional features:
If a member of the Domain Administrators group or an administrator with write access to Active Directory, installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as Pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.
If a stand-alone CA is installed by a member of the Domain Administrators group of the parent domain of a tree in the enterprise, or by an administrator with write access to Active Directory, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to Active Directory.
