70-742 Additional Notes – Standalone Certificate Authorities

August 20, 2017 at 1:54 pm

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

August 19, 2017 at 2:53 pm

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.

VIRL Gets a Refresh! (Finally)

August 17, 2017 at 4:55 pm

VIRL

Cisco’s own answer to GNS3 is finally getting an update with lots of improvements. Granted they had us spoiled before at the breakneck pace they were releasing updates.

VIRL PE 1.3 will be released on Wednesday, August 23, 2017. Important changes in this release include:

  • Updated virtual machines:
    • IOSvL2, including many bug fixes, including fixes for ARP L2 MAC address learning and port channel issues
    • CSR1000v 16.5.1, including an increase in the bandwidth cap from 100kbps to 1mbps
    • IOS XRv 6.1.3
    • ASAv 9.7.1
    • NX-OSv 9000 7.0.3.I6.1, not bundled, but available for download and supported out-of-the-box
  • Infrastructure refreshed to Ubuntu 16.04, KVM/QEMU 2.5, and OpenStack Mitaka to ensure the ability of VIRL PE to run the latest router VMs.
  • Updated installation instructions and simpler single-interface installation options.
  • Bug fixes for the core VIRL PE components.

Important Notes:

  • Single user restriction will be enforced starting with VIRL PE 1.3. That is, with version 1.3 and newer, only a single project ‘guest’ with a single user ‘guest’ can be created and used at the same time.
  • VIRL PE 1.3 will require a fresh installation, either by deploying the OVA or — for bare metal systems — by installing the ISO image. If you are running VIRL 1.2.83 or earlier today, you cannot perform an in-place upgrade.
Pearson Education (Peachpit)

VISIT OUR SPONSOR!