8.2. Identity Authentication

The policy engine is at the core of the authentication process for the NAC-based network. Authentication is a process of determining whether a user or a device (identity) is really what it claims to be:

  • Identity without authentication is like a hostess at a restaurant asking for your name to ensure a reservation.

    Maybe you can lie and get away with it (until the real party of seven shows).

  • Identity with authentication is like a police officer asking for your driver's license after a traffic violation.

    The officer and his network will verify your identity to make sure that you're who you say you are.

Many networks operate today as a network without identity, which isn't that much different than an open parking lot, where nobody checks who comes and who leaves. These networks connect the user or device to the network, and after the user or device is on the network, the enforcement point blocks access if that user or device has no credentials. Identity checks should happen a lot sooner, like putting a card-checking booth at the entrance to a parking lot.


With NAC, you can find out who the user or device is before you attach that user or device to the network.

8.2.1. Collecting identity

Although different NAC vendors support different methods of collecting identity, the typical first step in validating identity for access control is to collect the identity's credentials.

Your method of collecting those credentials must recognize whether the identity belongs to a user (human) or a device (non-human) for some very obvious reasons:

  • Users have jobs to do (and feelings, too). They don't like being authenticated dozens of times during the day.

  • Devices don't care how many times you authenticate them.

Although you can use several methods to collect user identity for NAC policy decisions, how credentials are collected can determine what the user experience is like when a user connects to the network (and the quality of the user experience is directly related to the number of complaints that come to your attention).

NAC gives you another level of authentication, on top of what users have to go through today. For example, a user might need only to plug into your current network to connect. With a typical NAC deployment, a user logs in to the network. After the network connection is complete, the user has to log in to Windows before he or she can start working. Users can start complaining pretty quickly because they don't like to have to log in twice before they can start their work.

NOTE

Here's the generic process for most NAC authentications:

  1. The user plugs his or her computer into the network.

  2. The network detects the computer.

  3. The network asks the agent on the computer for credentials.

  4. The agent pops up a dialog box in which the user types his or her credentials.

  5. The agent sends the user credentials across the network to the policy engine.

  6. The policy engine verifies the user credentials against a backend authentication system (such as Microsoft Active Directory, LDAP, and so on).

  7. The policy engine creates an access policy for that computer.

  8. The policy engine allows the computer and the user on the network.

The key steps in this whole flow for user authentication are how the credentials are collected (Step 4) and what they're verified against (Step 6). Without a verified source to validate them against, you can't validate with user identity.

Essentially, the success of the user experience hinges on how the endpoint agent collects the identity. Some technologies can solve the sticky problems and make the user experience more seamless.

8.2.1.1. Web portal

A Web portal is the simplest form of identity collection, similar to a Web page to which you have to submit a user name and password.

For example, in your hotel room, you plug into the network and open a Web browser, and then the hotel asks you for your credit card number or your room number. This user experience is a captive portal, also called the hotel-room experience. In a NAC deployment, you plug your computer into the network and get an address that you can enter to access a Web page. After you log on by using your Web browser, the NAC solution sees that you aren't authenticated and redirects your browser to a login page, where you have to submit your credentials.

Using a Web portal for authentication has some benefits:


  • It's the most cross-platform–friendly method of collecting credentials because it uses a Web browser.

  • You don't need to have any endpoint software running on the endpoint.

Web portals have a couple of limitations:

  • You have to open a Web browser to be able to log in. If the user opens an application such as Microsoft Outlook first, that user doesn't see a login page and can't connect.

  • Network or enforcement point needs to give the endpoint and IP address on the network before the user is authenticated. The network needs to give some sort of limited access initially, and after authentication, the access for that user changes.

Web-portal–based authentication is suited for many use cases and is often used in conjunction with some other form of credential collection. For example, a deployment might use

  • Agent-based collection for all managed corporate endpoints

  • Web-portal authentication for any guest users who connect to the network

8.2.1.2. Agent-based

An agent is a software program that performs a set of tasks. In NAC policy, the agent is a piece of software that runs on the endpoint trying to connect to the network.

NOTE

You can find two different types of agents: persistent and non-persistent. This section covers only the persistent endpoint agent that's installed on the connecting endpoint. Most NAC agents are designed to be persistent and start up with the computer when the OS loads. Agents give the NAC the most interaction with the connecting endpoint, and they allow agents to collect the connecting user's credentials in many different fashions.

The most popular agent-based methods of collecting credentials are

  • Dialog box: During the process of authentication, the agent displays a dialog box to the user (sort of like a pop-up window) and asks for that user's user name and password.

  • Saved credentials: The user has provided his or her credentials to the agent, and the agent is reusing those credentials.

    NOTE

    Using saved credentials isn't the most secure method. If someone steals a user's machine, the thief wouldn't need to enter credentials to get directly on the network.

  • Windows GINA (Graphical Identification and Authentication): This method uses a GINA plug-in that has the ability to collect credentials and log in the user to the network as a part of the Windows login process:

    1. When the Windows' login screen appears, GINA steps in, starting all the network connections and logging in the user to the network.

    2. After GINA completes its login process, the Windows authentication starts.

    GINA gives a very seamless way to tie NAC to a Windows login.


  • Certificates: The agent can collect a user certificate that was issued to the user who's logging in. The agent can use a certificate in conjunction with other credentials or a PIN that's configured for the certificate.

  • Smart cards: Similar to certificates, except that the certificate is contained on a card that the user needs to put in a card reader.

  • Kerberos tickets: Kerberos tickets allow agents to interact with the operating system so that they can piggy-back on available authentication sources. In a Windows environment, the agent can use the Kerberos ticket of the user to authenticate and get on the network.

NOTE

The agent approach does have a downside — it's platform dependant. The access control vendor needs to write an individual agent for each platform that you might support, such as Windows, Macintosh, and Linux. The agent approach is the most popular because most of the devices connecting to the network are managed PCs that can have the agent preconfigured and installed before the endpoint tries to connect to the network.

8.2.1.3. Single Sign-On

When you want a clean user experience, Single Sign-On (SSO) can help clean things up a bit. In a typical login scenario, a user hits Ctrl+Alt+Del, which causes the windows login screen to appear, which the user uses to log into Windows. Most NAC agents start only after the user logs in to Windows. So, the agent asks for a user name and password immediately after the user types them into the Windows login screen. Single Sign-On helps alleviate this problem.

NOTE

With Single Sign-On, double logins are a thing of the past. In a Windows Active Directory environment, a PC that's logged into the domain gets a Kerberos ticket as the result of a successful authentication. In some NAC solutions, the agent can take the Kerberos ticket and send it to the policy engine for verification, instead of asking the user for a user name and password again. The Kerberos ticket shows that a user has already submitted his or her credentials correctly. The policy engine then takes the Kerberos ticket and validates against Microsoft Active Directory. If the ticket is valid, the user successfully logs in to the network. The user isn't aware of this validation process — he or she sees only that the agent starts up and successfully logs in.

When you deploy your NAC solution, you probably use a blended solution that's made up of several types of authentication collection because each type serves a particular purpose.


8.2.2. Transporting credentials

Access control solutions communicate credentials between the agent and policy engine, or the endpoint and the policy engine, in some common ways.

If possible, look for an access control solution that leverages open standards for the communication process. (See Chapter 12 for more information on open standards.)


Several possible transports for authentication information exist. The transports discussed in the following sections are the most common.

8.2.2.1. 802.1X

802.1X allows an access control solution to communicate the user credentials at a Layer 2 level before an endpoint is connected to the network. This method offers a benefit because you can authenticate a user before his or her machine is ever connected to your network, and it gets an IP address.

Pop authentication collection quiz

Start thinking about your network access control's user experience early because it can help determine how you want to collect credentials and shape the deployment by dictating the types of authentication that you can leverage.

Ask yourself these questions:

  • What do you want the login to be like? Do you want it to request credentials many different times?

  • What's the maximum number of times you want a user to have to provide his or her credentials?

  • Do you want the login to be interactive, or would you rather the user to be logged in without any interaction?

  • Do you want to use two-factor authentication for additional security?

  • Do you want guest-access users to provide credentials?

Answering these questions early in the process helps to identify any possible issues you might encounter. The user experience may seem like a simple detail, but it can make or break your deployment, especially when users can't authenticate correctly or figure out how to log in to the network.


NOTE

802.1X transport happens across a secure tunnel that policy engine sets up between the endpoint and the policy engine. The standards-based tunnel receives two different manners (as we talk about in Chapter 4 and 802.1X authentication). Here's how the 802.1X works:

  1. The user plugs a PC into the network.

  2. A switch that's configured for 802.1X asks for credentials at Layer 2.

  3. The agent (also known as a supplicant) sends the credentials in an EAPoL (EAP over LAN) frame.

  4. The switch takes the EAP payload containing the user credentials and repackages the payload in an EAP over RADIUS packet. The switch then sends the EAP over RADIUS packet to the policy engine.

  5. The policy engine pulls the EAP message out of RADIUS to validate the user credentials.

NOTE

Authentication is made up of several authenticating-data trips back and forth to and from policy engine. The simplest way to think of 802.1X is as a secure tunnel that runs from the endpoint that contains the agent to the policy engine. The switch, or access point in the middle, is a dumb device that passes messages between the endpoint and the policy engine.

One of the biggest benefits of 802.1X is that it gives access control the ability to communicate with a connecting endpoint before that endpoint has an IP address on the network.

