CHAPTER 19

Identity and Access Services

In this chapter, you will

•  Learn how to install and configure identity and access services

•  Understand how to compare and contrast the different identity and access services

To use a system, one must identify themselves with the system in some form or fashion. This chapter examines the identity and access services employed by systems to determine whether a user gets access or not. Identity and access services are comprised of hardware, software, and protocol elements that work together to manage the identity and access functions across the enterprise.

Certification Objective   This chapter covers CompTIA Security+ exam objective 4.2, Given a scenario, install and configure identity and access services.

Objective 4.2 is a good candidate for performance-based questions, which means you should expect questions in which you must apply your knowledge of the topic to a scenario. The best answer to a question will depend upon specific details in the scenario preceding the question, not just the question. The questions may also involve tasks other than just picking the best answer from a list. Instead, you may be instructed to order things on a diagram, put options in rank order, match two columns of items, or perform a similar task.

LDAP

A directory is a data storage mechanism similar to a database, but it has several distinct differences designed to provide efficient data-retrieval services compared to standard database mechanisms. A directory is designed and optimized for reading data, offering very fast search and retrieval operations. The types of information stored in a directory tend to be descriptive attribute data. A directory offers a static view of data that can be changed without a complex update transaction. The data is hierarchically described in a treelike structure, and a network interface for reading is typical. Common uses of directories include e-mail address lists, domain server data, and resource maps of network resources. The Lightweight Directory Access Protocol (LDAP) is commonly used to handle user authentication and authorization and to control access to Active Directory objects.

To enable interoperability, the X.500 standard was created as a standard for directory services. The primary method for accessing an X.500 directory is through the Directory Access Protocol (DAP), a heavyweight protocol that is difficult to implement completely, especially on PCs and more constrained platforms. This led to LDAP, which contains the most commonly used functionality. LDAP can interface with X.500 services and, most importantly, can be used over TCP with significantly less computing resources than a full X.500 implementation. LDAP offers all of the functionality most directories need and is easier and more economical to implement, hence LDAP has become the Internet standard for directory services. LDAP standards are governed by two separate entities depending upon use: the International Telecommunication Union (ITU) governs the X.500 standard, and LDAP is governed for Internet use by the Internet Engineering Task Force (IETF). Many RFCs apply to LDAP functionality, but some of the most important are RFCs 4510 through 4519.

EXAM TIP    A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS (LDAP over SSL).

Kerberos

Developed as part of MIT’s project Athena, Kerberos is a network authentication protocol designed for a client/server environment. The current release at the time of writing is Kerberos Version 5 release 1.15.2 and is supported by all major operating systems. Kerberos securely passes a symmetric key over an insecure network using the Needham-Schroeder symmetric key protocol. Kerberos is built around the idea of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an authentication server (AS) and a ticket-granting server (TGS). Kerberos communicates via “tickets” that serve to prove the identity of users.

Taking its name from the three-headed dog of Greek mythology, Kerberos is designed to work across the Internet, an inherently insecure environment. Kerberos uses strong encryption so that a client can prove its identity to a server and the server can in turn authenticate itself to the client. A complete Kerberos environment is referred to as a Kerberos realm. The Kerberos server contains user IDs and hashed passwords for all users that will have authorizations to realm services. The Kerberos server also has shared secret keys with every server to which it will grant access tickets.

The basis for authentication in a Kerberos environment is the ticket. Tickets are used in a two-step process with the client. The first ticket is a ticket-granting ticket (TGT) issued by the AS to a requesting client. The client can then present this ticket to the Kerberos server with a request for a ticket to access a specific server. This client-to-server ticket is used to gain access to a server’s service in the realm. Since the entire session can be encrypted, this will eliminate the inherently insecure transmission of items such as a password that can be intercepted on the network. Tickets are time-stamped and have a lifetime, so attempting to reuse a ticket will not be successful.

The steps involved in Kerberos authentication are

1. The user presents credentials and requests a ticket from the Key Distribution Server (KDS).

2. The KDS verifies credentials and issues a TGT.

3. The user presents a TGT and request for service to the KDS.

4. The KDS verifies authorization and issues a client-to-server ticket.

5. The user presents a request and a client-to-server ticket to the desired service.

6. If the client-to-server ticket is valid, service is granted to the client.

