CCNP Security SISAS 300-208 Official Cert Guide (2015)

---

1. What are two types of identities used in Cisco Identity Service Engine?

a. SSID

b. MAC address

c. Username

d. IP address

2. What are the two general types of identity stores used by Cisco ISE?

a. Temporary

b. External

c. Internal

d. Permanent

3. Cisco ISE internal identity stores are used to authentication which two of the following?

a. Endpoints

b. AD security groups

c. RADIUS

d. Users

4. Which identity store attributes can be used in an ISE authorization policy? (Choose two.)

a. User

b. Time

c. Accounting

d. Machine

5. What is an individual identity store called?

a. Authentication source

b. Identity database

c. Identity source

d. Authentication database

6. How is an identity source sequence processed?

a. Bottom to top

b. Left to right

c. Top to bottom

d. No particular order

7. Which of the following identity stores are supported by ISE for authentication? (Choose three.)

a. LDAP

b. TACACS

c. Microsoft Active Directory

d. RADIUS servers

8. Which of the following can be used with an internal identity store?

a. SSID

b. Guest login

c. Administration

d. MAB

9. What are the two types of internal identity stores used in ISE?

a. User database

b. Endpoint database

c. System database

d. Admin database

10. What are the two primary reasons for using external identity stores?

a. Performance

b. Monitoring

c. Scalability

d. Management

Foundation Topics

What Is an Identity?

According to the Oxford English dictionary, an identity is “serving to establish who the holder, owner, or wearer is by bearing their name and often other details such as a signature or photograph.”

Someone could walk up to you and say that her name is “Tammy,” but how would you know that identity is true? You would need some type of “trusted” evidence such as a third-party form of identification—say, a driver’s license or passport—to verify her credentials.

One of the first and foremost uses of identity in the world of secure network access control is the identity of a person or device. Typically, many factors can make up an identity, including an employee’s username and password that would be used to access corporate network resources. Another form of identity could be the use of media access control (MAC) address to uniquely identify a specific endpoint such as a network-based printer.

Identity Stores

An identity store is basically a database that can be used to authenticate a user’s or an endpoint’s credentials. The identity store could be an internal database that resides on the Authenticaton Authorization and Accounting (AAA) server or even external database(s) housing the identities.

Identity stores can also be used for the retrieval of user or machine attributes used in authorization policies, which are covered in more detail in Chapter 11, “Authorization Policies.”

Each individual identity store is also referred to as an identity source. You can combine multiple identity sources into an identity source sequence that can then be processed for user and endpoint authentications and authorizations. The identity source sequence will then process the identity stores in the order they are defined from top-to-bottom succession. See Figure 3-1 for an example of an ISE identity source sequence configuration.

Figure 3-1 ISE identity source sequence configuration.

Both the Cisco Identity Services Engine and the Cisco Secure Access Control Server are capable of using identity sources inclusive of an internal identity database(s) as well as external identity databases. External identity sources include Microsoft Active Directory (AD), Lightweight Directory Access Protocol (LDAP), one-time password (OTP) servers, smart cards, and certificate authorities (CAs).

Internal Identity Stores

Cisco ISE has an internal user database that can be used for internal username and password accounts. These user accounts stored in the internal user database are referred to as internal users. The internal user database can be used as an internal identity store for local authentication and authorization policies.

One example for use of this internal identity store would be to authenticate and authorize a sponsored ISE guest accounts to access your corporation’s guest wireless network. Cisco ISE maintains a separate guest identity store. Another example is the internal identity source for administrative accounts, which is another separate identity store.

A third example would be to create internal username accounts that could be used as sponsor accounts for the creation of ISE guest accounts. See Figure 3-2 for an example of an ISE internal user account configuration.

Figure 3-2 ISE internal user account configuration.

Any internal user accounts configured then are associated with a defined user identity group that sets the type of internal account being created. Several preconfigured user identity groups can be used when creating internal user accounts, including the following: Guest, Activated Guest, Employee, SponsorAllAccount, SponsorGroupAccounts, and SponsorOwnAccounts. See Figure 3-3 for an example of ISE user identity group options.

Figure 3-3 ISE user identity groups.

If you are using internal user account, make sure that the internal user’s identity store is part of the identity source sequence. The identity source sequence can then be used in the ISE authentication and authorization policies.

The second type of internal identity store used in both Cisco ISE and Cisco ACS is called the internal endpoint database. It is used to store information about all endpoint devices that connect to the ISE infrastructure. See Figure 3-4 for an example of the ISE internal endpoint database.

Figure 3-4 ISE internal endpoint database.

External Identity Stores

External identity stores are used to integrate your Cisco ISE deployment with your company’s existing authentication infrastructure. By using the company’s existing external authentication database, you can eliminate duplication of account creation and management. Because user and machine accounts are created, modified, or deleted in the external identity store, you do not have to worry about that process being duplicated for the Cisco ISE deployment. External identity stores allow for better scalability and management for ISE authentication and authorization processes.

The Cisco ISE deployment will connect to the external identity source to verify username and password credentials for authentication policies. Certificate information can also be retrieved from the external identity store. Cisco ISE uses authentication protocols to secure communications with the external identity stores. These authentication protocols are discussed more in depth in Chapter 4, “EAP over LAN (also Known as 802.1X).”

Examples of external identity stores include certificate authentication profiles, Active Directory, LDAP, RADIUS Token, and RSA SecureID. See Figure 3-5 for an example of external identity stores available for configuration in ISE.

Figure 3-5 External identity stores.

Active Directory

One of the most popular external identity store supported with Cisco ISE is the integration with Microsoft Active Directory for user and machine authentication and authorization. Additional support includes authorization using AD security group membership and various other AD attributes.

Cisco ISE supports Active Directory natively by joining the Microsoft Active Directory domain. Support for multiple AD domains can be also supported by leveraging the use of two-way trust relationships between the domains.

Cisco ISE 1.2 supports AD integration as an external identity store using Microsoft Active Directory Servers 2003, 2008, 2008 R2, and 2012. Microsoft Active Directory Server 2000 is not support by Cisco ISE 1.2. See Figure 3-6 for an example of ISE Active Directory identity source configuration.

Figure 3-6 ISE Active Directory identity source configuration.

LDAP

The Lightweight Directory Access Protocol (LDAP) uses TCP/IP networking protocol as defined by RFC 2251. LDAP uses a client model to connect and retrieve information from X.500 directory service databases using TCP port 389. See Figure 3-7 for an example of LDAP identity source configuration.

Figure 3-7 ISE LDAP identity source configuration.

Using LDAP as an external identity store can be supported for user authentication for Cisco ISE deployments. The username and passwords are sent in the clear by default when using LDAP. To prevent clear-text credentials from going across the wire, it is highly recommended to secure the LDAP communications using Secure Sockets Layer (SSL). LDAP over TLS/SSL uses TCP port 636.

LDAP also supports the retrieval of group membership information that can be used in the Cisco ISE authentication and authorization policies.

The LDAP external identity store supports configuring both a primary and secondary IP address for failover redundancy. You can also configure more than one Cisco ISE external identity store to connect to multiple LDAP X.500 database instances if needed.

The LDAP protocol is used in a variety of today’s Enterprise Identity Management (IDM) solutions, including Active Directory, Sun Directory Server, Novell eDirectory (formerly Novell Network Directory Services [NDS]), Oracle Identity Manager, and IBM Tivoli Identity Manager (TIM) to name a few.

Two-Factor Authentication

In secure enterprise networks, typical user identities are based on a username and some type of static password that hopefully has a required security policy of changing the user’s password every 30, 60, or even 90 days.

One of the main disadvantages of using usernames with static passwords is that the credentials could be packet captured and then later used for a replay attack to break into the company’s networks.

When dealing with sensitive data access or remote access, security administrators might want the password used to access the corporate network or virtual private network (VPN) systems to include more security by requiring two forms of identity.

This process is known as two-factor authentication.

A typical example of using two-factor authentication system is when you go to your bank’s ATM system to withdraw money from your checking or savings account. To make the withdrawal, you need two separate items.

The first item is the actual ATM debit/credit card issued by your bank. This is known as the something “you have.”

The second item that is required is the actual personal identification number (PIN) that you selected when you set up your bank account. This is known as the something “you know.” Your account PIN is typically a four-digit number to maintain your secure access to your account.

If someone were to have your PIN but not your actual debit/credit card, he would not be able to process an ATM withdrawal from your account.

So the two factors for authenticating the user identity that will come into play are the required something “you have” and the separate required something “you know.”

One-Time Password Services

Another version of two-factor authentication is called one-time password (OTP) services. You are still required to “have something” and to “know something.”

In this case, the “have something” comes in the form of a hard or soft token card.

Hard tokens typically come in various forms, including credit card, USB token key, or key FOB to name a few. Soft tokens, also known as virtual tokens, serve the same role as a hard token but run as software on your computer instead of you having to carry around a separate physical token card. See Figure 3-8 for an example of various hard tokens types.

Figure 3-8 Hard token types.

There are two main advantages of using a soft token over hard token cards. The first benefit is the extra cost that is associated with having to have an actual hard token card per each user. The second advantage to using a soft token is you do not have to worry about misplacing or losing the hard token card itself anymore.

OTP systems are based on algorithms that make use of pseudo randomness to generate unique security tokens. Two possible types of algorithms are usually used by OTP systems to generate these unique tokens. The first algorithm uses a time synchronization algorithm and the second method uses a mathematical algorithm.

The time synchronization method is used to guarantee the uniqueness of the one-time password. The typical hard token device (credit card, key FOB, or USB token) maintains an accurate clock that is in sync with the OTP authentication server. The time synchronization is critical to maintain the expected next unique token (password) between the end user’s hard token and the OTP authentication system. Typically, there is a +1 to -1 ratio of acceptable passwords. This means that the authentication system will accept the last generated password, the current password, and the next password in sequence. This helps account for a minor drift in time synchronization between the token card and the token authentication server.

The mathematical algorithm uses the previous OTP to generate the next OTP or by using a challenge (also called a PIN) that must be entered to generate the next OTP. The second method is what you typically see when using a soft token (virtual token) system. The software is run, and then the user is prompted for her secret challenge phrase/PIN. Upon successful input of the secure PIN, the soft token software program generates a unique OTP for the user to enter as her password with her network user ID.

The OTP that is generated is valid for one user login session only. By requiring users to use OTPs for logging in to either enterprise secure systems or remote VPN networks, you are enforcing a security policy that requires a unique password for each unique user login. The primary advantage of using OTP systems is that they are not subject to the replay attacks we discussed in the previous section for typical network username/password login systems.

You must also still have the “know something,” which in this case is the PIN associated with the hard token card or soft token software. The key difference when using an OTP system is that your PIN is actually used as input to the token software to generate an unique OTP that will then be entered as your password with your username to access your company’s secure networks or remote VPN networks.

RSA SecurID and SafeWord are just two examples of OTP systems that can be implemented with Cisco ISE.

Smart Cards

Another type of identity store supported by Cisco ISE is with the use of smart cards. Smart cards use embedded integrated circuits that then can be used as forms of identification. That identification can be used as a method authentication for secure network access control systems.

Common access card (CAC) is another term used to refer to smart cards that allow users to use their identification badges to authenticate. The end user inserts his CAC into a card reader and then enters his PIN. Again, you have to “have something” and “know something” for the authentication to be valid.

Smart cards store a set of X.509 certificates that use a public key infrastructure (PKI) to store the encrypted digital certificates required for the authentication process.

Today’s smart cards are used in variety of formats including bank credit cards, drivers’ licenses, and hospital patient identity cards to name a few examples.

