Modules
Sign in
New Request

Using a Windows Logon Agent on an Azure AD joined machine

Question

 

How do I use a Windows Logon Agent on an Azure AD-joined machine?

 

Answer

Prerequisites:
1. A machine that has been Azure Active Directory joined with your user account myusername@federateddomain.com
2. You have configured office 365 federation with Passly
3. You have an account in Passly that is connected to the AAD account yusername@federateddomain.com
4. The user account in Passly has a 2fa token registered (push or OTP – u2f not compatible)
5. The user account in Passly has either a username or an alternate principal name of myusername@federateddomain.com

When signing in to the machine you will need to enter the following:
azuread\myusername@federateddomain.com
mceclip1.png

AzureAD is the domain windows automatically maps the account to when setting up AAD join on the machine

Prerequisite #5 is critically important. Your Passly account REQUIRES a username or an alternate principal name of myusername@federateddomain.com otherwise the WLA will not be able to map your account for 2fa.

Since it’s possible to set the office 365 mapping to use an email address, the machine login and Passly login may not match which is when the alternate principal name would be required

Example:
Your Passly username is “myusername”
The machine/WLA requires a full username AzureAD\myusername@federateddomain.com
you add an alternate principal name to the account in Passly “myusername@federateddomain.com”
You log in to the machine using AzureAD\myusername@federateddomain.com with your PASSLY password.
You are prompted for 2fa.
You are signed into the machine

Changing your password

When the user changes their password in Passly, on the next machine login azure AD reaches out to Passly to renegotiate authentication using the organization policy via the WS Trust Protocol with mixed credentials (the machine/AAD forward the username and password to Passly with the configured federation information). After that's successful the OS stores the successful login info used.

Depending on your organization policy (if it requires 2fa) you can experience double push notifications after you changed your password and are signing into your machine for the first time afterward.

If you want to submit an OTP instead of receiving a 2fa push on your first login after changing your password you must enter the password and OTP both into the password field separated by a comma. This is totally unintuitive but is ultimately all we can do since federation is limited to the WS trust protocol in a machine logon scenario (Windows control this behavior and we cannot override it unless we change how the WLA handles password validation).

If your only 2fa device is via U2F you will be unable to log in if your organization requires 2fa after changing your password.

Sample user experience:

  • I changed my password in Passly
  • I signed into the machine with the new password
  • It stayed on the "validating local credentials..." for a while and sent me a push notification since my organization requires 2fa (this is the WS Trust part). Alternatively, I could have entered my new password followed by a comma and the 8-digit OTP in the mobile app: NewP@ssw0rd!,43228522
  • After I accepted the 2fa push, it went onto the WLA part and sent me another push notification
  • After I accepted the 2fa push I was logged into my machine.
  • I signed out then signed in again, but this time it was just one WLA 2fa prompt since the trust had been established with the new password between the machine, AAD, and Passly.



Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section