Chapter 4: Deploying Enterprise Authentication and Authorization Controls

Large enterprises often have very complex environments to manage. There are internal users to manage, there are internal services and external service providers. There are customers to consider, for guest users, within Business-to-Business (B2B) relationships. Federation services can be utilized to ensure robust, centralized authentication and access control are addressed in these hybrid environments. To manage all these interactions with information systems, the correct protocols must be chosen to make sure we have secure authentication and authorization. Many modern environments require the use of an additional factor as a single factor, such as just a user password, is known to be weak. In this chapter, you will learn how to effectively select the appropriate solution.

In this chapter, we will go through the following topics:

• Credential management
• Identity federation
• Access control
• Authentication and authorization protocols
• Using Multi-Factor Authentication (MFA)

Credential management

Credential management is critical for an enterprise. We must consider the day-to-day management of user credentials, including effective management of passwords. We must ensure passwords are created, stored, and destroyed securely. They must always be processed securely as well.

Single Sign-On (SSO)

The goal of SSO is to allow users to use a single account to access many services. This relies on robust authentication so ties in nicely with MFA. The weakness of SSO would be the account credentials being stolen. It is important to protect the account. SSO is very convenient for users. They must only remember one set of credentials.

Tip

When you sign in to Google to access Gmail, Google Docs, and content on YouTube, you will only need to sign in once with your Google account.

Password repository applications

Organization goals should include the use of SSO wherever possible. This allows a single account to be used for multiple applications or services. This goal, however, is not always achievable as some online service providers may not support SSO and insist upon creating local accounts. To allow users to store these additional accounts with passwords in a safe way, a local secure password repository can be used. Microsoft provides Credential Manager; Apple provides iCloud Keychain. This allows the use of a secure vault to store the required account password and transmit it to the application when required. See Figure 4.1 for a depiction of Microsoft Credential Manager:

Figure 4.1 – Microsoft Windows Credential Manager

It is important to have a secure, easy-to-use container for authentication credentials.

On-premises versus cloud password repository

As hybrid cloud models become the new normal for a business, they present a challenge for secure credential management. Should passwords be stored with the cloud provider? It is worth considering many cloud providers will have advanced access control, behavioral analytics, and continuous validation as part of their security offering. However, there is often a choice to use federation when accessing cloud-based services. When using Microsoft 365 services, it is possible to manage all identities on-premises, including passwords, and gain federated access to cloud portals.

Federation will be covered in detail in the Identity federation section.

Hardware key manager

Traditional password management software relies on the local operating system and stores the keys locally. Another option is for a hardware key manager that is quite popular and is relatively low cost but offers additional security just like having a separate smart card. A hardware key will typically support strong encryption algorithms to protect passwords. These devices may include tamper protection, erasing the contents after a number of failed attempts. Figure 4.2 shows a hardware implementation of a key manager:

Figure 4.2 – Hardware key manager

When we look at the use of multiple accounts that are privileged, there are better-managed solutions to handle this requirement.

Privileged access management

Privilege access management systems are very useful for allowing an employee to log in with their individual account and when necessary, they can check out an elevated credential password. This system will also allow the use of a shared account, but still makes that user accountable because their access to that privileged account will have been logged against their individual user account. This is even more useful nowadays as many organizations have hybrid cloud models, where we need to administrate on-premises and then with multiple cloud providers.

Password policies

Password policies need to be enabled to make sure that users will change their passwords based on the organization's requirements. Passwords can be chosen to have a certain level of complexity and/or meet a minimum character length. Password complexity is used to enforce the use of different character classes (uppercase, lowercase, numbers, and special characters: @~#!"£€%&). It is also important to have a password history so that users cannot reuse old passwords. Guidance has changed over recent years. Instead of enforcing super-complex passwords, it is accepted that Two-Factor Authentication (2FA) or MFA is the preferred option to protect identities. A long passphrase is proven to be much more secure overall than a complex password. To enforce password requirements, we could use a policy such as the one shown in Figure 4.3:

Figure 4.3 – Microsoft Group Policy password settings

If we do not have a baseline password requirements policy, users may choose weak passwords.

Password complexity

Password requirements will often have a requirement for complexity. This will require at least three from four character classes: uppercase, lowercase, numbers, and special characters.

Password length

Eight characters is generally recommended as the minimum length of a password; any greater than this and users will adopt bad practices, such as repeating the password to meet this requirement, for example, Bertie26Bertie26.

Password history

Password history is important. Without password history, compromised accounts may be reset to the original password, allowing the attackers to gain access to the account again.

Password maximum/minimum age

It is important to have a password minimum age as without a password minimum age, users may reset their passwords multiple times to get back to the original password. A password maximum age, however, is not really recommended anymore. Requiring users to change their password frequently (often every 30, 60, or 90 days) can sometimes mean they choose a weak password by simply incrementing a sequential number at the end of the old password. The passwords that are then chosen are often a poor choice and are vulnerable to attack. Also consider the fact that a compromised password is exploited immediately.

Password auditing

Password auditing is important as it allows the organization to check for weak passwords. Password checking can be done when users reset their passwords. We could use a dictionary word list to generate hashes and check that the users are not using those weak passwords. The National Cyber Security Center (NCSC) has listed 100,000 passwords taken from https://haveibeenpwned.com. The list can be found at the following link: https://www.ncsc.gov.uk/static-assets/documents/PwnedPasswordsTop100k.txt. The first 20 words from the list are shown in Figure 4.4:

Figure 4.4 – Password wordlist

If you find any of your passwords that are in use shown in this list, you should change them immediately.

Reversible encryption

Passwords should be stored in a secured format within a password database. They are normally hashed, prior to being written into the database. Password reversible encryption allows passwords to be stored in a plain text format. This is used for some legacy applications (perhaps a remote access management solution). These should never be used. An example would be Microsoft Remote Access Service (RAS). This allows users to be authenticated using Challenge Handshake Authentication Protocol (CHAP).

As well as being able to authenticate user accounts within our own sites, it is also important to work with external entities.

Identity federation

Identity federation allows you to use your identity with a third party. Many organizations will use services in the cloud such as software as a service. This allows the user to use SSO in their own enterprise and when accessing these third-party applications. Users only need to remember one identity. Typically, a token will be generated by an identity federation service and passed securely to the third party. Microsoft provides a service called Active Directory Federation Services (ADFS), which allows an authenticated enterprise user to use their credentials on a third-party site. They support many of the standard protocols in use out there including Security Assertion Markup Language (SAML).

Transitive trust

Transitive trust can be very useful within complex enterprise environments. When using directory services, we can create security boundaries referred to as domains or Kerberos realms. It is common to create these boundaries to separate account management geographically. For example, a bicycle manufacturer has a Taiwanese engineering and production plant in Taipei. They have sales, marketing, and distribution in Santa Cruz, US, which is the head office, and the same business function in Morzine, France. Each location has a separate domain, with the US being the root and Taiwan and France being child domains. In Figure 4.5, we can see the trust relationships between the domains:

Figure 4.5 – Transitive trust

There are direct trusts between the root domain and the child domains. There is, however, transitive trust between the two child domains. The relationship is similar to the concept of an authenticated Internet Protocol Security (IPsec) tunnel. An administrator would still need to provision access to resources, but there would be inherent trust between all parts of the organization. The sales team could then be given read privileges to production data from the manufacturing plant.

OpenID

Cloud-based Identity Providers (IdPs) such as Google, Facebook, and Twitter support a standard called OpenID. This is often used to access third-party services (referred to as the Relying Party (RP)) who support this standard. The current standard is version 2.0, and it is administered by the OpenID Foundation, a non-profit entity.

Once an identity has been validated by the OpenID provider, a secure token is generated and forwarded to the requesting service provider in the form of a JavaScript Object Notation Web Token (JWT). Figure 4.6 shows the OpenID SSO process:

Figure 4.6 – OpenID process

While OpenID is standard for cloud-based identities, there are other options used when enterprise users access third-party corporate portals.

Security Assertion Markup Language (SAML)

SAML is an open standard typically used to access corporate cloud-based portals for access to applications. It requires an IdP. The IdP will typically use directory services internally; the service provider will be the cloud entity. The service provider will require a secure token generated by the IdP. It also makes the experience for the user transparent, makes it easy for them to access third-party services, and supports SSO. Microsoft allows SAML to authenticate identities to Microsoft 365 services. SAML actually creates assertions. It uses the XML language and is secure. Assertions could include authentication attributes and authorization decisions.

The experience will be completely transparent to the user if they have already authenticated with the IdP:

Figure 4.7 – SAML

SAML is a good choice for accessing third-party corporate portals.

Shibboleth

Shibboleth is similar to SAML. It is, however, used mainly by educational establishments such as colleges and universities. It also allows for SSO by passing a token to the service provider and requires an IdP.

Once we have authenticated accounts, we may give access to resources.

Access control

Access control can be used to control authorization once a user has been authenticated. There may be many different requirements; for example, developers may need to share their code with one another. There may be requirements for very strict access control when there are sensitive documents that must be accessed. There may be a requirement to give privileges and rights to administrative role holders or perhaps to give fine-grained access based upon the location or the country of origin of the account holder. In the following section, we will investigate these choices.

Mandatory Access Control (MAC)

MAC is generally seen as the most secure way of controlling access to assets. It requires clearance levels. It requires the data to be classified or labeled. It can be time-consuming but offers the most security. Government agencies such as the Department of Defense and other such entities will typically use this system. Figure 4.8 shows the classification options for a filesystem folder:

Figure 4.8 – MAC

It is important to ensure strict adherence to a MAC framework; no write down and no read up (this stops a user with a lower clearance level from seeing data they are not cleared for).

Discretionary Access Control (DAC)

DAC means the authorization to the resource is controlled by the owner. This works well in the Windows NTFS filesystem where the owner of a file or a folder can assign permissions to other users or groups. This allows for decentralization. Another good example could be a SharePoint portal. While ownership is assigned to a team leader, they can then add their co-workers to give them access to the site:

Figure 4.9 – DAC

DAC could work well for smaller integrated teams (such as developers).

Role-based access control

Role-based access control can be used with existing roles, such as administrators, network configuration operators, and backup operators, or groups can be created for business units such as sales, marketing, production, and research. Role-based access control is centralized. It requires the administration to be done centrally. It works well with directory services. In Figure 4.10, we can see a list of Microsoft Active Directory groups. There are built-in role groups such as Cert Publishers and DHCP Administrators. Bill and Ben have been added to the ITAdmin group:

Figure 4.10 – Role-based access control

Roles or groups are commonly used to manage a large enterprise user base and are considered a good way to implement the best practice of least privilege.

Rule-based access control

Rule-based access control can be good for things where we need a common set of controls; for example, a particular department may require all their users to only work within certain hours or the requirement is that certain users can only log on from certain workstations. In Figure 4.11, we can see two student accounts have limited logon hours and can only log on from two workstations (intern01 and intern02):

Figure 4.11 – Rule-based access control

Rules can be very useful when we have a set of requirements to assign to multiple accounts.

Attribute-based access control

Attribute-based access control offers another level of granularity. It also works well with directory services. Attributes are associated with objects; for example, a user can have a department or a country attribute associated with their account. These attributes could be used to give more granular access to resources. For example, you may have research data that can only be accessed by scientists in the US. You could put extra controls in place so that members of the Scientists group can only access the data if they have United States as the country on their Active Directory user account:

Figure 4.12 – Attribute-based access control

In order to capture user credentials and authorize access to resources, there are industry-standard approaches.

Authentication and authorization protocols