The biggest drawback is that you have to have an agent (supplicant) installed on the endpoint for that endpoint to be able to communicate with the policy engine. If the user's machine doesn't have an agent, the user can't pass the credentials to switch or access point.


8.2.2.2. Secure Sockets Layer (SSL)

SSL is a proven method of transmitting information securely across networks.

When you log in to your bank's ATM machine, your information is transmitted across a secure tunnel and verified.


You can use SSL to transmit credentials in several places, such as

  • Using a Web portal (or hotel-room experience): Typically done across SSL so that the credentials are protected when they're submitted

  • Communicating user credentials across SSL to the policy engine: Typically not visible to the user because it happens when the agent is connecting to the network

You most often use SSL for a guest-access scenario that has no agent, so you want to leverage the Web browser as the agent for the endpoint.

The biggest drawback to relying on SSL for transmitting credentials is that the endpoint has to have an IP address on the network before the browser can establish an SSL connection with the policy engine.

8.2.2.3. Extensible Authentication Protocol (EAP)

EAP is a flexible framework for authentication used most often as an 802.1X-type access control deployment.

NOTE

You can use EAP to pass credentials from the endpoint to the policy engine in additional ways that we don't cover in this book, but you can find them available from various vendors if you need to implement them.

You can pass credentials between the endpoint and the policy engine in several ways that we don't talk about in this book. Just like any technology, some access control solutions use proprietary protocols to communicate credentials. Use solutions that leverage standards, not proprietary solutions, if you can because you may need to tie your deployment into another solution tomorrow — say, when you merge with another company or office. But, then again, your network needs might be so unique that they require a proprietary solution. Think twice before you act.

8.2.3. Identity validation

Although the policy engine decides whether a user should have access to the network, it doesn't do the validation on its own. The validation is typically a coordinated effort between the policy engine and the authentication server on your network.

After credentials are collected on the endpoint and sent across the network, the policy engine uses those credentials to validate the user against the authentication server.

The policy engine has an important job that dictates whether endpoints can connect to your network, but it doesn't act alone in this process — it has an accomplice. Most of the time, when the policy engine receives the credentials, it validates them against an external authentication source, such as Active Directory, which sends a pass or fail back to the engine. If the credentials are valid, policy engine may also get back group info that it can combine with the policy engine policies to create complex NAC rules (for example, the user is validated, but only to this group and not on weekends or evenings).

Most policy engines can tie back to your existing authentication servers. Some of the existing authentication sources that you can use include


  • Lightweight Directory Access Protocol (LDAP): LDAP gets wide use. It accepts authentication requests and also returns group information when users are classified into different groups:

    1. The policy engine receives the credentials and verifies them against LDAP.

    2. If the credentials are valid, the policy engine uses the group membership information from LDAP to map users to different access control roles.

  • Microsoft Active Directory: Enterprise networks often use this authentication server because it accepts authentication requests and returns group information. Active Directory has three different interfaces:

    • LDAP: Allows you to use Active Directory as an LDAP server

    • NTLM: An authentication protocol by Microsoft

    • Kerberos: Ticket based authentication system

    Most companies have at least Microsoft Active Directory or LDAP already installed in their networks, so Microsoft Active Directory and LDAP are the most popular validation choices for tying access control together.


  • Remote Authentication Dial-In User Service (RADIUS): For user-based authentication. It has only a limited ability to map users to access control policies in the policy engine.

  • Kerberos: Based on a key distribution system, which uses a third-party key server to validate and create secure communication of credentials.

    NOTE

    One of the most common uses of Kerberos is authentication of users against Microsoft Active Directory, which implements Kerberos-based Single Sign-On. The policy engine verifies the Kerberos ticket that's collected from the endpoint against the domain controller. Kerberos allows both authentication and group membership lookups.

  • Two-factor authentication: Used to prevent passwords from being compromised. Two-factor authentication requires both

    • A password

    • A device that has a unique code

    The combination of something that you know (the password) and something that you have (the code from the device) allows you to authenticate to the network.

    If you use two-factor authentication in your company already, you should be able to leverage that deployment for your access control deployment.


  • Certificates: Allow you to authenticate a device or a user based on certificates that the certificate server has issued. You typically use certificates in conjunction with technologies such as smart cards:

    1. The user puts the smart card in his or her device, making the certificate available for authentication.

    2. The policy engine checks whether the certificate is valid and not revoked.

    3. If the certificate is valid, the policy engine then allows access.

    You can do group membership validation in conjunction with something such as LDAP, based on an attribute in the certificate.

NOTE

Whatever access control solution you evaluate should allow you to use multiple authentication servers. You don't need to build something new to make a NAC solution successful. You should leverage your existing authentication infrastructure for network access control. For example, you may already have authentication servers, and you may need to use more than one type of server.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.128.198.60