Migrating AuthLite v1.x with Integrated users to version 2
AuthLite version 1 customers who have Integrated users need to perform these extra steps before migrating to a version 2 install.
This article first describes the security models for user authentication and endpoint protection between AuthLite versions 1 and 2 at a high level. Then information is provided about planning and executing an upgrade to a version 2 environment.
Limitations of AuthLite v1 Endpoint Security
AuthLite version 1 provides secure logon for endpoint workstations by leveraging "Integrated users". These accounts use a special augmented static secret as the account's AD password. This secret is never stored, and can only be generated by combining the user's plaintext password and a decrypted YubiKey one-time passcode. There are some important ramifications of relying on this approach:
Even though the augmented static secret is never stored anywhere, it gets assembled by the security core of each workstation each time the user authenticates. The domain controller processes the one-time passcode authentication and returns its cryptographic results to the workstation. That means any software running on the workstation with system-level privileges could theoretically see this value. A malicious workstation could collect the augmented secret and bypass the one-time passcode authentication factor in the future. This collected static value could also be used on other systems by an attacker in lieu of two-factor authentication, and the domain controller could not detect the difference.
In order to support offline (cached) logon, the workstations must store the YubiKey's shared secret so they can decrypt the one-time passcodes. The shared secret is encrypted against disclosure by a key derived from the user's plaintext password. But this is still not ideal since an attacker who can acquire or guess the password and then obtain the workstation's hard drive could bypass the one-time passcode authentication factor.
Since the AD password has been changed (it's the augmented static secret, not what the user types in as their plaintext password) this means there is no way for this account to authenticate anywhere on the domain except for systems and software that are AuthLite-aware. Although that configuration is "secure by default", in practice it is an unacceptable barrier to use for most customers, who wish certain systems and software to continue authenticating AuthLite users with one-factor only.
AuthLite v2 Endpoint Security Model
AuthLite version 2 has a more sophisticated Active Directory authentication subsystem. This allows us to dispense with the distinction between "Integrated" and "Split" users. Version 2 accounts have normal passwords whose hashes are stored in AD in the default Microsoft fashion. The domain controller makes the decision whether to allow or deny each authentication attempt based on the presence of a valid one-time passcode. This has the following ramifications:
Nothing seen by the workstation could be used to gain access to future sessions. The domain controller is making the ultimate decision each time an authentication is performed, so it can accept or reject the credentials properly. There is no augmented static secret anywhere in this model.
Version 2 software on the DC and workstation provides more secure cached/offline logons. The YubiKey challenge/response mode is used to encrypt a randomly chosen secret key that must be provided in order to decrypt the cached logon record and DPAPI keys. A new random secret is chosen each time the user authenticates to the workstation when it is online. This model means that in order to log in, an attacker would not only need the user's password, but access to the hard drive, followed by access to the YubiKey. Additionally, any partial disclosure is likely to be short-lived since the secrets are changed regularly. Finally, each secret is only useful for the workstation on which it was generated.
Logons work as one-factor by default, unless constrained by administrators. Compared to the limitations in v1, admins have finer-grained control over what systems and processes will require two-factor authentication.
WARNING: Domain controllers that do not have the AuthLite software installed will process all authentications as one-factor. They will reject AuthLite two-factor authentications, and they will ALLOW users to authenticate with one-factor even if you do not wish them to. All DCs should be made AuthLite-aware to avoid this situation. This warning may not necessarily apply if your two-factor users only log in via RADIUS or some other constrained subsystem where they are always funneled to an AuthLite-aware server.
Considerations for AuthLite version 1 customers before upgrading
If you only use Split-mode users in your version 1 deployment then your users can continue to use their existing YubiKeys in the same manner they have in the past. Read the v2 manual because replay windows and 2-factor forcing work quite differently and you will probably need to make configuration changes.
If you have Integrated users then at a minimum you will have to contend with these hurdles:
- Integrated user records must be altered to split-mode in order for the installation to proceed (see below).
- Currently active Integrated users will not be able to log in until their passwords are administratively reset, because v2 does not create or use augmented password values like v1.
Additional considerations for YubiKeys to support offline logons:
- Your YubiKeys need to be reprogrammed if you intend to use them to log on to offline workstations, because the old records will not have challenge/response secrets associated with them either in the keys or the data store.
- Your YubiKeys could be too old to program with challenge/response. The oldest supported YubiKey model is version 2.1. (YubiKey firmware cannot be updated.)
- If you are using the second configuration slot on your keys for something unrelated to AuthLite, that identity will be need to be OVERWRITTEN by the version 2 key programmer. Without the C/R identity in slot 2, it will not be possible to log on to offline workstations with that key.
Prerequisite for upgrading from version 1 to version 2
WARNING: This process will cause the destruction of your current data records. If you have any possibility of taking the environment back to version 1, you MUST make a backup of all records in the Data Manager before proceeding.
- Go into the AuthLite Data Manager and remove any key records that show "Integrated" unless you want to continue using those keys without offline logon support.
- Open ADSI Edit and Connect to the tree "DC=AuthLite,[DC=your,DC=domain,DC=fqdn,DC=here]" where the bracketed value is replaced with your domain's FQDN such as "DC=sandbox,DC=collectivesoftware,DC=com" for "sandbox.collectivesoftware.com"
- Go into the AuthLiteHashes section, and delete all records under it. This will remove the Integrated flag from the records and make them v2 compatible. See above for notes about mandatory password resets!