In the first part of this blog series, we’ll look at this hot topic. Read about some updated information on how to help fix this for your organization.

First off, keep up to date. Microsoft has slide in some more tech into their Smart Lockout feature for Windows Server 2016 in March 2018.

A ton more information can be found here on how to avoid this issue: https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/

Of course, you’re probably here and you want some more information because you’re currently being attacked and want to fix it, or you just like to learn!

The Challenge

Your accounts are being locked out. Where do these IP’s keep coming from?

Solving the Challenge

  1. The first step is to install the March Updates on your Windows Server 2016
  2. Enable Auditing on ALL ADFS Servers
    1. Verify, Enable the Success and Failure and then auditing (Success and Failures) by running the following 3 commands

    auditpol.exe /get /subcategory:”Application Generated”
    [cmd]
    auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable
    auditpol.exe /get /subcategory:”Application Generated”
    [/cmd]

    1. On the Primary ADFS Server
  3. On All ADFS Servers, Grant the “Generate security audits” User Rights assignment to your ADFS Service Account. Please note that this is in addition to the NT SERVCE\adfssrv that should already be in the list.

  4. On the Primary ADFS Server, configure ADFS Auditing Events

  5. On the Primary ADFS Server, enable Verbose Auditing 
    (Get-AdfsProperties).AuditLevel
Set-AdfsProperties -AuditLevel Verbose
(Get-AdfsProperties).AuditLevel

  6. Install the Azure AD Connect Health Agent for ADFS

Verifying the Changes

Throughout some of the steps above, I have added some verification steps, but now we really get to see the final outcome (And screenshots before you do this in production)!

Check Event Viewer

Once all the March 2018 and auditing settings have been enabled, you will additional events and the details of some of these events will be increased.

You should now see the new Event ID 1203 logged before the traditional 411 events.

Event 1203 Details

Part of the new details inside is the ForwardedIpAddress property. This shows the original calling IP address, even if it was passed through a Windows Application Proxy (WAP) or other proxy device such as a hardware load balancer.

The Federation Service failed to validate a new credential. See XML for failure details.

 

Activity ID: 00000000-0000-0000-0000-000000000000

 

Additional Data

XML: <?xml version=”1.0″ encoding=”utf-16″?>

<AuditBase xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:type=”FreshCredentialAudit”>

<AuditType>FreshCredentials</AuditType>

<AuditResult>Failure</AuditResult>

<FailureType>CredentialValidationError</FailureType>

<ErrorCode>N/A</ErrorCode>

<ContextComponents>

<Component xsi:type=”ResourceAuditComponent”>

<RelyingParty>N/A</RelyingParty>

<ClaimsProvider>N/A</ClaimsProvider>

<UserId>arafuse.test1@broadarc2.com</UserId>

</Component>

<Component xsi:type=”AuthNAuditComponent”>

<PrimaryAuth>N/A</PrimaryAuth>

<DeviceAuth>false</DeviceAuth>

<DeviceId>N/A</DeviceId>

<MfaPerformed>false</MfaPerformed>

<MfaMethod>N/A</MfaMethod>

<TokenBindingProvidedId>false</TokenBindingProvidedId>

<TokenBindingReferredId>false</TokenBindingReferredId>

<SsoBindingValidationLevel>NotSet</SsoBindingValidationLevel>

</Component>

<Component xsi:type=”ProtocolAuditComponent”>

<OAuthClientId>N/A</OAuthClientId>

<OAuthGrant>N/A</OAuthGrant>

</Component>

<Component xsi:type=”RequestAuditComponent”>

<Server>http://sts. broadarc2.com/adfs/services/trust</Server>

<AuthProtocol>N/A</AuthProtocol>

<NetworkLocation>Intranet</NetworkLocation>

<IpAddress>10.123.123.12</IpAddress>

<ForwardedIpAddress>220.180.107.193</ForwardedIpAddress>

<ProxyIpAddress>N/A</ProxyIpAddress>

<NetworkIpAddress>N/A</NetworkIpAddress>

<ProxyServer>N/A</ProxyServer>

<UserAgentString>N/A</UserAgentString>

<Endpoint>N/A</Endpoint>

</Component>

</ContextComponents>

</AuditBase>

 

Check the Azure Portal

If you installed the Azure AD Connect Health Agent for ADFS, it will start sending telemetry information to Azure.

  1. Log into Azure as a Tenant Administrator
  2. Click Azure Active Directory
  3. Click Azure AD Connect
  4. Click the Azure AD Connect Health link in the Health and Analytics Section

  5. Click the Pin at the top and Pin this to your Dashboard!
  6. Click your ADFS link

  7. View the metrics that are being populated

From the Microsoft Blog

I will highlight a section from the Microsoft blog I link to above

  1. We strongly recommend enabling always-on multi-factor authentication for all admins in your organization, especially subscription owners and tenant admins. Seriously, go do this right now.
  2. For the best experience for the rest of your users, we recommend risk-based multi-factor authentication, which is available with Azure AD Premium P2 licenses.
  3. Otherwise, use Azure MFA for cloud authentication and ADFS.
  4. In ADFS, upgrade to ADFS on Windows Server 2016 to use Azure MFA as primary authentication, especially for all your extranet access.

Stay tuned for the next post and Good luck!