Logons denied by Active Directory
UserLock can audit and notify logons denied by Active Directory through its different alerts to users and UserLock operators.
This feature requires:
- The UserLock 'Desktop agent' to be installed on network machines,
- The UserLock 'IIS agent' installed on IIS servers to detect logons denied when the IIS authentication is based on 'Windows mode',
- The Microsoft Audit policy 'Audit logons events' to be enabled on 'Failure' on target machines where the UserLock agent is installed. This operation can be done through a Microsoft Group Policy with the following parameter: 'Security settings/Local policies/Audit policy/Audit Logon events'.
These logons denied by Active Directory will be saved in the UserLock database and will be usable from predefined reports.
UserLock obtains connections denied by Windows only for existing user names in Active Directory. If a connection is attempted with an invalid username, UserLock will not save this attempt to its database.
Known limitation
Logons denied by Active Directory cannot be detected for RDP sessions using NLA authentication.
Such events will not be captured and will not be displayed in the reports ('Sessions history', 'Denied logon' ...) nor in the notifications sent by the UserLock service ('Warn users in real time of all connection events involving their credentials') in the 'General' section of the protected account's properties and the 'Notifications' section of the protected account's properties.
If you really need these notifications, you can configure your RDP servers to not use NLA authentication (not recommended).
For SharePoint working with ADFS authentication, logons denied by windows are not managed by IIS Agent
When ADFS authentication refuses a logon, the user's UPN is not sent to the SharePoint server. On the ADFS server's security log, the connection is allowed and automatically logged off. However, on the Sharepoint server's IIS log, the logon denied is logged without specifying the user, only the IP address.