One of the benefits of Windows 10 devices that are registered with Azure AD is the convenience and security that comes with Windows Hello and Microsoft Passport for Work. In this post I’ll delve into the technology of Microsoft Passport for Work with Azure AD and how it relates to devices and strong user authentication.
Microsoft Passport for Work is supported on all three types of devices registered with Azure AD to authenticate to work apps. In this post I will focus primarily on Azure AD joined and domain joined devices.
Quick note on personal devices
For Windows personal devices running the November 2015 update, Microsoft Passport for Work is limited to protecting certificates for traditional apps (like VPN) with the associated user’s gesture that unlocks the credential (read further in this post for details). These certificates are deployed typically by the Mobile Device Management (MDM) system.
The Microsoft Passport for Work provisioning experience won’t show up during Add Work or School Account unless an MDM has been configured in Azure AD for auto-enrollment. In this case, a user working on the device won’t authenticate to Azure AD using the Microsoft Passport for Work credential. A future update of Windows will have this support.
On the other hand, the credential in a Windows 10 device (including personal devices), can be used to remotely authenticate to an Azure AD joined or domain joined device. For more information please look for a future post about Microsoft Passport for Work 2Go: using your phone to authenticate to Windows.
There is a problem today with passwords. They are easy to clone and easy to steal. Issues in their implementation make them insecure, and users have a hard time balancing convenience and security. Users typically find “workarounds” to make their life easier when facing security requirements (e.g. a complex password may end up being written in some unsecure location).
Microsoft Passport for Work replaces user passwords with strong device-bound user credentials protected by a user’s gesture (a PIN or a biometric gesture like fingerprint or facial recognition i.e. Windows Hello).
For more details on the problems of passwords please see Problems with traditional credentials section in the Microsoft Passport guide we recently published in TechNet.
The Microsoft Passport for Work credential
The credential is an asymmetric key (private-public key pair) with their private key stored securely in the device in the Trusted Platform Module (TPM), and its corresponding public key securely registered with Azure AD. In the absence of a TPM the keys are software generated and stored encrypted.
The private key does not leave its secure location (if TPM available), it is not known to Azure AD or AD and it never goes into the network. It is only accessible by a gesture that the user knows (a PIN) or the user “is” (bio-gesture) which protects the key cryptographically by encrypting it using a “Hello”. A Hello is an authenticator which is unique to the gesture, the device and the user.
The public key is registered securely with Azure AD after both the device and the user have authenticated. The user must strongly authenticate by providing a second factor of authentication. This is important because the Microsoft Passport for Work credential is considered a strong credential when authenticating to Azure AD. The credential meets multi-factor authentication (MFA) policy and tokens obtained with this credential will have a corresponding related claim.
Once the credential is provisioned, it is used for authentication to Azure AD.
Provisioning the Microsoft Passport for Work credential
All starts with a device becoming registered with Azure AD. A device needs to be Azure AD joined, domain joined (which has auto-registered with Azure AD) or configured with Add Work or School Account before holding a Microsoft Passport for Work credential.
After an Azure AD joined or domain joined device has completed registration, on the next user sign-in to Windows the Microsoft Passport for Work provisioning experience will show up. Registration of the public key with Azure AD happens through the Azure Device Registration Service (Azure DRS).
This experience is a web driven experience rendered in the Cloud eXperience Host (CXH), a special host with access to particular WinRT APIs in the system. This is the same host that is used to render the experience for Azure AD Join.
The experience is launched after the user signs in to Windows if the following conditions are true:
- Microsoft Passport for Work policy signals provisioning. This means either of the following conditions:
- The device is Azure AD joined and Microsoft Passport for Work policy is not disabled (read it: in the absence of the policy being set the default behavior is to provision the credential).
- The device is domain joined and policy is enabled (read it: in the absence of the policy being set the default behavior is to NOT provision the credential). This is because there is preparation needed in the on-premises infrastructure for a domain joined device to be able to authenticate to a domain controller (DC) using the credential. After the required setup is made, the org. can enable the policy. I’ll mention some considerations about supporting AD on-premises authentication later in the post.
- The current session is not a remote session. Note that this doesn’t mean that Microsoft Passport Provisioning for Work won’t happen on virtual machines (VMs), but just that the provisioning experience won’t show up if the user is connected to the VM or physical device via a Remote Desktop Services (RDS) session (which includes connecting to the computer using Hyper-V Enhanced Session Mode, so you know in case you want to try this in your lab on a Hyper-V host).
Once the conditions listed above are met the user will see the provisioning experience. The experience is hosted in the following location:
The user will see the following page:
Once the user clicks on the ‘Create PIN’ button a WinRT API part of dsreg.dll is called. This registration API performs two operations: 1) authenticates the current user to get a token to Azure DRS, and 2) generates the key pair and registers the public key with Azure DRS using the token obtained in (1).
(1) Authentication of user to Azure DRS
The registration API will first obtain an access token to register with Azure AD the public key that is about to be generated. The token is intended to Azure DRS which registers the public key with the corresponding user and relates it to the corresponding device object. To obtain the token, the API uses the Web Account Manager API:
This API invokes the corresponding implementation for the Azure AD plug-in. For more information on the Web Account Manager and its Azure AD plug-in please look for a future post about How SSO works in Windows 10.
Users will see an MFA challenge depending on some conditions:
- Users on domain joined devices will see an MFA prompt. This is using username and password credentials. Please note that the November 2015 update of Windows 10 doesn’t support Microsoft Passport for Work provisioning if the user has signed into Windows using a physical or virtual smart-card. We will add this support in a future update of Windows.
- Users on Azure AD joined devices will NOT see an MFA prompt if the user joined the device in the first place and provided MFA at the time of join (the attribute ‘RegisteredOwners’ on the device object holds this user). Azure AD will treat the device as a second factor of authentication if the device was registered with MFA for the user who joined it. Please note that this is current service behavior as of the publishing date of this post. We have received mixed feedback about regarding registered devices as MFA. In the future we may allow it under a setting that organizations can control.
- Users on Azure AD joined devices who did not join the device will see an MFA prompt.
For a federated organization the MFA challenge can come from Azure AD or from their internal STS (e.g. AD FS):
After the user authenticates and the API obtains the token, it then proceeds to generate and register the Microsoft Passport for Work keys.
(2) Microsoft Passport for Work keys generation and registration with Azure AD
The registration API relies on the Microsoft Passport crypto API (part of ncrypt.dll) to generate the key and to obtain attestation data if available. Please note that the current implementation of the client and service doesn’t support attestation validation yet. We will enable this functionality in a future update of the service and/or Windows.
The keys are generally not created at this moment but obtained from a pool of keys previously generated. Pre-generation of multiple keys happens upon boot of the device and occurs in the background. Given that these are RSA 2048 bit key pairs, depending on the TPM these may take some time to generate.
After the key pair is obtained, the PIN collection UI shows up and the user is asked for a PIN. A logical container is created and the private key is placed in it:
A container is a logical grouping of key material protected by a protector key which is associated with a gesture. In this case the PIN is associated with a protector key that is obtained at this time. This key securely wraps the Microsoft Passport for Work private key recently obtained. The PIN gesture is the one that can “open” the container and allow access to the key.
About key attestation
As I mentioned above, attestation validation is not yet implemented, however let me provide details on some of the mechanics behind attestation generation. Along with the corresponding public key, its related attestation data, if available, is also obtained using the crypto API. The attestation data consists of the Attestation Identity Key (AIK) certificate and a blob holding information about the user and the Microsoft Passport for Work key generated. The blob is signed by the AIK which is a special purpose RSA key that allows the TPM to offer platform authentication. The AIK in conjunction with the Endorsement Key (EK) and its certificate (from the manufacturer) is sent to Azure Certificate Services to generate the AIK certificate which has a trust that chains up to the TPM manufacturer. This trust chain is what the service will validate upon key registration.
The registration API will now take the Azure DRS access token and the key information and post it to Azure DRS to the following end-point:
Azure DRS will find the user object in the directory and add the key information to a particular multi-valued attribute. The key information will contain a reference to the device ID (both user and device IDs are obtained from the token). A user object will have one key for every device where the user has provisioned a Microsoft Passport for Work credential.
About the user’s devices UI in the Azure management portal
One more thing that may be of interest. The UI in the Azure management portal that shows devices for a given user includes devices that the user has registered in a self-service manner (via Azure AD Join or Add Work or School Account). Windows 10 domain joined devices won’t show up given that no user participates in the registration of the device with Azure AD… except, if the user has provisioned a Microsoft Passport for Work credential, the domain joined device will show up in the UI under the user’s devices.
Authentication using the Microsoft Passport for Work credential
Finally after the credential has been provisioned it can be used to authenticate to Azure AD and to AD on-premises upon sign-in to Windows. For details on how this is accomplished please look for a future post on How SSO works in Windows 10.
Authentication to AD on-premises
In terms of the support of Microsoft Passport for Work authentication against AD on-premises, the device needs to be able to reach a DC running Windows Server 2016 (as of the date of this post it is in Technical Preview 4). There is no need to have a new Domain or Forest Functional Level in the on-premises AD.
As an alternative to deploying new DCs, logon certificates using the Microsoft Passport for Work key can be deployed. In this case down-level DCs will use the certificate for authentication (as it is today with virtual smart-cards) and users will enjoy the benefits of Windows Hello. Please note that in this case Azure AD will continue using the key for authentication.
To support logon certificates using the Microsoft Passport for Work key, it is required to have System Center Configuration Manager Technical Preview (domain joined devices) or Intune (Azure AD joined devices) (additional 3rd party MDMs may have this support as well).
For more details on deployment requirements to enable authentication to on-premises AD please see section Deployment requirements in the Microsoft Passport guide in TechNet. Please also refer to related TechNet documentation here for more resources.
Once again, thanks for reading this far and being interested in these features. Please let me know your questions or comments you have.
Until next time,
Jairo Cadena (Twitter: @JairoC_AzureAD)