To illustrate how the Kerberos authentication service works, think about the common driver’s license. You have received a license that you can present to other entities to prove you are who you claim to be. Because other entities trust the state in which the license was issued, they will accept your license as proof of your identity. The state in which the license was issued is analogous to the Kerberos authentication service realm, and the license acts as a client-to-server ticket. It is the trusted entity both sides rely on to provide valid identifications. This analogy is not perfect, because we all probably have heard of individuals who obtained a phony driver’s license, but it serves to illustrate the basic idea behind Kerberos.

EXAM TIP    Kerberos is a third-party authentication service that uses a series of tickets as tokens for authenticating users. The steps involved are protected using strong cryptography.

TACACS+

The Terminal Access Controller Access Control System+ (TACACS+) protocol is the current generation of the TACACS family. TACACS+ has extended attribute control and accounting processes.

One of the fundamental design aspects is the separation of authentication, authorization, and accounting in this protocol. Although there is a straightforward lineage of these protocols from the original TACACS, TACACS+ is a major revision and is not backward compatible with previous versions of the protocol series.

TACACS+ uses TCP as its transport protocol, typically operating over TCP port 49. This port is used for the login process. Both UDP and TCP port 49 are reserved for the TACACS+ login host protocol.

TACACS+ is a client/server protocol, with the client typically being a network access server (NAS) and the server being a daemon process on a UNIX, Linux, or Windows server. This is important to note, for if the user’s machine (usually a PC) is not the client (usually a NAS), then communications between the PC and NAS are typically not encrypted and are passed in the clear. Communications between a TACACS+ client and TACACS+ server are encrypted using a shared secret that is manually configured into each entity and is not shared over a connection. Hence, communications between a TACACS+ client (typically a NAS) and a TACACS+ server are secure, but the communications between a user (typically a PC) and the TACACS+ client are subject to compromise.

TACACS+ Authentication

TACACS+ allows for arbitrary length and content in the authentication exchange sequence, enabling many different authentication mechanisms to be used with TACACS+ clients. Authentication is optional and is determined as a site-configurable option. When authentication is used, common forms include Point-to-Point Protocol (PPP) authentication with either Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), or Extensible Authentication Protocol (EAP), token cards, and Kerberos. The authentication process is performed using three different packet types: START, CONTINUE, and REPLY. START and CONTINUE packets originate from the client and are directed to the TACACS+ server. The REPLY packet is used to communicate from the TACACS+ server to the client.

The authentication process is illustrated in Figure 19-1, and it begins with a START message from the client to the server. This message may be in response to an initiation from a PC connected to the TACACS+ client. The START message describes the type of authentication being requested (simple plaintext password, PAP, CHAP, and so on). This START message may also contain additional authentication data, such as username and password. A START message is also sent as a response to a restart request from the server in a REPLY message. A START message always has its sequence number set to 1.

Figure 19-1   TACACS+ communication sequence

When a TACACS+ server receives a START message, it sends a REPLY message. This REPLY message will indicate whether the authentication is complete or needs to be continued. If the process needs to be continued, the REPLY message also specifies what additional information is needed. The response from a client to a REPLY message requesting additional data is a CONTINUE message. This process continues until the server has all the information needed, and the authentication process concludes with a success or failure.

TACACS+ Authorization

TACACS+ authorization is defined as the action associated with determining permission associated with a user action. This generally occurs after authentication, as shown in Figure 19-1, but this is not a firm requirement. A default state of “unknown user” exists before a user is authenticated, and permissions can be determined for an unknown user. As with authentication, authorization is an optional process and may or may not be part of a site-specific operation. When authorization is used in conjunction with authentication, the authorization process follows the authentication process and uses the confirmed user identity as input in the decision process.

The authorization process is performed using two message types: REQUEST and RESPONSE. The authorization process is performed using an authorization session consisting of a single pair of REQUEST and RESPONSE messages. The client issues an authorization REQUEST message containing a fixed set of fields that enumerate the authenticity of the user or process requesting permission and a variable set of fields enumerating the services or options for which authorization is being requested.

The RESPONSE message in TACACS+ is not a simple yes or no; it can also include qualifying information, such as a user time limit or IP restrictions. These limitations have important uses, such as enforcing time limits on shell access or IP access list restrictions for specific user accounts.

TACACS+ Accounting

As with the two previous services, accounting is also an optional function of TACACS+. When utilized, it typically follows the other services. Accounting in TACACS+ is defined as the process of recording what a user or process has done. Accounting can serve two important purposes:

•  It can be used to account for services being utilized, possibly for billing purposes.

•  It can be used for generating security audit trails.

TACACS+ accounting records contain several pieces of information to support these tasks. The accounting process has the information revealed in the authorization and authentication processes, so it can record specific requests by user or process. To support this functionality, TACACS+ has three types of accounting records: START, STOP, and UPDATE. Note that these are record types, not message types as earlier discussed.

START records indicate the time and user or process that began an authorized process. STOP records enumerate the same information concerning the stop times for specific actions. UPDATE records act as intermediary notices that a particular task is still being performed. Together these three message types allow the creation of records that delineate the activity of a user or process on a system.

CHAP

Challenge Handshake Authentication Protocol (CHAP) is used to provide authentication across a point-to-point link using PPP. In this protocol, authentication after the link has been established is not mandatory. CHAP is designed to provide authentication periodically through the use of a challenge/response system sometimes described as a three-way handshake, as illustrated in Figure 19-2. The initial challenge (a randomly generated number) is sent to the client. The client uses a one-way hashing function to calculate what the response should be and then sends this back. The server compares the response to what it calculated the response should be. If they match, communication continues. If the two values don’t match, then the connection is terminated. This mechanism relies on a shared secret between the two entities so that the correct values can be calculated.

Figure 19-2   The CHAP challenge/response sequence

EXAM TIP    CHAP uses PPP, which supports three functions:

—Encapsulate datagrams across serial links

—Establish, configure, and test links using LCP (Link Control Protocol)

—Establish and configure different network protocols using NCP (Network Control Protocol)

PPP supports two authentication protocols:

—Password Authentication Protocol (PAP)

—Challenge Handshake Authentication Protocol (CHAP)

PAP

Password Authentication Protocol (PAP) authentication involves a two-way handshake in which the username and password are sent across the link in clear text. PAP authentication does not provide any protection against playback and line sniffing. PAP is now a deprecated standard.

EXAM TIP    PAP is a cleartext authentication protocol and hence is subject to interception. CHAP uses a challenge response handshake protocol to secure the channel.

MSCHAP

Microsoft Challenge Handshake Authentication Protocol (MSCHAP) is the Microsoft variant of CHAP. Microsoft has created two versions of CHAP, modified to increase its usability across their product line. MSCHAPv1, defined in RFC 2433, has been deprecated and dropped in Windows Vista. The current standard is MSCHAPv2, RFC 2759, which was introduced with Windows 2000. MSCHAPv2 offers mutual authentication, verifying both users in an exchange. It also offers improved cryptographic support including separate cryptographic keys for transmitted and received data.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a protocol that was developed as an AAA protocol. It was submitted to the IETF as a series of RFCs: RFC 2058 (RADIUS specification), RFC 2059 (RADIUS accounting standard), and updated RFCs 2865–2869 and 3579 are now standard protocols. The IETF AAA Working Group has proposed extensions to RADIUS (RFC 2882) and a replacement protocol called Diameter (RFC 7075).

RADIUS is designed as a connectionless protocol utilizing User Datagram Protocol (UDP) as its transport-level protocol. Connection type issues, such as timeouts, are handled by the RADIUS application instead of the transport layer. RADIUS utilizes UDP ports 1812 for authentication and authorization and 1813 for accounting functions.

RADIUS is a client/server protocol. The RADIUS client is typically a network access server (NAS). The RADIUS server is a process or daemon running on a UNIX or Windows Server machine. Communications between a RADIUS client and RADIUS server are encrypted using a shared secret that is manually configured into each entity and not shared over a connection. Hence, communications between a RADIUS client (typically a NAS) and a RADIUS server are secure, but the communications between a user (typically a PC) and the RADIUS client are subject to compromise. This is important to note, for if the user’s machine (the PC) is not the RADIUS client (the NAS), then communications between the PC and the NAS are typically not encrypted and are passed in the clear.

RADIUS Authentication

The RADIUS protocol is designed to allow a RADIUS server to support a wide variety of methods to authenticate a user. When the server is given a username and password, it can support PPP, PAP, CHAP, UNIX login, and other mechanisms, depending on what was established when the server was set up. A user login authentication consists of a query (Access-Request) from the RADIUS client and a corresponding response (Access-Accept or Access-Reject) from the RADIUS server, as you can see in Figure 19-3.

Figure 19-3   RADIUS communication sequence

The Access-Request message contains the username, encrypted password, NAS IP address, and port. The message also contains information concerning the type of session the user wants to initiate. Once the RADIUS server receives this information, it searches its database for a match on the username. If a match is not found, either a default profile is loaded or an Access-Reject reply is sent. If the entry is found or the default profile is used, the next phase involves authorization, for in RADIUS, these steps are performed in sequence. Figure 19-3 shows the interaction between a user and the RADIUS client and RADIUS server and the steps taken to make a connection:

1. A user initiates PPP authentication to the NAS.

2. The NAS prompts for

•  username and password (if PAP), or

•  challenge (if CHAP).

3. User replies with credentials.

4. RADIUS client sends username and encrypted password to the RADIUS server.

5. RADIUS server responds with Accept, Reject, or Challenge.

6. The RADIUS client acts upon services requested by user.

RADIUS Authorization

In the RADIUS protocol, the authentication and authorization steps are performed together in response to a single Access-Request message, although they are sequential steps, as shown in Figure 19-3. Once an identity has been established, either known or default, the authorization process determines what parameters are returned to the client. Typical authorization parameters include the service type allowed (shell or framed), the protocols allowed, the IP address to assign to the user (static or dynamic), and the access list to apply or static route to place in the NAS routing table. These parameters are all defined in the configuration information on the RADIUS client and server during setup. Using this information, the RADIUS server returns an Access-Accept message with these parameters to the RADIUS client.

RADIUS Accounting

The RADIUS accounting function is performed independently of RADIUS authentication and authorization. The accounting function uses a separate UDP port, 1813. The primary functionality of RADIUS accounting was established to support ISPs in their user accounting, and it supports typical accounting functions for time billing and security logging. The RADIUS accounting functions are designed to allow data to be transmitted at the beginning and end of a session, and it can indicate resource utilization, such as time, bandwidth, and so on.

When RADIUS was first designed in the mid-1990s, the role of ISP NASs was relatively simple. Allowing and denying access to a network and timing usage were the major concerns. Today, the Internet and its access methods have changed dramatically, and so have the AAA requirements.

SAML

Security Assertion Markup Language (SAML) is a single sign-on (SSO) capability used for web applications to ensure user identities can be shared and are protected. It defines standards for exchanging authentication and authorization data between security domains. It is becoming increasingly important with cloud-based solutions and with Software-as-a-Service (SaaS) applications as it ensures interoperability across identity providers.

SAML is an XML-based protocol that uses security tokens and assertions to pass information about a “principal” (typically an end user) with a SAML authority (an “identity provider” or IdP) and the service provider (SP). The principal requests a service from the SP, which then requests and obtains an identity assertion from the IdP. The SP can then grant access or perform the requested service for the principal.

OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which is discussed next. OpenID Connect allows clients of all types, including mobile, JavaScript, and web-based clients, to request and receive information about authenticated sessions and end users. OpenID is intended to make the process of proving who you are easier, the first step in the authentication–authorization ladder. To do authorization, a second process is needed, and OpenID is commonly paired with OAuth 2.0. OpenID was created for federated authentication that lets a third party, such as Google or Facebook, authenticate your users for you, by using accounts that the users already have.

OAUTH

OAuth (Open Authorization) is an open protocol that allows secure, token-based authorization on the Internet from web, mobile, and desktop applications via a simple and standard method. OAuth is used by companies such as Google, Facebook, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites. OAuth 1.0 was developed by a Twitter engineer as part of the Twitter OpenID implementation. OAuth 2.0 (not backward compatible) has taken off with support from most major web platforms. OAuth’s main strength is that it can be used by an external partner site to allow access to protected data without having to re-authenticate the user.

OAuth was created to remove the need for users to share their passwords with third-party applications, instead substituting a token. OAuth 2.0 expanded this into also providing authentication services, so it can eliminate the need for OpenID.

EXAM TIP    OpenID and OAuth are typically used together, yet have different purposes. OpenID is used for authentication, while OAuth is used for authorization.

Shibboleth

Shibboleth is a service designed to enable single sign-on and federated identity-based authentication and authorization across networks. It began in 2000, has been through several revisions and versions, but has yet to gain any widespread acceptance. Shibboleth is a web-based technology that is built using SAML technologies. Shibboleth uses the HTTP/POST, artifact, and attribute push profiles of SAML, including both identity provider (IdP) and service provider (SP) components to achieve its goals. As such, it is included by many services that use SAML for identity management.

Secure Token

Within a claims-based identity framework, such as OASIS WS-Trust, security tokens are used. A secure token service is responsible for issuing, validating, renewing, and cancelling these security tokens. The tokens issued can then be used to identify the holders of the tokens to any services that adhere to the WS-Trust standard. Secure tokens solve the problem of authentication across stateless platforms, for user identity must be established with each request. The basic five-step process to use tokens is as follows:

1. User requests access with username/password.

2. Secure token service validates credentials.

3. Secure token service provides a signed token to the client.

4. Client stores that token and sends it along with every request.

5. Server verifies token and responds with data.

These steps are highly scalable and can be widely distributed and even shared. A user application can use a token for access via another app, allowing someone to validate a login to Twitter via Facebook, as the tokens are transportable.

NTLM

NT LAN Manager (NTLM), also known as Windows Challenge/Response, is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. Both of these suites have been widely replaced by Microsoft’s Kerberos implementation, although NTLM is still used for logon authentication on stand-alone Windows machines. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire, but the cryptography used for this, MD4, is considered weak and deprecated by today’s standards.

Chapter Review

In this chapter, you became acquainted with the principles behind identity and access services. The chapter opened with an exploration of the LDAP protocol and then moved to Kerberos. TACACS+ was explored next, including how it performs authentication, authorization, and accounting. The chapter then examined the CHAP, PAP, and MSCHAP protocols. It then moved back to integrated services, this time looking at RADIUS, including how it does authentication, authorization, and accounting.

The chapter then explored distributed and federated methods such as SAML, OpenID Connect, OAuth, and Shibboleth. The chapter next introduced the use of secure tokens, followed by an examination of NTLM, an old, but still essential service.

Questions

To help you prepare further for the CompTIA Security+ exam, and to test your level of preparedness, answer the following questions and then check your answers against the correct answers at the end of the chapter.

1. You are working with a development group on a new web application that will be hosted in the cloud. They need single sign-on capability to exchange authentication and authorization data between multiple security domains and they prefer working with XML. What would you suggest they use?

A. PAP

B. RADIUS

C. SAML

D. SecureID

2. A colleague has been tasked to update the authentication protocols for a very old Windows-based application running on a stand-alone system—it’s still using LANMAN and running on Windows XP. The colleague would prefer to keep using something from Microsoft, but she can’t upgrade the OS past Windows 7 during this effort. Which of the following would you suggest she use?

A. TACACS+

B. NTLM

C. RADIUS

D. LDAP

3. Which of the following protocols uses a key distribution center and can securely pass a symmetric key over an insecure network?

A. CHAP

B. PAP

C. LDAP

D. Kerberos

4. Your colleague is preparing a talk about TACACS+ authentication and the exchange sequence. He is having trouble remembering the three different packet types used in the authentication process. Which of the following is not one of the three packet types used in TACACS+ authentication?

A. REPLY

B. START

C. CONTINUE

D. INITIATE

5. While helping to catalog older servers in your data center, you come across a RADIUS accounting server. Your supervisor asks you what RADIUS accounting was typically used for. You tell him it was used mainly for which of the following?

A. Source and destination IP addresses of network traffic

B. Applications used by users

C. Time billing and security logging

D. Tracking file access

6. Your development team needs an authentication solution that supports authentication across stateless platforms. They want you to explain how other applications use Facebook or Goggle logins for authentication. In your explanation, which of the following concepts would you definitely need to mention?

A. Secure tokens

B. Secure tickets

C. XML requests

D. Request packets

7. You are establishing a point-to-point link and need to provide authentication using PPP. Which of the following protocols would you consider?

A. CHAP

B. RADIUS

C. SAML

D. TCP auth

8. What does the “A” in RADIUS stand for?

A. Application

B. Authorization

C. Authentication

D. Auditing

9. Which of the following statements regarding TACACS+ is true?

A. Communications between a TACACS+ client (typically a NAS) and a TACACS+ server are not secure.

B. Communications between a user (typically a PC) and the TACACS+ client are subject to compromise as communications are usually not encrypted.

C. TACACS+ is an extension of TACACS and is backward compatible.

D. TACACS+ uses UDP for its transport protocol.

10. Which of the following protocols involves a two-way handshake and sends the username and password in clear text?

A. SAML

B. LDAP

C. PAP

D. NTLM

11. OpenID Connect allows for which of the following?

A. A third party can authenticate your users for you using accounts the users already have.

B. Symmetric keys can be shared across unsecured networks.

C. Identity can be confirmed with a single UDP packet.

D. Trusted IP addresses can be used to mitigate brute force attacks.

12. Your IT group is reworking their user authentication and authorization capabilities. They need something that can be used to control access to objects as well as handle user authentication and authorization. Which of the following protocols would you suggest they use?

A. MSCHAP

B. TACACS

C. PPP

D. LDAP

13. Which of the following is a service designed to enable single sign-on and federated identity-based authentication and authorization across networks?

A. PAP

B. Shibboleth

C. XAML

D. OASIS

14. Which of the following is a true statement about the NTLM protocol?

A. It uses an encrypted challenge/response protocol to authenticate a user.

B. It passes user credentials in clear text only.

C. It is commonly used to integrate UNIX services into a network.

D. It is typically used on stand-alone systems.

15. Which of the following is an open protocol that allows secure, token-based authentication and authorization from web, desktop, and mobile applications and is used by companies such as Google and Microsoft to permit users to share information about their accounts with third-party applications?

A. TKIP

B. OAuth

C. SAML

D. RADIUS

Answers

1. C. Security Assertion Markup Language (SAML) is a single sign-on capability used for web applications to ensure user identities can be shared and are protected. It defines standards for exchanging authentication and authorization data between security domains. It is becoming increasingly important with cloud-based solutions and with Software-as-a-Service (SaaS) applications as it ensures interoperability across identity providers.

2. B. NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users and would be the most likely choice from the list of choices. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN).

3. D. Kerberos securely passes a symmetric key over an insecure network using the Needham-Schroeder symmetric key protocol. Kerberos is built around the idea of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an authentication server (AS) and a ticket-granting server (TGS). Kerberos communicates via “tickets” that serve to prove the identity of users.

4. D. The TACACS+ authentication process is performed using three different packet types: START, CONTINUE, and REPLY. START and CONTINUE packets originate from the client and are directed to the TACACS+ server. The REPLY packet is used to communicate from the TACACS+ server to the client.

5. C. The primary functionality of RADIUS accounting was established to support ISPs in their user accounting, and it supports typical accounting functions for time billing and security logging.

6. A. Secure tokens provide for authentication across stateless platforms and can be used to identify the holder of the token to any services that adhere to the WS-Trust standard. Secure tokens are transportable, which is what allows users to log in to Twitter or other applications via Facebook.

7. A. Challenge Handshake Authentication Protocol (CHAP) is used to provide authentication across a point-to-point link using PPP.

8. C. The “A” stands for Authentication—Remote Authentication Dial-In User Service (RADIUS).

9. B. Communications between a user (typically a PC) and the TACACS+ client are subject to compromise as they are usually not encrypted.

10. C. Password Authentication Protocol (PAP) authentication involves a two-way handshake in which the username and password are sent across the link in clear text. PAP authentication does not provide any protection against playback and line sniffing.

11. A. OpenID was created for federated authentication that lets a third party authenticate your users for you, by using accounts the users already have.

12. D. LDAP is a protocol that is commonly used to handle user authentication/authorization as well as control access to Active Directory objects.

13. B. Shibboleth is a service designed to enable single sign-on and federated identity-based authentication and authorization across networks. Shibboleth is a web-based technology that is built using SAML technologies.

14. A. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire, but the cryptography is considered to be weak and ineffective by today’s standards.

15. B. OAuth (Open Authorization) is an open protocol that allows secure, token-based authorization on the Internet from web, mobile, and desktop applications via a simple and standard method. OAuth is used by companies such as Google, Facebook, Microsoft, and Twitter to permit the users to share information about their accounts with third-party applications or websites.