Certificate Authorities

In general terms, a certificate is an electronic document designed to identify an “entity” (for example, a device, a user, or a website) and uses a digital signature to validate the document. These identity documents are used within a standard known as X.509, which is a standard for PKI. The X.509 standard specifies the format for public key certificates, certificate authority hierarchy, revocation checking, and much more.

To help understand the topic of certificates, it is often easiest to relate it to something most of us are familiar with, which is your driver’s license. When you take your driver’s exam and pass the test, you are provided your driver’s license documentation. This document is “signed” by a recognized and trusted authority, such as a state agency known as the Department of Motor Vehicles (DMV). The authority that issues your driver’s license will use various methods to sign that license to indicate it came from a trusted source and is valid and trusted. One example that is typically used is a hologram embedded on the driver’s license, which makes it difficult to duplicate or forge.

An X.509 certificate is very much like a driver’s license. It is used to identify the user, device, application, or whatever that entity might be. The certificate authority (CA) vouches for the identity contained in the X.509 certificate by “signing” the X.509 information.

The comparison between X.509 certificates and driver’s licenses does not end here.

What happens when a police officer stops a speeding driver?

The driver is asked to provide his driver’s license, which the police officer will then use to perform the following tasks:

1. Validate that the driver’s license appears to be a real document and not a forgery.

2. Ensure the picture does in fact look like the person in the driver’s seat.

3. Ensure that the driver’s license is still valid and not expired.

4. The police officer will then verify via computer query that the driver’s license has not been suspended or revoked based on past offenses.

X.509 certificates work in a similar fashion. Think of an authentication server, such as Cisco ISE, as the police officer. When the authentication server is presented with an identity certificate, it performs the following tasks (at a minimum):

1. Has the digital certificate been issued and properly signed by a known and trusted certificate authority?

2. Is the certificate expired? (Must check both the issue and expiration dates!)

3. Has the certificate been revoked by the certificate authority?

4. Has the client provided proof of possession?

Has the Digital Certificate Been Signed by a Trusted CA?

As mentioned previously, a CA vouches for the identity that’s contained within the certificate. The owner of the certificate (the client) and the access device (the server) must both mutually trust the CA. When an identity certificate is presented, you must be able to trust the signing authority. Without the established trust first, the authentication server has no way to validate the identity certificate being presented.

The signing of a certificate really has two requirements. The first requirement is that the certificate must be presented in the proper format as based on the X.509 standards. If the certificate is not formatted properly, the authentication server will discard the identity certificate being presented and the authentication process will then be immediately terminated.

The second requirement is that the trusted signing certificate authority’s public key must be stored in the Trusted Certificates database of the authentication server and that certificate must be trusted for purposes of authentication processes.

Using Cisco ISE as an example, the trusted certificate will need to have the Trust for Client Authentication use case selected, as shown in Figure 3-9.

Figure 3-9 Trust for Client Authentication.

So not only does Cisco ISE “trust” the certificates that have been signed by the certificate authority, but it also must trust those certificates for the specific required use case, such as client authentication in this example. If a client presents a certificate and the chosen CA did not authorize the certificate for client authentication, the authentication immediately fails. This authentication process is comparable to someone entering the wrong password for a user account—or, better yet, a user attempting to use a movie ticket for the wrong movie.

Has the Certificate Expired?

Just like a driver’s license or a passport that has an issued date and an expiration date, a certificate has validity dates. The certificate list the Issued On date, which is the starting date that the certificate is first valid. It also has an Expires On date, which is the date on which the certificate will be no longer valid. Figure 3-10 illustrates the valid-from and valid-to attributes within a certificate.

Figure 3-10 Certificate validity.

After the certificate has expired, it will have to be renewed with the trusted certificate authority. An authentication server will examine these dates to ensure the identity certificate is valid for the date and time that the authentication request is processed.

When working with certificates it is critical to synchronize your network infrastructure, including your CA, when creating new certificates along with your authentication servers when processing certificates used for authentication. The best practice is to use the Network Time Protocol (NTP) (UDP port 123) to a trusted and authenticated network time server. This NTP server acts as a centralized timekeeper for the network.

Many of the issues involved with creating, implementing, and processing certificates concern time being out of sync. A typical example is when the certificate Issued On date and time stamp is not valid yet. The certificate might be presented for authentication on September 9, 2014, at 10:13 a.m., but its Issued On value in the certificate itself is listed as starting on September 10, 2014, at 5:13 p.m.

Characteristically this is because the certificate authority was NOT in sync when the certificate was originally generated.

Has the Certificate Been Revoked?

Now if we go back to the police officer analogy that was described earlier, remember that the officer can look at your driver’s license and verify whether the expiration date is still valid. The question still remains: How does the police officer know if your driver’s license has been revoked?

To verify that your driver’s license is not revoked, the police officer will have to perform additional checks of your driver’s license number against the DMV’s database. If the police officer runs your driver’s license number and finds out that you have many speeding tickets and in fact your driver’s license has been revoked, you would be immediately arrested for driving on a revoked license.

When presented with a certificate for authentication, the authentication server has the same capability to verify that the trusted certificate authority has not revoked the identity certificate. Every CA should also have a service to publish a list of certificates that have been revoked. There are two primary ways to check for certificates that have been revoked: a certificate revocation list (CRL) and the Online Certificate Status Protocol (OCSP). These are discussed next.

Certificate Revocation List

This is basically a signed list of the revoked certificate serial numbers that the CA publishes on a website that can be read by any device or application needing to confirm a certificate’s validity. This file is periodically downloaded and stored locally on the authentication server. When a certificate is then presented for authentication, the authentication server examines the CRL to see whether the client’s certificate serial number is on the list indicating that the certificate has been revoked.

The use of CRL option does lead to some security concerns that you need to be aware of.

How often does the CA update the CRL? If the CRL is updated only once a week, then there is still the possibility that the CRL will be outdated if presented with a recently revoked certificate. For instance, if the CRL was just cached yesterday at noon on the authentication server with a caching time of one week, then the certificate that is revoked as of yesterday at 12:01 p.m. can still be used until next week when the CRL would be scheduled for the next update.

How often does the authentication server download the CRL from the CA? Again, if the CRL is not updated locally on the authentication server, then the list of certificate serial numbers that are revoked could be stale.

To deal with these security concerns, let’s take a look at how OCSP works as compared to the CRL method.

Online Certificate Status Protocol

This is the preferred method for revocation checks in most environments today because it provides near real-time updates. OCSP allows the authentication server to send a real-time request that is similar to an HTTP web request to the service running on the CA or another device and checking the status of the certificate right then and there. OCSP could be compared to the police officer using the computer in her squad car and doing a live lookup on the DMV’s database.

If the certificate has been revoked, then access is denied.

Figure 3-11 is an example of the configuration screen for a CA in ISE. The administrator has the ability to configure a location to check for OCSP and/or CRL when this particular CA signs a certificate or its subordinates.

Figure 3-11 Certificate CRL and OSCP configuration.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here; Chapter 23, “Final Preparation”; and the exam simulation questions on the CD-ROM.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 3-2 lists a reference of these key topics and the page numbers on which each is found.

Table 3-2 Key Topics for Chapter 3

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

identity store

identity source

identity source sequence

internal user database

user identity group

internal endpoint database

external identity store

Active Directory (AD)

Lightweight Directory Access Protocol (LDAP)

Remote Authentication Dial-in User Service (RADIUS)

certificate authentication profile (CAP)

two-factor authentication

one-time password (OTP)

common access card (CAC)

public key infrastructure (PKI)

certificate authority (CA)

registration authority (RA)

Network Time Protocol (NTP)

certificate revocation list (CRL)

Online Certificate Status Protocol (OCSP)