Administering Authentication Methods (FIDO2/Passwordless)

Issues with passwords:

• People get phished
• People use the same password for many systems

Passwordless Based Authentication

Passwordless authentication methods are more convenient because the password is removed and replaced with something you have, plus something you are or something you know.

Azure and Azure Government offer the following three Passwordless authentication options:

1. Windows Hello for Business:
   – ideal for users with their own designated computer
   – biometric and pin credentials are tied to users pc
   – with Public Key Infrastructure (PKI) integration and built in SSO support, it provides convenient access for cloud services

2. Microsoft Authenticator app
   – allow your employees phone to become a Passwordless authentication method
3. Fast Identity Online (FIDO2) security keys
   – This is an open standard for Passwordless authentication
   – this is a hardware device that handles authentication
   – Users use an external security usb key to authenticate.

Implementing an Authentication Solution based on Windows Hello for Business

Using InTune

1. Go to endpoint.microsoft.com (InTune) -> Devices -> Enrol Devices -> Windows Hello for Business
2. The options here are:
   – enable Windows Hello for Business
   – set PIN options (max length, special characters etc…)
   – Use TPM (required or preferred)
   – allow biometrics
   – Enable enhanced anti-spoofing
   – Allow security keys (FIDO2)

Devices must first be joined to Azure AD

Within Windows 10

• Go to Accounts -> Sign in options
• Here you can set up PIN and biometrics

Enabling the FIDO2 based Security Method in Azure AD

1. Go to Azure AD -> Security -> Authentication Methods
2. Click on FIDO2
3. Click on Enable
4. specify which users you want to be able to use this option
5. Click on Configure for more options:
   – allow self-service set up
   – enforce attestation (only approved keys will work)
   – Restrict certain keys (you need the AAGUID for the key you want to restrict)

Password protection within Azure AD, and Smart Lockout On-Premise ADDS

Password Settings/Policies for cloud only users

In M365 Portal

• Go to M365 Admi portal -> Settings ->Org settings -> security and privacy
• Click on ‘Password expiration policy’
• Here you can turn on password expiration (its off by default) and when to expire them (default is 90 days). You can set how many days to notify a user before it expires

In Azure Portal:

• Go to Azure AD -> Security -> Authentication methods -> Password protection
• Here you can set the following settings:
  – Lockout threshold: how many times they can incorrectly enter a password before getting locked out
  – lockout duration in seconds
  – Banned passwords list: enter a list of passwords that are banned
  – Enable password protection on windows Server Active Directory_
  – Mode: Enforced (its on for people), Audit (its just logging)

Password Settings/Policies for on premise AD

• Open Group Policy Management
• These settings are in: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy
• Settings here include:
  – password history (don’t allow users reuse passwords)
  – Max password age (when password needs to be changed in days)
  – Min password age (how long users must keep a password before they can change it)
  – Password length (in characters)
  – Complexity requirements (include numbers, uppercase, symbol etc…)
• Account Lockout policy: lets you set the threshold, duration etc…

Configuring and Deploying Self Service Password Reset(SSPR)

Note: Administrators can use this but only with MFA

Hybrid Environment

If running Hybrid environment you must have password writeback enabled in Azure AD connect to be able to change passwords in Azure.

You must have premium Azure licences to enable SSPR with writeback to on premise AD.

Configuring SSPR

1. Go to Azure AD ->Users ->Password Reset
2. From here you can enable SSPR
3. Select which users or groups to apply it to
4. Number of methods required to meet: you can select the number of ways a person must be able to prove themselves (email, phone, security questions, authenticator app etc…)
5. Security questions: you can select how many questions a user needs to answer and which questions they are. You can add custom questions

Implementing and Managing Tenant Restrictions

This is a way of restricting users from logging in to other Organisations M365 tenants when on your network. You need a proxy device to enforce this.

How it works

The overall solution comprises the following components:

1. Azure AD: If the Restrict-Access-To-Tenants: <permitted tenant list> header is present, Azure AD only issues security tokens for the permitted tenants.
2. On-premises proxy server infrastructure: This infrastructure is a proxy device capable of Transport Layer Security (TLS) inspection. You must configure the proxy to insert the header containing the list of permitted tenants into traffic destined for Azure AD.
3. Client software: To support tenant restrictions, client software must request tokens directly from Azure AD, so that the proxy infrastructure can intercept traffic. Browser-based Microsoft 365 applications currently support tenant restrictions, as do Office clients that use modern authentication (like OAuth 2.0).
4. Modern Authentication: Cloud services must use modern authentication to use tenant restrictions and block access to all non-permitted tenants. You must configure Microsoft 365 cloud services to use modern authentication protocols by default. For the latest information on Microsoft 365 support for modern authentication, read Updated Office 365 modern authentication.

From <https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions>