What Is A User Certificate Template

Andy Richter , Jeremy Wood , in Practical Deployment of Cisco Identity Services Engine (ISE), 2016

PEAP machine-only authentication

The advantages of this methodology are that it is easily configured from both a supplicant and an ISE policy perspective. PEAP machine-only authentication works by configuring the Windows supplicant to only ever provide its computer credential. A feature of Windows that not every administrator is aware of is that each AD member PC maintains an account in the AD, the username is the hostname, and a password associated with this account. This password for the machine account is even rotated occasionally depending on AD policy in the background. You can configure the native supplicant of a Microsoft Windows PC to always use this account for its authentication credential, never using a user credential. If you are to do this to every PC with wireless enabled on it in your company with GPO, you're going to give ISE a way to determine that each of these PCs is in fact a member of AD because it will present its AD credential. Any device authenticating with a user-type credential would then by definition not be a domain PC because each domain device would have already been configured via GPO to always only present a computer credential.

The disadvantages to this are that this can be an inflexible deployment option. First, it is generally available only to Windows PCs that are AD domain members.

Because each Windows PC is going only to dot1x authenticate with its computer credential always, it is impossible to apply network policy based on the user who is logged into the PC. ISE never actually learns who is logged into the system. If corporate policy requires that different network access policy be applied based on user security group membership, computer-only authentication is generally not an option.

Configuring a supplicant for this is actually really straightforward. Simply go into Advanced settings for the supplicant and set the suppliant for computer authentication.

To allow the same thing in ISE authorization policy is really quite straightforward.

In this case we are going to validate the aspects of the authentication we expect to occur: wireless dot1x, PEAP, and Domain Computer membership. All other methodologies are going to be denied (until we allow a BYOD policy at least).

X509 Authentication

With EAP-TLS authentication while ensuring corporate authentication you're able to ensure the user authentication from a corporate device; policy may be applied based on user directory security group membership. This user directory group membership is otherwise not possible through PEAP computer-only authentication. Why user resource differentiation you ask? Some examples of policy to be applied may look like as follows:

•: IT users may be assigned to a VLAN that allows access to network devices via virtual teletype (VTY) ACL.
•: Finance users may be assigned a general VLAN without restriction to network resources servicing their needs.
•: General users are assigned to a general VLAN but are provisioned an ACL that restricts access to services only R&D users may need.
•: Computer-only authentication allows for access only to WSUS, AV servers, and domain controller services.

The disadvantages of this methodology are simply that the organization choosing to deploy this must maintain an internal PKI that allows for certificate distribution to client machines for authentication. If a PKI doesn't exist, one must be designed, and deployed prior to this architecture being selected.

EAP-TLS authentication in and of itself will absolutely not determine that a device is a corporate asset. On the contrary, there are places that we expect to use EAP-TLS to authenticate a BYOD, distinctly noncorporate asset. To accomplish EAP-TLS authentication while simultaneously providing sufficient differentiation between corporate and BYOD we need to accomplish two basic tasks:

1.: Ensure that certificates issued to corporate devices have their private keys sufficiently secured to preclude users from applying a corporate certificate to a different device.
2.: Issue certificate attributes that make it identifiable as a certificate issued to a corporate device.

It is critical that administrators of PCs in an enterprise environment take steps to secure the certificate store to preclude users from easily removing certificates and their corresponding private keys from devices. Should both the private key and the public certificate be removed, the pair may be installed a third-party device and joined to your network and ISE would not be able to differentiate between the malicious device and the corporate device it was removed from. Thus, security of the cryptographic material is truly critical. While key security is not exactly in the scope of this book, here are some tips that we give to customers typically when they look to ensure that private keys aren't compromised off corporate devices:

•: Seems obvious, but mark the private keys as "no export" when creating the certificate templates in your AD.
•: Remove the end user from the local administrator group so they are unable to access the local key store.
•: Implement full disk encryption where possible to mitigate attacks at the local disk.
•: Disable removable media access to make removal of key information directly from a system more difficult.

As to the second point above, making the certificates used for corporate authentication different from ISE-issued certificates, the most common way to differentiate certificates is at the time of their deployment through templates. There are three ways to issue certificates that are pretty common in ISE deployments:

•: AD certificate enrollment with GPO
•: ISE-issued certificate (SCEP or Internal CA)
•: MDM-issued certificate

The ability to distinguish between AD GPO-issued certificates and MDM- or ISE-issued certificates is in the attributes the certificates have. Here are some common ones we may look for:

•: AD-issued certificates typically have the username/hostname of the certificate in the SAN (subject alternative) field as the UPN or DNS name of the PC.
•: MDM- or ISE-issued certificates typically have the username simply as the common name of the certificate.
•: The attribute of the certificate may be set with a specific watermark to identify how or where it was issued from.
•: The SAN of an ISE-issued certificate have the MAC address of the device the certificate was issued to.

Advantages in deployment of this methodology are numerous. X509-type authentication is considered the gold standard for network authentication. Properly implemented it provides strong authentication cryptographically and is efficient for the RADIUS server to process as it doesn't necessarily require queries to the external identity store for authentication, making it very efficient.

Because certificates may be issued to both the user and the machine (stored in different locations in the registry), both computer and user authentication may be performed. These specific authentications happen independently and, where possible, we recommend you perform both.

Let's take a second to talk about why doing machine authentication along with user authentication is important for a good user experience (and not only user). The reason for this is that if a user attempts to log in to a machine that has user-only authentication enabled on it, there are a variety of restrictions placed on it simply by the behavior of user-only authentication.

When a computer boots up, before anyone logs into it, when machine authentication is enabled, a machine is able to obtain an IP address, check in with any services that are available on the LAN that provide it security updates (WSUS and/or AV server), and connect to domain controllers. With connectivity to the domain controllers a few functions will be available that would otherwise be unavailable should the PC be disconnected from the network:

•: If the user had not ever logged into the PC, they would not be able to log in without connectivity to the domain controller.
•: If the user had previously logged into the PC but they were required to update their password per domain policy, they would not have the domain policy applied to them and they would not be prompted for password update.
•: If the user had previously logged into that PC, but had changed their password in the interim since that PC had been connected to the corporate network, they would have to log in with their old password since the PC in question would have no record of the updated password.
•: Typically login scripts run when machine authentication is enabled, whereas when user-only authentication is enabled, this is less flexible.

The configuration of the supplicant is fairly straightforward where certificate authentication is set, and presuming both user and computer certificates are issued, user or computer authentication is configured. Typically using GPO to configure the SSID is easiest. Here are the screenshots of my recommended GPO settings. First create a Vista or later wireless policy. ¹

Under Network Permissions there are a few settings you should configure. First, deny access to the corporate guest network to corporate PCs. There is typically no reason a company-owned domain member PC should be connecting to the guest network. Next, prevent connections to ad hoc wireless networks. There is generally no reason for corporate PCs to connect to an ad hoc Wi-Fi network. Lastly, enable the "Block Period" and set it to 1 min.

Add the SSID of the WLAN you're looking to use.

Set it for "Microsoft: Smart Card or other certificate" authentication which will set it for EAP-TLS and increase the maximum authentication failures to above 3. A good number to set this too is 5. It goes without saying that if you're using anything other than Wi-Fi Protected Access (WPA) 2/Advanced Encryption Standard (AES), you're nuts.

Under Properties next to the authentication method you should specify the CA that issued the certificates to your ISE servers. This helps prevent malicious actors from impersonating your enterprise wireless network.

Under the Advanced settings field both enforce advanced 802.1x settings (to ensure consistent EAP timers across clients) and enable Single Sign On. ²

As for ISE policy, the authentication policy must take into account certificate authentication selecting the correct principal X509 username. In our case, being that the certificate is deployed via AD GPO, the SAN would hold the UPN of the user/machine. ³

Looking at our authorization rules, they are more complicated than the AuthZ policy we configured for machine-only PEAP.

First off, there are two rules: one rule for machine authentication and one for user authentication:

•: Machine authentication occurs when no user is logged into the PC.
•: User authentication occurs when a user has logged in during the Netlogon process of Windows.

There are also more conditions in these rules than previously. Let's break them down one at a time:

•: Wireless_802.1x: Specifying the media used and the authentication methodology, specifically excluding MAB methods.
•: External Group membership: Validating that while we have authenticated the certificate as being valid, it is associated with a valid domain object in either Domain Users or Domain Computers security groups (per rule).
•: Authentication Method: PKI authentication to be sure that we're identifying the specific method used in case password authentication is used elsewhere in our policy.
•: Certificate Subject Name Contains: In our case, the domain we're using is presidio-labs.com. Because the UPN is used in the subject alternative, domain object will have presidio-labs in their UPN. This is the watermark I've chosen to use to validate this certificate was issued via GPO.

EAP-Chaining is a really effective feature when it comes to determining corporate access. It is effective in this case specifically because of our ability to simultaneously authenticate a device's membership to the directory, and the user logged into the PC simultaneously (or chained in the same authentication).

Advantages of this design methodology are basically twofold. First, implementation of PKI is not required for client authentication. This means that the server infrastructure required is simpler than it is for EAP-TLS. Second, because we have the user information as part of the authentication, we can apply network access policy based on the user's security group information along with the computer's own security group membership.

Disadvantages to this deployment are that at the time of this writing EAP-Chaining is a Cisco proprietary methodology that requires the AnyConnect NAM and is as such a Windows-only feature. If other platforms are required, OSX or any other mobile OS, another methodology would have to be used.

Let's look at the supplicant's configuration.

You have limited control over NAM from the UI exposed after it is installed so the first thing you are going to want to do is get ahold of the AnyConnect Profile Editor installer which will give you the tools you need to create the profiles you will be using. The NAM Profile Editor will give you a GUI front end to what will eventually be an XML file containing all settings needed by AnyConnect (AC) for your network configuration. After we create the file you will have a number of deployment options but we'll mainly concentrate on having ISE do that part.

Launching the Profile Editor will show you a GUI that looks similar to this.

The initial Client Policy page is fairly straightforward and provides good defaults for most environments. If you need to manage mobile data connections or configure Start Before Logon, this is where you can do that. Authentication Policy lets you define what methods you want the NAM module to use when authenticating to networks. Now this is important because unless you want to restrict your users from using some network types or you don't permit them to connect to unknown networks, these will impact the user connecting from home, hotel, airport, etc., which could result in some not-so-happy calls. If you are ready to deal with complaints and/or want only to ensure they are connecting only to absolutely secure network, then you can uncheck legacy options here. However, even though it should be fairly obvious that there are far better options to go with than Wired Equivalent Privacy (WEP), Temporal Key Integrity Protocol (TKIP), LEAP, etc., those should be retired if still in use; chances are that you will want to leave these settings alone.

Let's jump to Network Groups quickly since misunderstanding what it is will probably result in end user confusion and/or you having to redo your profiles. There is a single group listed by default and for the majority of deployments you don't want to change this. You will also probably want to keep all the networks you create in the global network list instead of adding them to the default network group. The global networks are always available no matter the network group that is selected.

The one possible use case for separate network groups would be location-specific networks you want to define for your users that might not be available at every site. Then you can create a group called "Site A," add site A's networks to it, and have it there for your users. The gotcha is that users need to actively switch between network groups that aren't global. That is why creating something like "Widget Group Networks" and placing your networks inside that group and having another group called "Personal Networks" for users custom ones might seem like a good idea but is going to cause a lot of pain on the user end as they have to switch between groups. Moral of the story: Use network groups only when you know your use case needs them and your users can handle it. Besides ISE handling your networks you should be able to reduce the number of SSIDs you need to configure anyway!

The big section here is obviously the Networks one; it's here you will be creating the different definitions of the networks your users will be connecting to. The Profile Editor does a decent job of walking you through the steps needed to configure a profile and only presents the tabs to you that you need based on what options you have selected. You will start off selecting a wired or wireless connection type; note that if you select wired, it will show up for all wired connections; so whatever you name the connection will show up even when connected to a non-dot1x network. It's mainly an aesthetics issue but something that could confuse end users. If you select a wireless network, you have the option of telling ISE that the SSID is hidden or if it is a corporate SSID. The hidden SSID option tells ISE that it needs to actively probe for the SSID since the network isn't going to be broadcasting itself. The corporate SSID option tells AnyConnect that the SSID has the highest priority and should always be connected to if it's in range. This is generally a good option for your corporate SSID obviously and since we're running ISE you really need only one anyway! It's not required however and depending on your use case might not be appropriate—always test in your own environment. You can also tell AC to run a script when it connects to a network but the catch is the script isn't included in the profile and instead you are required to place it on the machine with some other method. If you package the AC installers together into your own setup package, you can include it there or even deploy it with GPOs.

After selecting the type of connection, you are going to be prompted to select the security level. Since we're talking ISE here, you are always going to pick Authenticating Network since that is the type that lets you pick 802.1x parameters. For a wireless network you will have to pick the Association Mode (WPA, WPA2, etc.). Wired profiles will require you to define a Port Authentication Exception Policy so that AC knows how to handle traffic when there authentication/key management fails. It's safe to leave these options alone unless you really need to tweak how the supplicant works.

Your next task will be selecting either Machine/User/Machine or User as an option for the type of connection the profile will be used for. This is mentioned earlier but it's important to reiterate it again: If you are authenticating machines joined to a domain, you should implement machine authentication or machine and user authentication; if you do only user authentication, your domain machines will have issues since they won't be able to connect to the domain controllers while booting. Issues from this won't show up right away (cached GPOs) but new GPOs or GPOs that can be applied only during startup will eventually cause you to start troubleshooting weird machine issues—do yourself a favor and address this issue now. Since we're talking about EAP-Chaining we'll want to select Machine and User Connection.

Next we'll configure our machine authentication; our EAP Method will be EAP-FAST and we'll want to leave all the defaults that show up after that. Make a note of the option to use unauthenticated PAC provisioning; make sure this is off unless there is a really good reason you need it. The names are a little misleading, but unauthenticated provisioning just creates a TLS tunnel between the machine and the ISE allowing potential bad actors to man-in-the-middle attack the exchange without any knowledge of the client/ISE. Instead, authenticated PAC provisioning will verify the certificate provided by ISE before the exchange, ensuring that the client trusted the endpoint. Within the certificates area you can configure trust rules that can further verify certificates being used by ISE to ensure they have the correct CN/SAN before sending credentials across. Security wise this is a good thing to do; rogue RADIUS servers configured on a cloned SSID that your clients use can be used to steal credentials and we don't want that. The issue can be that the rules you create can cause issues with certificate flexibility down the road, if you move to a new domain name or change the names of the ISE PSNs. Using the rules is recommended but just keep those issues in mind while creating them. If you plan on using a wildcard certificate and follow best practice of segmenting your domain, then you can safely add that same segment as a rule (something like ".ise.company.tld") and be covered for the most part. For CA trust you probably want to trust the OS's certificate store so you don't have to manage another certificate store. For credentials we'll want to use the machine credentials, but the usage of the "host/anonymous" unprotected identity is up to you. It is best practice to leave that there because it provides some additional security for your clients and under normal circumstances you would rarely see that information within ISE. However, there are times when having a real user/machine name in the unprotected identity can be useful for troubleshooting clients that are having problems and it can also cut down on some confusion for other people who might not understand the inner/outer identity concept.

The user section of the configuration will be almost exactly the same as the machine section; there are only a couple of small changes to make and the first is "Extend user connection beyond logoff." Enabling this setting results in users appearing to be logged in even after they have logged off in Windows. Now you could make use of this to permit access to machines for maintenance purposes or something else that might be environment dependent but we recommend disabling the option and relying on proper machine authentication/authorization instead. This option has the potential to throw off your accounting information so if you are heavily investing in accounting, then definitely turn it off. The second option is the user credentials that are used; you probably want this to be "Use Single Sign-On Credentials" so that the domain credentials of the user will be passed to ISE and they don't have to type anything in. This setting will also fall back to prompt the user for a username/password.

Once you've created your networks, save the entire configuration as an XML file and simply copy it to: "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\newConfigFiles\configuration.xml." Restart the service and the configuration will be applied. The name is important and must be "configuration.xml" or else AnyConnect will ignore it.

There are two steps in configuring the ISE policy for EAP-Chaining. First, you need to enable EAP-Chaining in the authentication result. This would be under the allowed protocols in Authentication results.

