Chapter 5

Authentication

Abstract

This chapter will focus on the authentication portion of ISE starting off with configuring the protocols used within the authentication policy and then moving into recommended changes that should be made to the default policy. PAC provisioning options for EAP-FAST are covered as well as setting up certificates/trusts for EAP-TLS.

Keywords

authentication

AuthC

Remembering that ISE is a RADIUS server it’s important to remember that we’re going to go through the AAA steps: authentication, authorization, and accounting.

To start the AAA process the first thing you have to do is steer the RADIUS authentication (AuthC for short) to the correct identity store or stores. Good ISE design calls for AuthC rules to be as short as is plausible so don’t try to get too fancy.

The idea is not to try to decide what to do with the user (what kind of access they should have); that’s the role of the authorization ruleset later. Rather the purpose of the authentication is to establish who is asking for network access. Different methods of authentication require us to look in different identity stores for the correct type of authentications.

Anatomy of authentication policy includes the following items:

• Conditions

• Network Access Service

• Identity store

Conditions would be the network access methodology or specific authentication types:

• Dot1x, wired or wireless

• MAB, wired or wireless

• VPN

• Web authentication

• Certificate authentication

• MS-CHAPv2 authentication

Network Access Service can be one of two things:

• Allowed Protocols

• RADIUS proxy

Most typically it’s “Allowed Protocols” where there is a list of allowed RADIUS authentication methodologies. This is important because it allows you to specify which authentication methodologies are allowed in your RADIUS authentication in ISE. Examples of these include (but are not limited to):

• Password Authentication Protocol (PAP)

• CHAP

• EAP-TLS

• PEAP:

• EAP-MS-CHAPv2

• EAP-GTC

• EAP-FAST:

• EAP-Chaining

To configure an authentication result, or allowed protocol, you need to browse to the authentication policy element: Policy → Policy Elements → Results → Authentication → Allowed Protocols.

A lot of deployments don’t require a lot of customization here. There are a few nondefault customizations that you should consider when you’re designing ISE authentication.

When deploying EAP-Chaining, this method is not enabled by default so if you want to use it you will need to enable it under EAP-FAST.

If you are implementing a feature that requires anonymous in-band PAC provisioning, it is not recommended to allow this kind of provisioning wirelessly. You can restrict this by configuring multiple allowed protocols where anonymous PAC provisioning is allowed over wired media where session snooping is unlikely, and disallowed wirelessly.

Lastly, the preferred EAP Protocol field is an option that is used when you need to propose an EAP method to a client that is authenticating to a network. In operations of a well-designed enterprise network, nearly all clients will have their supplicant configured with a specific EAP method (EAP-TLS or PEAP). In some cases, where a client is connecting to a network for the first time, it’s helpful to propose a specific EAP method for them to use.¹

If your authentication store is actually in another RADIUS platform, you would need to configure the authentication policy to use an external RADIUS service as your Network Access Service. This is a less common, but not an uncommon deployment.

The last piece of an ISE AuthC rule are the identity stores (presuming you’re not using a RADIUS proxy); this is where one should actually look for the credential to determine if the identity is to be validated.

These stores include the following:

• Internal endpoints

• AD

• LDAP

• Certificate authentication profile

• Identity source sequence (ISS)

Let’s look into some examples of what ISE policy most typically looks like.

Typically the foundation ISE authentication policy rule starts with MAC authentication bypass rules. In all common cases, the policy will look like this where all MAB authentications will be authenticated with the internal ISE endpoint database.²

When you go to design and deploy ISE, it’s important to keep in mind how your users/devices are going to supply credentials for authentication. This is going to guide how you design your ISE rules. For example, if you expect the majority or all of your dot1x authentications to require AD credentials, then you need to create AuthC rules to steer those dot1x authentications to look for username/password credentials in AD. This is really typical in a deployment that uses PEAP.

In some designs authentications will largely be certificate authentications and in that case the specific certificate authentication profiles become important to differentiate between both mechanisms used to issue the certificate (AD enrollment vs. Simple Certificate Enrollment Protocol (SCEP)). In that case a certificate authentication profile needs to be referenced. What’s the easiest way to do that? Making a subrule inside the dot1x authentication ruleset is often the best way.

