Bulk Revoke Passkeys from the passkey table. Users can now revoke one or multiple passkeys directly from the passkey table. This will allow them to quickly identify stale or unwanted passkeys and remove them with a few clicks. Note that this action is permanent and cannot be recovered once done.
Roaming Authentication Scope. You can now scope Roaming Authentication to enable configured source IP addresses. It allows more granular control of which sources roaming Authentication is enabled and for which sources the QR code is displayed. For example, configure source IP addresses of an organization’s ISPs to enable roaming Authentication from these locations only.
Configure this under Settings > Authentication Options > Roaming Authentication.
Policy Attribute: Applications Installed. The Applications Installed attribute now supports matching on application versions for Windows and macOS. Leverage this attribute to match policy rules based on applications installed on endpoint devices. Note: Matching on versions currently supports numeric versions only.
Policy Action: Allow w/ Biometric Verification. Beyond Identity administrators can now allow users to leverage biometrics as a step-up/additional factor. The biometric-only option can be configured using the Beyond Identity policy engine and does not permit an end user to fall back to the operating password or PIN to satisfy the additional factor. If configured, the user will receive a denied notification when they attempt to authenticate if biometrics are not satisfied or unavailable.
DataDog SIEM Integration Enhancement. Because Datadog offers independent sites based on data governance regulations, you must select the proper site parameter to properly connect to our event HTTP listener. We’ve added a new field that allows you to do so. The default example corresponds to the US1 location. However, you can now modify this according to the site corresponding to your data's location. For more information about DataDog site parameters, see Getting Started with Datadog Sites.
Password Change/Reset in Windows Desktop Login - Windows Desktop Login (WDL) now detects when the user changes their password and automatically re-caches the BI credentials without needing the user to unlock or re-login while offline. Previously, login credentials were automatically re-cached whenever the user logins or locks and unlocks via WDL.
The Password change assist only works for Domain Local and Hybrid, it does not work for Azure Only.
The details of the new solution are:
- Local Account: If the user changes their password and their account is a local only account, Windows produces an Event Log message specifying that the password changed. Specifically, Windows trigger event #4723 if the user changes their own password, and #4724 if an Admin changes another user’s password. WDL listens for both of these password change events and re-caches the WDL credentials whenever it receives either event.
Domain or hybrid Azure AD/Domain: In a domain or a hybrid Azure AD/Domain environment, the domain controller receives the password changed event(s) instead of the client. However, event #4693 indicates that the DPAPI master key was recovered. This event is triggered on the client at least once whenever the user changes their password on a domain. WDL listens for this event and re-caches the WDL credentials whenever it receives it. Additionally, event #4693 is not enabled by default, so you’ll need to enable domain clients to receive this message.
Apply the following settings for the Group Policy under the OU for your Beyond Identity users/clients.
- On the Domain Controller, open the Group Policy Editor.
- Edit the Default Group Policy or the applicable OU policy. Go to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies - Local Group Policy Object > Detailed Tracking.
- Open the Audit DPAPI Activity properties, select the Success and Failure options, and click OK to save the configuration.
- Close the Group Policy Editor and ensure that the new Group Policy is pushed out to all the clients.
- Azure AD Only: Currently, WDL cannot detect that a user changed their password in an Azure AD Only environment. So, in an Azure AD Only environment the user must login again or lock/unlock while still online.
Microsoft's Data Protection API (DPAPI) provides services to safely encrypt and decrypt data using the current user account. Microsoft Windows uses this mechanism throughout. Beyond Identity WDL uses DPAPI to protect various pieces of user's data, including the credential that is used to verify a login via Beyond Identity. Under the covers, DPAPI utilizes the user's password as part of the encryption process when protecting data. This is how DPAPI can ensure that only the currently logged-in user can access any data protected with DPAPI.
WDL uses a virtual smart card to allow users to log in using their Beyond Identity credentials. Virtual smart cards emulate the functionality of physical smart cards, but they use the Trusted Platform Module (TPM) chip available on devices. Virtual smart cards don't require a separate physical smart card and reader. Instead, you create virtual smart cards in the TPM, where the keys used for authentication are stored in cryptographically-secured hardware.
When a user is a member of a domain or a hybrid Azure AD/domain environment, they still need to be able to login if they are:
- offline, or
- if they are not connected to a VPN that gives them access to the domain
Windows solves this problem by caching the user's login credentials using DPAPI. So, when the user is offline and enters their correct password during login, Windows can decrypt the cached credential and verify the user even though they are offline or can't reach the domain. WDL uses an identical caching mechanism to ensure the user can log in using Beyond Identity offline.
Windows has a limited number of slots that are used for caching the number of previous login credentials. However, since WDL uses a virtual smart card, its cached credential uses a different slot than the normal password.
One complication of this mechanism is that the cached credentials must be re-cached whenever the user changes their password. Windows ensures that the login credentials are re-cached whenever the user changes their password but makes no assurances for additional authentication methods like the virtual smart card that WDL uses. As such, WDL must re-cache the smart card login credential to ensure that offline access via WDL will continue to work whenever the user changes their password.