There are many protocols associated with authentication and authorization in an enterprise. A common approach will be to log on within the domain using directory services. This may use Kerberos as an SSO protocol. In other cases, we must look at solutions where this is not possible. Remote access could be an example, or securing access to the network using the new zero-trust approach. In this section, we will take a look at the available protocols.

Remote Authentication Dial-In User Server (RADIUS)

RADIUS is a well-supported Authentication, Authorization, and Accounting (AAA) protocol. This is used to gain access to networks, so it could be used to grant access over a Virtual Private Network (VPN) or anything that will require remote access. Radius could also be used to gain access to a switch that is Ethernet 802.1 X-compliant. This could also be used to gain access to a Wireless Access Point (WAP). AAA allows the RADIUS client (network device) to pass on authentication requests to the AAA server. The server will often pass these requests back to a directory services server, as RADIUS may not actually hold the user account database. RADIUS supports two networking protocols or port numbers. It can operate on UDP port 1812 or UDP port 1645 (this is normally used by Cisco). Figure 4.13 shows clients (supplicants) accessing networks through 802.1x-compliant RADIUS clients:

Figure 4.13 – AAA services

While RADIUS is the most widely adopted AAA protocol, there are other solutions.

Terminal Access Controller Access Control System (TACACS)

TACACS was originally developed in 1984 and was very common on UNIX networks for the purpose of authenticating access to a network. It has been further developed by Cisco and the current standard is TACACS+. This has no compatibility with earlier versions. TACACS is like RADIUS but does not have as wide support as RADIUS. It uses TCP ports for AAA, making it more reliable, and it is said to be more secure because it encrypts the entire authentication process (it uses TCP port 49).

Diameter

Diameter is the next version of RADIUS. It is based upon RADIUS but uses TCP ports to make the connection and the authentication more reliable. It has wide support from many vendors. It has been assigned TCP port 3868.

Lightweight Directory Access Protocol (LDAP)

LDAP is a standard for accessing directory services. It was chosen as an alternative to Directory Access Protocol (DAP), as it is more straightforward. LDAP allows for access to directory services and the creation of content, such as user accounts, computer accounts, and other types of objects in directory services. It is usually used to administer directory services. It is defined in RFC 4511. LDAP uses port 389 for regular access. Alternatively, we can use Transport Layer Security (TLS). This uses TCP port 636 and allows for the connection to be secured (LDAPS). Figure 4.14 shows the typical administration of objects in an LDAP database. In this instance, we are resetting a user password and creating a new user account:

Figure 4.14 – LDAP services

LDAP does not provide the authentication for the user login.

Kerberos

Kerberos is a secure SSO protocol that was developed by the Massachusetts Institute of Technology (MIT) and is protected by export restrictions to use within the US. This is now supported by the Internet Engineering Task Force (IETF) and has been assigned several RFCs defining the implementation (RFC 3961, 3962, 4120, and 4121). Kerberos is in widespread use and is supported by many operating system vendors, including Red Hat, Oracle, and IBM. It has been the standard for Microsoft Active Directory services for over 20 years. Kerberos supports encrypted communication and anti-replay. Kerberos is very time-dependent. It is important that the clocks are in synchronization; otherwise, Kerberos authentication will fail. Figure 4.15 shows the Kerberos SSO mechanism. The server hosting the Key Distribution Center (KDC) and Ticket Granting Services (TCS) could be a Windows Domain Controller (DC) running Active Directory services:

Figure 4.15 – Kerberos authentication

Kerberos is used on enterprise networks but is not used when accessing third-party sites or B2B partners.

OAuth

OAuth allows for SSO. Users can sign in to their OpenID provider such as Facebook, Google, or Twitter and they can access third-party services. Users do not need to remember multiple credentials. It is used by many service providers, including Microsoft, Tripadvisor, Hotels.com, and many merchant sites requiring payment authorization. There are currently two versions of Open Authorization (OAuth): V1 and V2. OAuth V2 is the current standard. PayPal would be a good example of a system we use every day. If you make a payment on a merchant site and you choose to use PayPal, you will end up being prompted to authorize that payment. A token will be securely generated by PayPal and sent to the merchant site. This will authorize the transaction.

