Why does AuthLite want the OTP in the username field?

All authentication dialogs have a username and a password field, and AuthLite's design goal is to support all of them without replacing the client or server software.

Problems with using the password field

AuthLite authenticates at your Domain Controllers, so we need to get the OTP from your client to the DC.  But (by security design) many authentication protocols don't actually send the contents of your password field to the server.  Rather, they convert your password into a "password hash" and send that to the server, or otherwise use it with a challenge/response to authenticate you.

So for these protocols, putting anything in the password field except  for your password will simply result in a bad password hash.  The OTP won't get sent to the server, it will just get destroyed on the client, and the DC will see it as if you had entered the wrong password.

Username field to the rescue!

Pretty much all protocols send the username up to the server exactly as the user types it.  This means we can put the OTP in that field and it will reach the DC.  As long as AuthLite's running there and we have enough information to tell who you are, we can make this one-factor software send two-factor authentication!  We can tell who you are because either:

• You use a YubiKey OTP, so AuthLite can see its static ID and map it to your user account. Or,
• You enter your username, followed by a dash (minus), followed an OATH code.  So AuthLite can parse your username out of that and then validate the OTP.

Can I use the password field?

AuthLite supports password and OTP together in the same field, so long as the protocol being used doesn't hash the password before reaching the server!

Does the username field always work?

As long as the client software sends the username field (by RDP, LDAP, Windows authentication, etc.) and trusts the authenticated result from the DC, then it will work!  But this isn't always true:

• Some systems use the text you enter in the username field to look up the user in a separate database of their own.  In this case, it won't match. Try OTP+password together.

• Some systems log the text of the username field, so you'll see YubiKey OTPs in your logs (you can look these up by pasting into the Find field of the Token Manager app)
• Linux-like SSSD systems will reject the OTP in the username because they have extra logic that verifies the user record returned from the domain equals the username originally entered.  So there is more work for Linux.

Let us know if you need help figuring out how to pass 2-factor credentials through a certain application, or how to enforce 2-factor.