The rule flow allows for multiple results in this case. Inside the dot1x ruleset, if the authentication method is x509, the authentication is steered toward our certificate authentication profile. If it’s not, authentication is then directed toward AD. This technique gets useful when you have to worry about multiple different authentication types and getting them to the right place at the right time.³

Let’s take a look at this in a little more detail.

When a certificate is issued via the ISE BYOD process or through another SCEP service, the Common Name (CN) of the certificate contains the username of the end user who requested the certificate. The Subject Alternative Name (SAN) and OU fields can be filled with various other pieces of useful information depending on the exact issuer. In ISE’s case the SAN is populated by the calling station ID, which is the MAC address of the device requesting the certificate. In the case of the certificate issued by ISE then, the AuthC policy should be configured such that those certificate authentications are directed to a certificate authentication profile that specifies the CN as the principal x509 username.

This is different from where the username is typically when a certificate is issued from AD enrollment/Group Policy Object (GPO). In that case, most typically the CN field is populated with the “$firstname $lastname” of the user. The SAN is then populated with the User Principal Name (UPN) which is the fully qualified directory name of the user (e.g., mmaroney@presidio-labs.local for domain presidio-labs.local). In this case, it’s important to create the AuthC policy where a certificate authentication profile specifies the SAN field as the principal x509 username.

How is this best way to set the certificate authentication profile to accomplish this differentiation you ask? Well, that’s a great question; you need to understand exactly how your certificates are deployed. In our example the UPN will be used in the SAN field for the AD certificate enrolled devices. That means each SAN will contain “presidio-labs.com.” I can then construct a rule with the “CONTAINS” operator for the contents of the certificate SAN name.

Then, any other certificates issued from other places (e.g., SCEP) would typically have the username in the CN and that can be referenced pretty reliably.

Your deployment may be wildly different than this depending on your requirements. If you prefer to identify which certificate has been issued by the CA, that’s entirely possible just by modifying the conditions. You can use a variety of mythologies to match the correct authentication methodology you’re looking to use. We’ve used regular expressions very effectively looking for the correct style of string in different certificate attributes. It’s important though to understand the contents of the certificates you’re deploying to be able to properly authenticate devices with them.

Now that we’ve hammered on certificate authentication for a while, what if you wanted to authenticate the default dot1x rule to multiple places potentially? Presuming you’re looking to authenticate usernames and passwords to multiple identify stores, the easiest way to do that is through an ISS. In the case that you may look in multiple different identity stores you can use an ISS. The ISS is literally a list of identity stores you can use to chain together.

Let’s look at a specific example; if you’re doing wireless dot1x authentication and you know that most of your users will be in AD, but you want to use some users locally configured in the ISE user identity database and you want to keep your authentication rules simple, you can have your AuthC rules reference the ISS where the dot1x authentications first look in AD, and if the user is not found, internal ISE user identities is checked second.

To configure this you’re simply creating yourself an ISS with the relevant identity sources, and giving it a reasonably intelligible name. This ISS is then referable in your identity store configuration of your authentication rule.

This configuration gives you a fair amount of flexibility. The bulk of your dot1x username/password authentications will be properly steered toward AD, but should you then need to reference users who are not in AD, you would have to add users to the internal ISE user database.⁴

As you can see, authentication policy isn’t about applying policy to live users, rather just identifying where we should figure out who they are. Now that we’ve done that, we can move on in our policy and look at what kind of access we may permit them.

---

¹ If you have LEAP enabled for a specific design reason, LEAP will be the default preferred EAP protocol. In that case, we’d recommend picking a more secure EAP method like PEAP as your preferred method so you don’t accidentally get gratuitous LEAP authentication.

² Endpoints for MAB may be stored in an LDAP database. This is not a common deployment so we’re not covering it but it could be practical for your specific environment.

³ Obviously, you’ll also have to be sure that the trusted chain of the client certificate is installed for client authentication in the trusted certificate store in ISE. Otherwise ISE will not be able to successfully trust the client certificate.

⁴ While this configuration is great as an example, if you have a really large AD to search, it may not be plausible to use local authentication second to AD in reality if the time it takes to search AD exceeds a RADIUS or EAP timeout. If you have a large AD environment in your enterprise, then you should have your ISS utilize the smaller identity source before you ask it search AD.