AD FS sign-ins in Microsoft Entra ID with Connect Health - preview
AD FS sign-ins can now be integrated into the Microsoft Entra sign-ins report by using Connect Health. The Microsoft Entra sign-ins Report report includes information about when users, applications, and managed resources sign in to Microsoft Entra ID and access resources.
The Connect Health for AD FS agent correlates multiple Event IDs from AD FS, dependent on the server version, to provide information about the request and error details if the request fails. This information is correlated to the Microsoft Entra sign-in report schema and displayed in the Microsoft Entra sign-in report UX. Alongside the report, a new Log Analytics stream is available with the AD FS data and a new Azure Monitor Workbook template. The template can be used and modified for an in-depth analysis for scenarios such as AD FS account lockouts, bad password attempts, and spikes of unexpected sign-in attempts.
Prerequisites
- Microsoft Entra Connect Health for AD FS installed and upgraded to latest version (3.1.95.0 or later).
- Reports Reader role to view the Microsoft Entra sign-ins
What data is displayed in the report?
The data available mirrors the same data available for Microsoft Entra sign-ins. Five tabs with information are available based on the type of sign-in, either Microsoft Entra ID or AD FS. Connect Health correlates events from AD FS, dependent on the server version, and matches them to the AD FS schema.
User sign-ins
Each tab in the sign-ins blade shows the default values below:
- Sign-in date
- Request ID
- User name or user ID
- Status of the sign-in
- IP Address of the device used for the sign-in
- Sign-In Identifier
Authentication Method Information
The following values may be displayed in the authentication tab. The authentication method is taken from the AD FS audit logs.
| Authentication Method | Description |
|---|---|
| Forms | Username/password authentication |
| Windows | Windows-integrated Authentication |
| Certificate | Authentication with SmartCard / VirtualSmart certificates |
| WindowsHelloForBusiness | This field is for auth with Windows Hello for Business. (Microsoft Passport Authentication) |
| Device | Displayed if Device Authentication is selected as “Primary” Authentication from intranet/extranet and Device Authentication is performed. There's no separate user authentication in this scenario. |
| Federated | AD FS didn't do the authentication but sent it to a third party identity provider |
| SSO | If a single-sign-on token was used, this field is visible. If the SSO has an MFA, it shows as Multifactor |
| Multifactor | If a single sign-on token has an MFA and that was used for authentication, this field displays as Multifactor |
| Microsoft Entra multifactor authentication | Microsoft Entra multifactor authentication is selected as the Additional Authentication Provider in AD FS and was used for authentication |
| ADFSExternalAuthenticationProvider | This field is if a third-party authentication provider was registered and used for authentication |
AD FS Additional Details
The following details are available for AD FS sign-ins:
- Server Name
- IP Chain
- Protocol
Enabling Log Analytics and Azure Monitor
Log Analytics can be enabled for the AD FS sign-ins and can be used with any other Log Analytics integrated components, such as Sentinel.
Note
AD FS sign-ins may increase Log Analytics cost significantly, depending on the amount of sign-ins to AD FS in your organization. To enable and disable Log Analytics, select the checkbox for the stream.
To enable Log Analytics for the feature, navigate to the Log Analytics blade and select "ADFSSignIns" stream. This selection allows AD FS sign-ins to flow into Log Analytics.
To access the updated Azure Monitor Workbook template, navigate to "Azure Monitor Templates", and select the "sign-ins" Workbook. For more information about Workbooks, visit Azure Monitor Workbooks.
Frequently Asked Questions
What are the types of sign-ins that I may see? The sign-in report supports sign-ins through O-Auth, WS-Fed, SAML, and WS-Trust protocols.
How are different types of sign-ins shown in the sign-in report? If a Seamless SSO sign-in is performed, there is one row for the sign-in with one correlation ID. If a single factor authentication is performed, two rows are populated with the same correlation ID, but with two different authentication methods (that is, Forms, SSO). In cases of multifactor authentication, there are three rows with a shared correlation ID and three corresponding Authentication Methods (that is, Forms, Microsoft Entra multifactor authentication, Multifactor). In this particular example, the multifactor in this case shows that the SSO has an MFA.
What are the errors that I can see in the report? For a full list of AD FS related errors that are populated in the sign-in report and descriptions, visit AD FS Help Error Code Reference
I am seeing “00000000-0000-0000-0000-000000000000” in the “User” section of a sign-in. What does that mean? If the sign-in failed and the attempted UPN doesn't match an existing UPN, the “User”, “Username”, and “User ID” fields are “00000000-0000-0000-0000-000000000000” and the “Sign-in Identifier” populated with the attempted value the user entered. In these cases, the user attempting to sign-in doesn't exist.
How can I correlate my on-premises events to the Microsoft Entra sign-ins report? The Microsoft Entra Connect Health agent for AD FS correlates event IDs from AD FS dependent on server version. The events are available on the Security Log of the AD FS servers.
Why do I see NotSet or NotApplicable in the Application ID/Name for some AD FS sign-ins? The AD FS sign-in report displays OAuth Ids in the Application ID field for OAuth sign-ins. In the WS-Fed, WS-Trust sign-in scenarios, the application ID is NotSet or NotApplicable and the Resource IDs and Relying Party identifiers are present in the Resource ID field.
Why do I see Resource ID and Resource Name fields as "Not Set"? The ResourceId/Name fields are "NotSet" in some error cases, such as "Username and Password incorrect" and in WSTrust based failed sign-ins.
Are there any more known issues with the report in preview? The report has a known issue where the "Authentication Requirement" field in the "Basic Info" tab are populated as a single factor authentication value for AD FS sign-ins regardless of the sign-in. Additionally, the Authentication Details tab displays "Primary or Secondary" under the Requirement field, with a fix in progress to differentiate Primary or Secondary authentication types.