70-742 Additional Notes – Standalone Certificate Authorities

70-742

Overview

Stand-alone certification authorities (CAs) can issue certificates for purposes such as:

  • Digital signatures
  • Secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions)
  • Authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS)

Characteristics

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.
  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user’s information is already in AD DS 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 submitted information and approves the request. The administrator has to perform these tasks because the certificate requester’s credentials are not verified by the stand-alone CA.
  • Certificate templates are not used.
  • 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.
  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key.

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller 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 Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.

70-742 Additional Notes – AD Federation Services with Device Registration

70-742

Overview

You can add the Device Registration Service (DRS) to your Active Directory Federation Service (AD FS) configuration. DRS provides seamless second factor authentication, persistent single sign on, and conditional access to devices attempting to access your corporate resources.

Prepare your Forest

To properly implement DRS, you first should prepare your forest. To do this you must meet the following requirements:

  • You must be an Enterprise Admin
  • The forest must be at the Windows Server 2012 R2 schema or higher
  • There must be at least one Global Catalog Server in the forest root domain

Step 1 – On the Federation Server run the PowerShell command:

Initialize-ADDeviceRegistration

Step 2 – When prompted for the ServiceAccountName – enter the service account you used for AD FS

Enable DRS on a Federation Server Farm Node

One each node in the farm, run the PowerShell command:

Enable-AdfsDeviceRegistration

Enable Seamless Second Factor Authentication

Use the AD FS Management Console and navigate to Authentication Policies. Select Edit Global Primary Authentication. Click Enable Device Authentication and click OK.

Update the Web Application Proxy Configuration

On the WAP server – run the PowerShell command:

Update-WebApplicationProxyDeviceRegistration

When prompted, input an account with administrative credentials.