Section 8 – Implement an Authentication and Access Management Solution – Manage user authentication

• administer authentication methods (FIDO2 / Passwordless)
• implement an authentication solution based on Windows Hello for Business
• configure and deploy self-service password reset
• deploy and manage password protection
• configure smart lockout thresholds
• implement and manage tenant restrictions

What is passwordless?

Passwordless means that You sign-in without a password, You really don’t have a password. Or You could have but You don’t need it to sign-in. You will use a device or biometric solution to sign-in (ex. fingerprint or Your Face)

In my last blog there was a list and passwordless covers 2 out of 3 from this list.

• Something you possess – which might be a mobile app that receives a notification or a token-generating device.
• Something you are – which typically is a biometric property, such as a fingerprint or face scan used on many mobile devices.

I will be covering the solutions that are needed for SC-300 not the preview ones, although I really like the Temporary Access Pass but it’s still in preview and not in the test. Hopefully don’t have to wait that long for it to be GA!

Choose a passwordless method

	Windows Hello for Business	Passwordless sign-in with the Microsoft Authenticator app	FIDO2 security keys
Pre-requisite	Windows 10, version 1809 or later	Microsoft Authenticator app	Windows 10, version 1903 or later
	Azure Active Directory	Phone (iOS and Android devices running Android 6.0 or above.)	Azure Active Directory
Mode	Platform	Software	Hardware
Systems and devices	PC with a built-in Trusted Platform Module (TPM)	PIN and biometrics recognition on phone	FIDO2 security devices that are Microsoft compatible
	PIN and biometrics recognition
User experience	Sign in using a PIN or biometric recognition (facial, iris, or fingerprint) with Windows devices.	Sign in using a mobile phone with fingerprint scan, facial or iris recognition, or PIN.	Sign in using FIDO2 security device (biometrics, PIN, and NFC)
	Windows Hello authentication is tied to the device; the user needs both the device and a sign-in component such as a PIN or biometric factor to access corporate resources.	Users sign in to work or personal account from their PC or mobile phone.	User can access device based on organization controls and authenticate based on PIN, biometrics using devices such as USB security keys and NFC-enabled smartcards, keys, or wearables.
Enabled scenarios	Password-less experience with Windows device.	Password-less anywhere solution using mobile phone.	Password-less experience for workers using biometrics, PIN, and NFC.
	Applicable for dedicated work PC with ability for single sign-on to device and applications.	Applicable for accessing work or personal applications on the web from any device.	Applicable for shared PCs and where a mobile phone is not a viable option (such as for help desk personnel, public kiosk, or hospital team

Solutions from Microsoft

So the solutions are FIDO2 and Microsoft Authenticator. Temporary pass is a also a nice feature for new users to sign-in and create their own pass, but this one will not be covered in this article.

FIDO2 (Fast IDentity Online)

So first on the list is FIDO2 (Fast IDentity Online) keys. with FIDO you can use an usb-dongle to register and then select a FIDO2 security key at the sign-in interface as their main means of authentication. These FIDO2 security keys are typically USB devices, but could also use Bluetooth or NFC. With a hardware device that handles the authentication, the security of an account is increased as there’s no password that could be exposed or guessed.

Microsoft has browser support web for FIDO usb-dongles https://docs.microsoft.com/en-us/azure/active-directory/authentication/fido2-compatibility

In Azure AD you can assign the keys to target groups, for all users or to selected users.

In the configure section

Allow self-service set up should remain set to Yes. If set to no, your users will not be able to register a FIDO key through the MySecurityInfo portal, even if enabled by Authentication Methods policy.

Enforce attestation setting to Yes requires the FIDO security key metadata to be published and verified with the FIDO Alliance Metadata Service, and also pass Microsoft’s additional set of validation testing.

Enforce key restrictions should be set to Yes only if your organization wants to only allow or disallow certain FIDO security keys, which are identified by their AAGuids. You can work with your security key provider to determine the AAGuids of their devices. If the key is already registered, AAGUID can also be found by viewing the authentication method details of the key per user.

Security key Authenticator Attestation GUID (AAGUID)

The FIDO2 specification requires each security key provider to provide an Authenticator Attestation GUID (AAGUID) during attestation. An AAGUID is a 128-bit identifier indicating the key type, such as the make and model.

The process with FIDO keys.

1. The user plugs the FIDO2 security key into their computer.
2. Windows detects the FIDO2 security key.
3. Windows sends an authentication request.
4. Azure AD sends back a nonce.
5. The user completes their gesture to unlock the private key stored in the FIDO2 security key’s secure enclave.
6. The FIDO2 security key signs the nonce with the private key.
7. The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
8. Azure AD verifies the signed nonce using the FIDO2 public key.
9. Azure AD returns PRT to enable access to on-premises resources.

Sign in with passwordless credential

In the example below a user has already provisioned their FIDO2 security key. The user can choose to sign in on the web with their FIDO2 security key inside of a supported browser on Windows 10 version 1903 or higher.

Microsoft Authenticator

Note! First you have to enable combined security information registration https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-registration-mfa-sspr-combined

You can also allow your employee’s phone to become a passwordless authentication method. You may already be using the Microsoft Authenticator App as a convenient multi-factor authentication option in addition to a password. You can also use the Authenticator App as a passwordless option.

There is the same options as with FIDO keys, but there is the configuration available under the three famous dots.

Authentication modes

And here you can choose the authentication modes.

And the user experience after enabling passwordless

The flow for the authentication

And the process

1. The user enters their username.
2. Azure AD detects that the user has a strong credential and starts the Strong Credential flow.
3. A notification is sent to the app via Apple Push Notification Service (APNS) on iOS devices, or via Firebase Cloud Messaging (FCM) on Android devices.
4. The user receives the push notification and opens the app.
5. The app calls Azure AD and receives a proof-of-presence challenge and nonce.
6. The user completes the challenge by entering their biometric or PIN to unlock private key.
7. The nonce is signed with the private key and sent back to Azure AD.
8. Azure AD performs public/private key validation and returns a token.

If you will choose passwordless logins to your services you dont have to be concerned about password inside those services that support it. If you integrate logins to apps thru Azure AD app registrations it will be a lot easier to use them and you would have a single pane to login and only one identity to login with.

Configure and deploy self-service password reset

Installing Identity Protection Proxy

First you have to enable Password Writeback, it’s not mandatory just preffered because then you can use self-service password reset from the cloud but and also use the same password on-premises.

When config is done you have to run sync cycle.

Deploy and manage password protection

Enable on-premises protection from Security -> Authentication methods and add some password that are considered bad for your organization.

Browse to https://www.microsoft.com/en-us/download/details.aspx?id=57071 and download both packages from there.

When you get them installed do a reboot and then you can check that the services are running.

There are audit and enforce modes available.

Audit mode

Audit mode is intended as a way to run the software in a “what if” mode. Each Azure AD Password Protection DC agent service evaluates an incoming password according to the currently active policy.

If the current policy is configured to be in audit mode, “bad” passwords result in event log messages but are processed and updated. This behavior is the only difference between audit and enforce mode. All other operations run the same.

Enforced Mode

Enforced mode is intended as the final configuration. Like when in audit mode, each Azure AD Password Protection DC agent service evaluates incoming passwords according to the currently active policy. When enforced mode is enabled though, a password that’s considered insecure according to the policy is rejected.

When a password is rejected in enforced mode by the Azure AD Password Protection DC agent, an end user sees a similar error like they would see if their password was rejected by traditional on-premises password complexity enforcement. For example, a user might see the following traditional error message at the Windows logon or change password screen:

“Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.”

This message is only one example of several possible outcomes. The specific error message can vary depending on the actual software or scenario that is attempting to set an insecure password.

Affected end users may need to work with their IT staff to understand the new requirements and to choose secure passwords.

Azure AD smart lockout

You can then enable smart lockout, but make sure that your Azure AD smart lockout duration to be higher than AD DS, then Azure AD would be 120 seconds (2 minutes) while your on-premises AD is set to 1 minute (60 seconds). If you want your Azure AD lockout threshold to be 5, then you want your on-premises AD lockout threshold to be 10. This configuration would ensure smart lockout prevents your on-premises AD accounts from being locked out by brute force attacks on your Azure AD accounts.

Lockout policy

1. Open the Group Policy Management tool.
2. Edit the group policy that includes your organization’s account lockout policy, such as, the Default Domain Policy.
3. Browse to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
4. Verify your Account lockout threshold and Reset account lockout counter after values.

Trying out Self-Service password reset

Logon to https://aka.ms/sspr

And it will offer you options to verity that you are you (of course you have MFA in-place as it will block 99,9% of phishing, right?)

So I choose Authenticator and it went thru, now it will ask the second method to verify you.

and when it finished, you done.

Tenant restrictions

Set up tenant restrictions

There are two steps to get started with tenant restrictions. First, make sure that your clients can connect to the right addresses. Second, configure your proxy infrastructure.

URLs and IP addresses

To use tenant restrictions, your clients must be able to connect to the following Azure AD URLs to authenticate:

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Additionally, to access Office 365, your clients must also be able to connect to the fully qualified domain names (FQDNs), URLs, and IP addresses defined in Office 365 URLs and IP address ranges.

Proxy configuration and requirements

The following configuration is required to enable tenant restrictions through your proxy infrastructure. This guidance is generic, so you should refer to your proxy vendor’s documentation for specific implementation steps.

Prerequisites

• The proxy must be able to perform TLS interception, HTTP header insertion, and filter destinations using FQDNs/URLs.
• Clients must trust the certificate chain presented by the proxy for TLS communications. For example, if certificates from an internal public key infrastructure (PKI) are used, the internal issuing root certificate authority certificate must be trusted.
• Azure AD Premium 1 licenses are required for use of Tenant Restrictions.

Configuration

For each outgoing request to login.microsoftonline.com, login.microsoft.com, and login.windows.net, insert two HTTP headers: Restrict-Access-To-Tenants and Restrict-Access-Context.

Do not include subdomains under *.login.microsoftonline.com in your proxy configuration

End-user experience

Admin experience

Under there You can see the restricted logons.

Things to remember

Something you possess – which might be a mobile app that receives a notification or a token-generating device like FIDO2 key.

Something you are – which typically is a biometric property, such as a fingerprint or face scan used on many mobile devices.

Security key Authenticator Attestation GUID (AAGUID)

Microsoft Authentication and FIDO2 are both disabled by default.

Azure AD Password Protection has Audit and Enforced Modes.

Custom password list allows you to enter up to 1000 items. Just add keywords not containing different symbols, different variants are created automatically.

Tenant restriction HTTP headers to add: Restrict-Access-To-Tenants and Restrict-Access-Context.

Link to main post