What is Azure Active Directory authentication?
One of the main features of an identity platform is to verify, or authenticate, credentials when a user signs in to a device, application, or service. In Azure Active Directory (Azure AD), authentication involves more than just the verification of a username and password. To improve security and reduce the need for help desk assistance, Azure AD authentication includes the following components:
- Self-service password reset
- Azure AD Multi-Factor Authentication
- Hybrid integration to write password changes back to on-premises environment
- Hybrid integration to enforce password protection policies for an on-premises environment
- Passwordless authentication
Take a look at our short video to learn more about these authentication components.
Improve the end-user experience
Azure AD helps to protect a user's identity and simplify their sign-in experience. Features like self-service password reset let users update or change their passwords using a web browser from any device. This feature is especially useful when the user has forgotten their password or their account is locked. Without waiting for a helpdesk or administrator to provide support, a user can unblock themselves and continue to work.
Azure AD Multi-Factor Authentication lets users choose an additional form of authentication during sign-in, such as a phone call or mobile app notification. This ability reduces the requirement for a single, fixed form of secondary authentication like a hardware token. If the user doesn't currently have one form of additional authentication, they can choose a different method and continue to work.
Passwordless authentication removes the need for the user to create and remember a secure password at all. Capabilities like Windows Hello for Business or FIDO2 security keys let users sign in to a device or application without a password. This ability can reduce the complexity of managing passwords across different environments.
Self-service password reset
Self-service password reset gives users the ability to change or reset their password, with no administrator or help desk involvement. If a user's account is locked or they forget their password, they can follow prompts to unblock themselves and get back to work. This ability reduces help desk calls and loss of productivity when a user can't sign in to their device or an application.
Self-service password reset works in the following scenarios:
- Password change - when a user knows their password but wants to change it to something new.
- Password reset - when a user can't sign in, such as when they forgot password, and want to reset their password.
- Account unlock - when a user can't sign in because their account is locked out and want to unlock their account.
When a user updates or resets their password using self-service password reset, that password can also be written back to an on-premises Active Directory environment. Password writeback makes sure that a user can immediately use their updated credentials with on-premises devices and applications.
Azure AD Multi-Factor Authentication
Multi-factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan.
If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, is it really the user signing in with the username and password, or is it an attacker? When you require a second form of authentication, security is increased as this additional factor isn't something that's easy for an attacker to obtain or duplicate.
Azure AD Multi-Factor Authentication works by requiring two or more of the following authentication methods:
- Something you know, typically a password.
- Something you have, such as a trusted device that is not easily duplicated, like a phone or hardware key.
- Something you are - biometrics like a fingerprint or face scan.
Users can register themselves for both self-service password reset and Azure AD Multi-Factor Authentication in one step to simplify the on-boarding experience. Administrators can define what forms of secondary authentication can be used. Azure AD Multi-Factor Authentication can also be required when users perform a self-service password reset to further secure that process.
By default, Azure AD blocks weak passwords such as Password1. A global banned password list is automatically updated and enforced that includes known weak passwords. If an Azure AD user tries to set their password to one of these weak passwords, they receive a notification to choose a more secure password.
To increase security, you can define custom password protection policies. These policies can use filters to block any variation of a password containing a name such as Contoso or a location like London, for example.
For hybrid security, you can integrate Azure AD password protection with an on-premises Active Directory environment. A component installed in the on-premises environment receives the global banned password list and custom password protection policies from Azure AD, and domain controllers use them to process password change events. This hybrid approach makes sure that no matter how or where a user changes their credentials, you enforce the use of strong passwords.
The end-goal for many environments is to remove the use of passwords as part of sign-in events. Features like Azure password protection or Azure AD Multi-Factor Authentication help improve security, but a username and password remains a weak form of authentication that can be exposed or brute-force attacked.
When you sign in with a passwordless method, credentials are provided by using methods like biometrics with Windows Hello for Business, or a FIDO2 security key. These authentication methods can't be easily duplicated by an attacker.
Azure AD provides ways to natively authenticate using passwordless methods to simplify the sign-in experience for users and reduce the risk of attacks.
Web browser cookies
When authenticating against Azure Active Directory through a web browser, multiple cookies are involved in the process. Some of the cookies are common on all requests, other cookies are specific to some particular scenarios, i.e., specific authentication flows and/or specific client-side conditions.
Persistent session tokens are stored as persistent cookies on the web browser's cookie jar, and non-persistent session tokens are stored as session cookies on the web browser and are destroyed when the browser session is closed.
|ESTSAUTH||Common||Contains user's session information to facilitate SSO. Transient.|
|ESTSAUTHPERSISTENT||Common||Contains user's session information to facilitate SSO. Persistent.|
|SignInStateCookie||Common||Contains list of services accessed to facilitate sign-out. No user information. Security feature.|
|CCState||Common||Contains session information state to be used between Azure AD and the Azure AD Backup Authentication Service.|
|buid||Common||Tracks browser related information. Used for service telemetry and protection mechanisms.|
|fpc||Common||Tracks browser related information. Used for tracking requests and throttling.|
|esctx||Common||Session context cookie information. For CSRF protection. Binds a request to a specific browser instance so the request can't be replayed outside the browser. No user information.|
|ch||Common||ProofOfPossessionCookie. Stores the Proof of Possession cookie hash to the user agent.|
|ESTSSC||Common||Legacy cookie containing session count information no longer used.|
|ESTSSSOTILES||Common||Tracks session sign-out. When present and not expired, with value "ESTSSSOTILES=1", it will interrupt SSO, for specific SSO authentication model, and will present tiles for user account selection.|
|AADSSOTILES||Common||Tracks session sign-out. Similar to ESTSSSOTILES but for other specific SSO authentication model.|
|ESTSUSERLIST||Common||Tracks Browser SSO user's list.|
|SSOCOOKIEPULLED||Common||Prevents looping on specific scenarios. No user information.|
|cltm||Common||For telemetry purposes. Tracks AppVersion, ClientFlight and Network type.|
|x-ms-gateway-slice||Common||Azure AD Gateway cookie used for tracking and load balance purposes.|
|stsservicecookie||Common||Azure AD Gateway cookie also used for tracking purposes.|
|x-ms-refreshtokencredential||Specific||Available when Primary Refresh Token (PRT) is in use.|
|estsStateTransient||Specific||Applicable to new session information model only. Transient.|
|estsStatePersistent||Specific||Same as estsStateTransient, but persistent.|
|ESTSNCLOGIN||Specific||National Cloud Login related Cookie.|
|UsGovTraffic||Specific||US Gov Cloud Traffic Cookie.|
|ESTSWCTXFLOWTOKEN||Specific||Saves flowToken information when redirecting to ADFS.|
|CcsNtv||Specific||To control when Azure AD Gateway will send requests to Azure AD Backup Authentication Service. Native flows.|
|CcsWeb||Specific||To control when Azure AD Gateway will send requests to Azure AD Backup Authentication Service. Web flows.|
|Ccs*||Specific||Cookies with prefix Ccs*, have the same purpose as the ones without prefix, but only apply when Azure AD Backup Authentication Service is in use.|
|threxp||Specific||Used for throttling control.|
|rrc||Specific||Cookie used to identify a recent B2B invitation redemption.|
|debug||Specific||Cookie used to track if user's browser session is enabled for DebugMode.|
|MSFPC||Specific||This cookie is not specific to any ESTS flow, but is sometimes present. It applies to all Microsoft Sites (when accepted by users). Identifies unique web browsers visiting Microsoft sites. It's used for advertising, site analytics, and other operational purposes.|
Cookie definitions and respective names are subject to change at any moment in time according to Azure AD service requirements.
To learn more about self-service password reset concepts, see How Azure AD self-service password reset works.
To learn more about multi-factor authentication concepts, see How Azure AD Multi-Factor Authentication works.