Identification & Authentication

  • 7 minutes to read

Overview

Identify Users & Managed Identities

All User and managed identities in Microsoft 365 are managed using Azure Active Directory.

Azure Active Directory (Azure AD) access reviews enable organizations to efficiently manage group memberships, access to enterprise applications, and role assignments. User’s access can be reviewed on a regular basis to make sure only the right people have continued access. Access reviews automate the process of controlling user and administrative rights and are accomplished via the steps below:

  1. Sign in to the Azure portal (GCC-High) and open the Identity Governance page.
  2. In the left menu, click Access reviews.
  3. Click New access review to create a new access review.
  4. Name the access review and provide a description for the reviewers.
  5. Select the start date. The end date defaults to 30 days out.
  6. To make the access review recurring, change the Frequency setting from One time to Weekly, Monthly, Quarterly or Annually.
  7. In the Users section, specify the users that the access review applies to.
  8. In the Groups section, select one or more groups that you would like to review membership of.
  9. In the Reviewers section, select either one or multiple people to review all the users in scope.
  10. Set Upon completion settings to specify what happens (No change, Remove access, Approve access or Take recommendations) after a review completes then click Start.

This process initiates the access review. For more information, see Create an access review of groups and applications in Azure AD access reviews.

Perform User Authentication

All Microsoft 365 services and enrolled devices require authentication using Azure Active Directory (AAD).

Enforce Password Complexity

Security Baseline: The following password policy is enforced for all users:
Password length: Minimum 8 characters – max 256
Password complexity: Three out of the four following, lowercase, uppercase, number & symbol
Password history: Last password can’t be used again
Password reset history: Last password can be used when the user has forgotten the password.
Lockout threshold: 10 (the account is locked after 10 failed login attempts)
Lockout duration: 60 seconds

Prohibit Password Reuse

Azure AD password policy does not allow for password reuse.

Leverage Temporary Passwords

Temporary passwords are an important part of password reissue. If an administrator assigns a user’s permanent password, they will then have access to the account. If the permanent password was provided to the user insecurely an attacker might be able to intercept it. Temporary passwords mitigate this challenge. When an administrator resets a user’s password or when a user requests a self-service password reset, a temporary one-time password (OTP) is issued. This password allowed a user to sign-in only once to reset their password. You can reset a user’s password in Azure Active Directory and issue a temporary password via the steps below. For more information, see Reset a user’s password using Azure Active Directory.

  1. Sign into the Azure portal as a user administrator, or password administrator.
  2. Select Azure Active Directory, select Users, search for and select the user that needs the reset, and then select Reset Password.
  3. In the Reset password page, select Reset password. When using Azure Active Directory, a temporary password is auto generated for the user.
     
    Copy the temporary password and securely transmit to the user. The user will be required to change the password during the next sign-in process.

Obscure Authentication Feedback

This requirement is geared towards mitigating shoulder-surfing. If my password is displayed while I’m signing into an information system, someone might be able to look over my shoulder to steal my password.

By default, Azure Active Directory obscures all passwords by default and below is an example. In this example, John Doe has typed his password, but the characters are masked for security. John would only be able to view his typed password for verification by scrolling to the far right of the bar and selecting the hidden eye icon. Selecting anything else, even a right click will automatically move the password back to masked characters. For more information, see Azure Active Directory fundamentals documentation.

Implement Multi-Factor Authentication

Implementing Multi-Factor Authentication is arguably one of the strongest controls to protect identity and access management in the cloud. This ensures the user making the authentication request is who they say they are, because the user must input an additional token which is generated on another device they own.

Azure AD MFA for Microsoft Apps & Services

Azure Active Directory provides the capabilities to set granular authentication controls for users, applications and services. Multi-factor authentication is enforced and requires users to register multiple authentication methods. Those authentication methods are:

  • Password
  • Microsoft Authenticator App
  • SMS text message
  • Voice Call

Security Baseline: MFA is enforced for all Azure AD cloud applications and services using the conditional access policy, NIST - GRANT - MFA For All Users

It’s important to note that Azure AD MFA does not apply to your device login, ie. Windows desktop. For device level multi-factor authentication, Windows Hello for Business is configured and enforced.

Device MFA

Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Windows Hello for Business combined with Azure Active Directory joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential.

Employ Replay-Resistant Authentication

Azure Active Directory provides configurations to enforce replay-resistant authentication. This prevents attackers from sniffing authentication attempts and replaying the password for unauthorized authentication. The TokenReplayCache is used to prevent the replay of Active Directory Authentication Library (ADAL) authentication tokens. The TokenReplayCache property allows application developers to define a token replay cache, a store that can be used for saving tokens for the purpose of verifying that no token can be used more than once.

This is a measure against a common attack, the aptly called token replay attack: an attacker intercepting the token sent at sign-in might try to send it to the app again (“replay” it) for establishing a new session. E.g., In OIDC code-grant flow, after successful user authentication, a request to “/signin-oidc” endpoint of the relying party is made with “id_token”, “code” and “state” parameters.