Figure 4.16 shows typical sites supporting SSO using OAuth:

Figure 4.16 – OAuth SSO dialogs

Once you have indicated the account that is to be used, the connection can be transparently made in the future.

Important Note

OAuth defines the flow of requests and responses to authorize a transaction, while OpenID defines the role of the IdP.

802.1X

802.1X is an Ethernet standard. It defines Port-Based Access Control (PBAC). It can allow devices or users to be authenticated to a network connection and is supported on switches, remote-access VPNs, and WAPs. It can be easily configured with the use of Public Key Infrastructure (PKI) certificates. Certificates can be assigned to devices such as computers, mobile devices, IoT devices, and network printers. A wide variety of devices can be connected securely to networks, removing the need for actual credentials to be typed in.

Extensible Authentication Protocol (EAP)

EAP is a framework. This allows more secure authentication methods to be implemented when using PBAC. PBAC is implemented when network devices support 802.1x Ethernet standards. For more details, see Chapter 1, Designing a Secure Network Architecture.

Tip

For the certification exam, it is important to recognize the appropriate authentication protocols to provide both security and compatibility within complex enterprise networks.

A single factor for authentication is always a risk. Compromise of a password may be all that is needed for hackers to take control of an account. Having a second factor is the best protection against this threat.

Multi-Factor Authentication (MFA)

MFA is becoming an important consideration for many enterprises as passwords alone are not considered secure enough. Guidance from the NCSC in the United Kingdom recommends that MFA should be used to counter the threat of compromised passwords. Microsoft strongly promotes the use of MFA when accessing their cloud services. It is becoming more and more straightforward to implement multiple factors; for example, Microsoft automatically supports the use of smart cards with Active Directory accounts. There are many third-party solution providers offering mobile authenticator apps. We will take a look at some of the choices in the following sections.

Two-Factor Authentication (2FA)

2FA simply means using two different methods or two different factors during the authentication process. You must combine two different factors. Factors are assigned a unique identifier (there are five factors: Type I through to Type V).

The factors include the following:

• Type I – Something you know: Password, pin, birthday
• Type II – Something you have: Token, smart card, RFID card
• Type III – Something you are: Retina, iris, fingerprint, facial recognition
• Type IV – Somewhere you are IP address, GPS
• Type V – Something you do: Gait, handwriting, keystrokes

  Tip

  Two factors could be password and smart card, pin and ATM card, or biometrics and a physical token such as an RFID card. One of each type (Type I and Type III, for example) is required.

Additional authentication can be triggered by a change of context; maybe you logged in from a new location, or from a device that you have never logged in from before.

Two-step verification

Two-step verification is supported by many online IdPs. Think about when you log in to Google from a new workstation you have never signed in from before. You would receive a push notification in your Google app on your smartphone and need to respond:

Figure 4.17 – Two-step verification

When using two-step verification, it is preferable to use a second channel. Imagine a fraudster phished the credentials of a user. They would have to gain control of something else as well, such as the user's smartphone.

In-band authentication

In-band authentication would mean doing all the necessary authentication checks using a single channel, such as your internet browser connection to your bank. This would be seen as inferior to other mechanisms. Reliance on in-band authentication makes the possibility of Cross-Site Request Forgery (CSRF/XSRF) very real. Imagine you are connected to your bank and have logged on with your user account and password. A malicious script could authorize a payment to a criminal.

Out-of-Band Authentication (OOBA)

OOBA would require the use of a secondary channel, such as when you log in to your bank, you receive an SMS message on your smartphone, or when you log in to your Google account, you are asked to verify your identity using your smartphone. Your bank will use OOBA to send you an authorization request, to prevent fraud.