Then you need to configure an AuthZ policy to utilize EAP-Chaining. ISE authorization policy would typically look like as follows in most normal EAP-Chaining situations. Notice that you can use the Network Access:EapChainingResult AuthZ condition here.

We are validating independently when a user is authenticated to a domain PC, and also when a domain PC is authenticating without a user authenticated (user will fail in this case).

Lastly in our examples, using the external MDM feature of ISE to validate corporate device is a pretty powerful method to authorize devices that are not Windows. Previously we've given you some pretty powerful examples that require the corporate devices are running Microsoft Windows, but we all know that companies issue devices that are not necessarily running Windows. ISE utilizes REST API that may be used by a wide variety of MDM vendors. If an enterprise uses an MDM, chances are that MDM is in the ISE compatibility matrix for integration and if your corporate devices are managed by that MDM, ISE can query the MDM for useful information such as registration or policy compliance. If the enterprise registers their corporate devices to the MDM, regardless of platform, ISE can validate that these devices are corporate assets.

The advantage of this method is twofold. First, the client platform doesn't matter to ISE. If your MDM vendor of choice supports an OS, ISE won't necessarily care what that is. My examples will include using the Meraki Systems Manager Enterprise which supports Windows, OSX, IOS, and Android. Second, the policy configuration of this is extremely simple from an ISE perspective. Simply integrate ISE into the MDM and MDM conditions appear in the AuthZ ruleset.

Disadvantages are limited to the fact that this does require ISE APEX licenses which is the highest cost plus the cost of the MDM. From a licensing perspective this may be the highest software cost. ⁴ If you don't have an MDM and you're not sure what direction you may want to go in, it doesn't hurt to check out the Meraki Systems Manager MDM. It has a good feature set for many customers and you can onboard up to 100 devices without incurring a license charge. ⁵

To register a device to the MDM if you're using the Meraki Systems Manager, the process is pretty straightforward. Under the Client List menu click "Add devices".

Under the Add devices menu, each supported platform has a different onboarding methodology. Select the platform of the device you'd like to onboard and follow the process.

If you're using another MDM solution, obviously, this will be very different.

From an ISE policy perspective here is what is required. First, integrate the MDM to ISE. To perform this task in ISE, browse through the UI Administration → Network Devices → External MDM. Then provide ISE the IP/hostname and API credentials to the MDM (from an ISE perspective, the process is exactly the same no matter what MDM you are using). ⁶

Finding those settings in Meraki you need to browse: Organization → Configure → MDM → ISE Settings. The ISE Settings menu is located at the bottom of the page.

Once the MDM is integrated to ISE, the MDM may be referenced in the AuthZ policy. For this to work smoothly you need two rules. You can use one rule to check for MDM registration and later in the AuthZ policy you'll need to create a web authentication rule that references an MDM portal. Let's start by looking at an AuthZ policy.

If a device is known by ISE to be registered to an MDM on the MDM server named Meraki, it's given a "PermitAccess" result on whatever VLAN the WLC is configured for. For ISE to know to check the MDM for its registration status ISE needs to perform a web authentication to an MDM portal. ⁷ Here is the result that I'm using in this example.

The result is a web authentication that uses an MDM redirect action, has an ACL ⁸ (airspace), and points to a portal and MDM server.

The user experience of this is, if a device previously registered, the MDM portal page will display a "Success" page after ISE does a REST lookup to the MDM, a CoA is issued, and the result is matched where MDM registration is selected. If the device is not registered, it will be prompted to onboard to the MDM. In the case of a Meraki MDM the CWA portal will request a Meraki network ID. If the end user does not know this (typically this would be kept by IT), they would be unable to gain network access beyond the MDM portal.

Back to the AuthZ policy; notice that there is an AuthZ rule that allows you to check for MDM compliance. This MDM compliance would be where you can create policy that the endpoint devices conform to requirements for network access. This may include preventing devices from connecting that do not have PIN lock configured, or preventing devices that are jailbroken. In Meraki to configure compliance policy those rulers are set in: Systems Manager → Configure → Policies.

Then you can apply this policy to all or some of the devices in your MDM by going through: Systems Manager → Configure → General and scrolling down to ISE Settings.

This way, any devices associated with a tag may be determined to be compliant or noncomplaint depending on which security policy you then associate with the tag.