KeySignTest Failure & Device Registration

This week I got involved in an issue where the user could not access Microsoft Teams due to our Conditional Access policy. Our requirements are quite simple: devices must be compliant or domain joined.

(TLDR: If you see a KeySignTest failure from dsregcmd /status check the status of the TPM chip using tpm.msc.)

I expect most people are familiar with a typical CA failure like the one below?

The interesting part of this problem is that the user told us he was attempting to access teams from a corporate laptop joined to our on-premises domain and as a result Hybrid Joined.

Checking the Azure sign-in logs is a great place to start when analysing CA problems. To display the information I’m interested in I filtered on the users name, application being accessed (Microsoft Teams) the client app used (Mobile Apps and Desktop Clients and the status (Failure):

More detail can be obtained by exploring the sign-in record. The basic information tab shows me that the device is not compliant:

The Conditional Access tab tells me the same story and would help surface session control information if they were being used:

The Troubleshooting and support section has an excellent feature where we can raise a support request directly from Azure AD with the added bonus of providing an easy way to add the request ID of the failed sign-in to the ticket:

At this point we have established that a Hybrid Joined Device is being tagged as non-compliant and therefore access to Teams via the desktop application is not permitted…to find out further information the next step is to run dsregcmd /status on the affected system – of particular note was that the KeySignTest had failed, notice that the KeyProvider is the MS Platform Crypto Provider:

The MS Platform Crypto Provider is essentially the hardware TPM chip. This encouraged me to find out more about out how the TPM is used during device registration.

The best information I could find on how a Windows 10 device is registered with Azure AD is by Jairo Cadena. A very brief breakdown of Jairo’s post is:

  1. Group Policy is (usually) used to begin auto-registration with Azure AD
  2. The device queries the on-premises AD to discover the tenant ID and tenant domain name
  3. The device authenticates itself to Azure AD via ADFS (or directly to Azure if ADFS is not used) to obtain a token for registration
  4. The device generates keys used for device registration
  5. Azure AD registration is completed via the Device Registration Service

The important area for me and the Teams CA issue is step 4, where keys are generated for device registration. A more detailed post from Jairo covers this brilliantly, and I have attempted to summarise his main points below:

  1. Key pairs are generated for the device certificate.
  2. A certificate signing request (CSR) is generated using the key pair above.
  3. A Second key pair is created – this will be used to bind SSO tokens physically to the device when authenticating to Azure AD. This key is called the storage/transport key (Kstk) and is derived from the Storage Root Key of the TPM.
  4. A device registration request is sent to Azure DRS sending along the ID token, the CSR and the public portion of the storage/transport key along with its attestation data.
  5. Once the request reaches Azure DRS, the token is validated and a corresponding device object is created in Azure AD.
  6. Finally, a certificate is created and sent back to the device.

PowerShell can be used to check for the presence of this certificate & Jairo helps again by providing this command in his post:

dir Cert:\LocalMachine\My\ | Where-Object { $_.Issuer -match "CN=MS-Organization-Access" } | Format-List

My output in PowerShell:

Or you can view the cert in certificate manager:

So, with this information it’s clear that the TPM is an important component in the device registration process and it’s also used to enable SSO post registration. If the device has a TPM chip it will be used to securely generate the key pairs, if not the registration process should try to fall back to the software key provider.

Moving back to discovering the root cause of the Teams CA issue…I checked the TPM status of the remote machine using tpm.msc and found that the TPM status was “not ready for use”:

I’m guessing that during initial registration the process attempted to use the physical TPM but was unable to do so, and the process was not able to fall back to use the software key storage provider. Once I enabled the TPM, device registration was successful but note that the KeyProvider is now using the Software Key Storage Provider instead:

Whilst not a perfect solution (as we are not using the physical TPM to generate keys – which is more secure) the user can now successfully sign into Microsoft Teams, satisfying the Conditional Access policy:

Given more time to access this remote system I would like to try to re-register with Azure AD, I’m confident that next time the physical TPM will be used 🙂

Thanks for reading.

Further reading::

https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/how-windows-uses-the-tpm

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/device-registration-technical-reference

https://s4erka.wordpress.com/tag/dsregcmd/

Leave a reply:

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Site Footer