One-Time Password (OTP)

OTPs mean you are prompted for a password that you did not previously know or set; this is typically a password that is generated for you for one-time use where you must enter a strong password for future use to continue.

HMAC-based One-Time Password (HOTP)

HMAC-based systems generate OTPs on demand. The device will have a seed or a key. It will generate codes or passwords based upon an incrementing counter. These passwords do not have to be used immediately, which means this could be less secure. HMAC OTPs do not always have to be used sequentially, which means this system could be exploited.

Time-based One-Time Password (TOTP)

TOTPs are based on the same principle as HMAC-based OTPs. There is a key that will be embedded into your token (or smart app) that creates codes based upon the current time. The password will only be relevant for 30 seconds (although this set time can vary); then, a new password will be generated. This reduces the chances of passwords being compromised. Figure 4.18 shows an RSA SecurID token device:

Figure 4.18 – RSA SecurID token ("File:RSA SecurID Token Old.jpg" by Alexander Klink is licensed with CC BY 3.0: https://creativecommons.org/licenses/by/3.0)

Time synchronization with the authentication server is important. This type of MFA is very popular and with more and more online digital identities to manage, you need to ensure access is secured to these online portals. When you complete your tax returns, you can secure this with MFA TOTP or connect to your bank to perform electronic banking. Figure 4.19 shows typical TOTP prompts:

Figure 4.19 – MFA using TOTP

There are many other solutions allowing for secure attestation.

Hardware root of trust

A hardware root of trust is a secure container. A good example would be a hardware implementation of a security module such as the Trusted Platform Module (TPM) incorporated into many modern computer systems. This allows for values to be stored that could be used for secure boot, as we can validate the information that is stored in that container. We can use it to store cryptographic keys for BitLocker Drive Encryption, providing security while encrypting and decrypting drives.

TPM can store other types of information that can be used to validate or attest that certain conditions or information are correct. It is used for mobile device management, as we can store software and hardware values in a secure container. If we trust that container, we can extract the information from that hardware root of trust. When you enable BitLocker with TPM support, you will need to configure additional settings, as in Figure 4.20:

Figure 4.20 – Hardware root of trust

Users will be able to remember a single set of credentials more easily. Whenever we ask users to authenticate with multiple sets of credentials, we introduce the risk of unsecured user behaviors.

JWT

JWT is based upon an open standard (RFC 7519). It is used for securely sending information between parties where a secure trusted payload is important. The attestation service will validate a piece of information so this could be very useful within a cloud environment where we are not already directly trusting one another. Microsoft could be the attestation provider; they will sign a requestors information package and if the third party trusts Microsoft's attestation service, they will be able to trust the JWT. It is a similar concept to PKI; if you trust the root CA, then you automatically trust certificates generated within that hierarchy. JWTs can be used for both attestation and identity proofing. A common use of JWT is when using federation services such as OpenID and OAuth V2.

Summary

In this chapter, we have studied the challenges large enterprises face when they must support complex environments, needing to manage internal users and their authentication to external service providers. We have looked at the role of federation services, to ensure robust authentication and access control are addressed in hybrid environments. We have looked at the use of MFA as a single factor is known to be weak. We have studied the options to ensure authentication is needed to gain access to a network.

In this chapter, you have gained the following skills:

• Securely managing credentials
• Understood the situations that require identity federation
• Examined access control models
• Understood authentication and authorization protocols
• Examined the choices for MFA

These core skills will be useful as we move into the next domain: security operations.

Questions

Here are a few questions to test your understanding of the chapter:

1. What is the container on a Windows operating system that allows the secure storage of user credentials and passwords?
   1. Password repository application
   2. Credential Manager
   3. iCloud Keychain
   4. End user password storage
2. What security would be provided for the storage of passwords in a cloud repository? Choose three.
   1. Advanced access control
   2. Behavioral analytics
   3. Continuous validation
   4. Reversible encryption
3. What type of device allows the secure retention of user passwords?
   1. Hardware key manager
   2. Removable storage
   3. Password policies
   4. iCloud Keychain
4. What management solution allows auditing of privileged accounts and checkout of these credentials?
   1. Password policies
   2. Privileged access management
   3. Password complexity
   4. Password auditing
5. What password policy will ensure a password cannot be reused? Choose two.
   1. Password length
   2. Password reuse
   3. Password complexity
   4. Password history
6. What password policy would most likely force Bill to change his password from flowerpot to F10w€rPot?
   1. Password length
   2. Password reuse
   3. Password complexity
   4. Password history
7. What password policy will ensure Mary cannot spend her lunch break resetting her password 24 times to make it the original password?
   1. Minimum password age
   2. Maximum password age
   3. Password complexity
   4. Password history
8. How can you detect the use of a poor password that may match dictionary words?
   1. Password spraying
   2. Password auditing
   3. Password guessing
   4. Password reset
9. What is required for CHAP authentication, when setting a password requirements policy?
   1. Strong encryption
   2. Reversible encryption
   3. Forward encryption
   4. Complexity
10. What is the term used when credentials can be used with a third party utilizing SSO?
    1. Identity proofing
    2. Identity federation
    3. Identity cloud
    4. Identity trust
11. What XML federation service will most like be used to access third-party cloud-based corporate portals?
    1. Shibboleth
    2. SAML
    3. OAuth
    4. OpenID
12. Which federation service will most like be used to access third-party cloud-based digital services?
    1. OAuth
    2. SAML
    3. Kerberos
    4. LDAP
13. What access control will offer the most security for a government agency?
    1. MAC
    2. DAC
    3. Role-based access control
    4. Rule-based access control
14. What access control will offer the most flexibility for de-centralized administration?
    1. MAC
    2. DAC
    3. Role-based access control
    4. Rule-based access control
15. What access control will allow for access based upon country and department?
    1. MAC
    2. DAC
    3. Role-based access control
    4. Attribute-based access control
16. Which AAA service offers the widest support across vendor networking equipment?
    1. RADIUS
    2. TACACS+
    3. Circumference
    4. HP proprietary
17. How can I administer my directory services securely?
    1. LDAP using TLS
    2. Kerberos
    3. OAuth
    4. Out-of-band
18. What can I use to authenticate securely to directory services, preventing replay and MITM attacks?
    1. IPsec
    2. Kerberos
    3. CHAP
    4. PAP
19. What Ethernet standard allows networking appliances to authenticate connection attempts?
    1. 802.11
    2. 802.1X
    3. 802.3
    4. 802.1s
20. What is the framework that allows many different authentication protocols?
    1. PAP
    2. EAP
    3. CHAP
    4. PEAP
21. What will I need to support if users need to present an RFID card, iris scan, and pin?
    1. MFA
    2. 2FA
    3. Two-step verification
    4. In-band authentication
22. What is being used when my bank sends me a confirmation code via SMS?
    1. In-band authentication
    2. OOBA
    3. Bandwidth
    4. Out-of-bounds
23. What type of password is not already known to the user?
    1. Forgotten password
    2. OTP
    3. PIN
    4. KBA question
24. What will I need to support if users need to present a password, memorable secret, and pin?
    1. MFA
    2. 2FA
    3. Two-step verification
    4. Single-factor authentication
25. What type of password will my Microsoft Authenticator application generate?
    1. HOTP
    2. TOTP
    3. Hardware root of trust
    4. JWT
26. What is called it when I sign on to directory services and can use my internal email without being prompted to sign in a second time?
    1. SSO
    2. JWT
    3. Attestation and identity proofing
    4. TPM

Answers

1. B
2. A, B and C
3. A
4. B
5. B and D
6. C
7. A
8. B
9. B
10. B
11. B
12. A
13. A
14. B
15. D
16. A
17. A
18. B
19. B
20. B
21. A
22. B
23. B
24. D
25. B
26. A