PowerShell script to collect AD FS 2016 bad password sign in attempts data

There is an excellent blogpost about federated to Microsoft Cloud accounts lockouts data collection, analysis and mitigation. 

The article above provides links to the scripts collecting event logs data for Windows Server 2008 R2, 2012 and 2012 R2.

But in Windows Server 2016 there were audit enhancements made in AD FS 2016 auditing to make it more streamlined and less verbose.

With this enhancement the EventIDs for Audit Failure logged in the Security logs by AD FS Auditing has changed.

Below is my version on PowerShell script to parse the Security Event log and collect information about EventID 1203 – “Fresh Credential Validation Error”.

$events = Get-WinEvent -FilterHashtable @{Logname='Security';Id=1203}
$events2 = ($events | select Message,TimeCreated -ExpandProperty Message)
$info = @()
$events2 | foreach {
    $IpStart = $_.Message.IndexOf("<IpAddress>")
    $IpEnd = $_.Message.IndexOf("</IpAddress>")
    $IpAddresses = $_.Message.Substring($IpStart+11,($IpEnd-$IpStart-11))

    $UserIdStart = $_.Message.IndexOf("<UserId>")
    $UserIdEnd = $_.Message.IndexOf("</UserId>")
    $UserId = $_.Message.Substring($UserIdStart+8,($UserIdEnd-$UserIdStart-8))

    $AuditStart = $_.Message.IndexOf("<AuditResult>")
    $AuditEnd = $_.Message.IndexOf("</AuditResult>")
    $Auditresult = $_.Message.Substring($AuditStart+13,($AuditEnd-$AuditStart-13))
    
    $FailureStart = $_.Message.IndexOf("<FailureType>")
    $FailureEnd = $_.Message.IndexOf("</FailureType>")
    $FailureType = $_.Message.Substring($FailureStart+13,($FailureEnd-$FailureStart-13))
    
    $AuthStart = $_.Message.IndexOf("<AuthProtocol>")
    $AuthEnd = $_.Message.IndexOf("</AuthProtocol>")
    $AuthProtocol = $_.Message.Substring($AuthStart+14,($AuthEnd-$AuthStart-14))
    
    $EndpointStart = $_.Message.IndexOf("<Endpoint>")
    $EndpointEnd = $_.Message.IndexOf("</Endpoint>")
    $Endpoint = $_.Message.Substring($EndpointStart+10,($EndpointEnd-$EndpointStart-10))

$Fail = New-object -TypeName PSObject
add-member -inputobject $Fail -membertype noteproperty -name "TimeStamp" -value $_.TimeCreated
add-member -inputobject $Fail -membertype noteproperty -name "IPaddress" -value $IpAddresses
add-member -inputobject $Fail -membertype noteproperty -name "User ID" -value $UserId
add-member -inputobject $Fail -membertype noteproperty -name "Audit" -value $Auditresult
add-member -inputobject $Fail -membertype noteproperty -name "FailureType" -value $FailureType
add-member -inputobject $Fail -membertype noteproperty -name "Protocol" -value $AuthProtocol
add-member -inputobject $Fail -membertype noteproperty -name "ADFS Endpoint" -value $Endpoint

$info +=$Fail
}
$info 

Also would higly recommend reading the following blogpost about best practices for defending against password spray attack using Azure AD and AD FS. Note the new Smart Lockout settings coming to AD FS 2016 in March 2018.

Azure Multi-Factor Authentication Server not sending emails out for new users

Recently was troubleshooting the issue when no email is sent to the new MFA server users regardless all the configurations seems to be correct. See following official documentation for more details. 

Because Administrator was able to send the Update email to the end user, we excluded the improper SMTP server configuration.

Per MFA server Help file: New Users – An email is sent to a user added that is enabled and complete (phone specified, mobile app activated, or OATH token secret key specified), or to an updated user that was either disabled or incomplete and is now enabled and complete.

Note: Emails are only sent when Send email to users is checked and the user’s email address is specified or their username is in email address format.

Confirmed that the New user has “Send email” check box selected on the User profile General Tab and the email address is correct.

Also, by going to MFA UI – Email – Email Context confirmed all the New User templates have correct email address specified in the From field.

Checked the SMTP server logs and don’t see any email send attempt from MFA server for New User email, only connections for Update email to be send.

Time to check the MFA Server logs!

To make sure you are looking at the latest logs, go to MFA UI – Logging – View Log Files.

Looking at the MultiFactorAuthAdSyncSvc.log see following error correlating to the time when the new user was added:

2018-03-07T18:20:20.006280Z|e|2960|4036|pfadssvc|***** ERROR ***** Error sending email to NewUser@domain.com: Access to the path ‘\\FileShare\public\MFA-Instructions\MFA-Guide.pdf’ is denied.

So the Administrator used the Attachment option to send additional instructions to new users, but the File share had access restrictions preventing the MFA server Local System account reading this document.

Solution was to either move the MFA instructions files to the MFA server or adjust the file share access permissions to allow Everyone to read the files.

Morale of the story: Read the manuals and logs, those are written by smart people 😊

Azure AD device registration error codes

Even when you followed the Hybrid Azure AD join instructions to set up your environment (https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup ), you still might experience some issues with the computers not registering with Azure AD.

If you are looking for troubleshooting guide for the issue when Azure AD Conditional Access policy is treating your successfully joined station as Unregistered, see my other recent post – https://s4erka.wordpress.com/2019/04/05/azure-ad-conditional-access-policies-troubleshooting-device-state-unregistered/

To check if the device was joined to Azure AD run “dsregcmd /status” command in command prompt and look at AzureAdJoined value. For the Azure AD registered devices, it should be set to YES.

If the AzureAdJoined says NO, next step will be to collect information from the Application and Services – Microsoft – Windows – User Device Registration – Admin logs.

First thing, try to locate and read the text description in the error to see if it gives any clue.

Below are some examples of the errors and possible solutions to try.

User Device Registration Admin log – EventID 304 or 305 – adalResponseCode: 0xcaa1000e – recommended step is to check the AD FS claim rules per mentioned above article. It is important to have the AD FS claim rules in the described order and if you have multiple verified domains, do not forget remove any existing IssuerID rule that might have been created by Azure AD Connect or other means.

User Device Registration Admin log –wmain: Unable to retrieve access token 0x80004005 – recommended step is to check the AD FS claim rules.

User Device Registration Admin log – EventID 305 – AdalErrorCode: 0xcaa90006 – make sure the computer is able to reach and authenticate to specified in the error text description Identity Provider endpoint.

User Device Registration Admin log – EventID 204 – Error code: 0x801c03f2 (“The device object by the given id (xxx) is not found.”) – make sure the on-premises computer object is synchronized to Azure AD. Run the Delta Azure AD Connect sync.

User Device Registration Admin log – EventID 304 (309, 201 and 233 coming before it) – Error code: 0x801c0021 (Error code: 0x80072efe in EventID 201) (Or in the User Device Registration Debug logs EventID 500 with message “wmain TenantInfi::Discover failed with error code 0x801c0021”) – most likely the network or proxy didn’t allow the connection to Azure AD device registration endpoints or IdP to complete authentication. Also see next error description for the recommended troubleshooting steps.

User Device Registration Debug log – EventID 502 – Error code: 0x80072ee7 (“WinHttpRequest<class DiscoveryHttpRequest>::OnCallback: The callback handling failed with error code: 0x80072ee7”) – most likely the network or proxy didn’t allow the connection to Azure AD device registration endpoints or IdP to complete authentication. Open IE as System Account using “psexec -i -s cmd.exe” and try to navigate to https://enterpriseregistration.windows.net/verifiedDomain/enrollmentserver/contract?api-version=1.2 (replace VerifiedDomain with your domain). You should see the list of device registration service endpoints like this.

If there is a failure, you might want to configure correct proxy settings in the same IE opened as System Account.

User Device Registration Admin log – 0xCAA90022 Could not discover endpoint for Integrate Windows Authentication. Check your ADFS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (error message is self explanatory). In case your IdP is not AD FS consult your IdP documentation.

User Device Registration Admin log – 0xCAA9002b with this error from ADAL – ADALUseWindowsAuthenticationTenant failed, unable to perform integrated auth. Check your STS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (error message is self explanatory). In case your IdP is not AD FS consult your IdP documentation.

User Device Registration Admin log – 0x801c001d. Failed to lookup the registration service information from Active Directory. Recommended to check the Service Connection Point settings in on-premises Active Directory.

Sometimes the error description of the User Device Registration Admin log event is not providing enough information and you have to enable the User Device Registration Debug log to get more information.

To enable debug logs open Event Viewer – check “Show Analytic and Debug Logs” and browse to Application and Services – Microsoft – Windows – User Device Registration – right click on Debug log and select Enable log.

To trigger the device join attempt you have to open Command prompt as System account (you can use Sysinternals PsExec – psexec -i -s cmd.exe) and issue “dsregcmd /debug /join” command. After that disable the Debug log, check the Admin logs and if still the error description is not informative go to Debug logs.

Example 1:

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          2/9/2018 10:17:49 AM
Event ID:      304
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      XXX
Description:
Automatic registration failed at join phase.  Exit code: An unexpected internal error has occurred in the Platform Crypto Provider.

User Device Registration Debug log –

Log Name:      Microsoft-Windows-User Device Registration/Debug
Source:        Microsoft-Windows-User Device Registration
Date:          2/9/2018 10:23:30 AM
Event ID:      500
Task Category: None
Level:         Information
Keywords:     
User:          SYSTEM
Computer:      XXX
Description:
wmain: failed with error code 0x80290407.

Most likely this error is an indication that the TPM is not supporting Azure AD join requirements (https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/tpm-recommendations ).

Next steps for this particular issue I would recommend for these stations are:

• Ensure the TPM is in 2.0 mode. You will find this setting in the BIOS.
• As a last resort, disable TPM in the BIOS, so Azure AD Join process uses software-based keys.

Example 2:

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          4/17/2018 12:44:10 PM
Event ID:      304
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      XXX
Description:
Automatic registration failed at join phase.  Exit code: Keyset does not exist. Server error: empty.

After running dsregcmd /debug /join see following in the output:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

Most likely this error indicates that the machine was imaged from the already Azure AD registered computer. Also it might indicate the TPM issues (see the TMP troubleshooting steps mentioned above).

If the fist is true, try renaming the “C:\ProgramData\Microsoft\Crypto\Keys” folder and re-running the dsregcmd /debug /join.

Example 3:

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          5/16/2018 8:44:03 AM
Event ID:      305
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:     XXX
Description:
Automatic registration failed at authentication phase.  Unable to acquire access token.  Exit code: Unspecified error. Server error: AdalMessage: ADALUseWindowsAuthenticationTenant failed,  unable to preform integrated auth
AdalErrorCode: 0xcaa9002c

This error usually indicates an issue with connecting to AD FS farm. Check if Windows Integrated Authentication is enabled for Intranet, is working correctly for Intranet and WSTrust windows endpoints are enabled in AD FS.

Azure Multi-Factor Authentication Server with ADFS – EventID 105 troubleshooting. Part 2

You might already have checked for the EventID 105 error solution in my previous post.

This time the issue was similar, followed the official instructions – https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-adfs-w2k12 and when restarting the AD FS service we got the EventID 105.

Looking at the ADFS Debug logs see new error:
Log Name:      AD FS Tracing/Debug
Source:        AD FS Tracing
Date:          3/6/2018 3:03:41 PM
Event ID:      183
Task Category: None
Level:         Error
Keywords:      ExternalAuthentication
User:          XXX
Computer:      XXX
Description:
OnAuthenticationPipelineLoad() exception: System.Exception: Error connecting to Multi-Factor Authentication service. —> System.Runtime.InteropServices.SEHException: External component has thrown an exception.
   at native.construct(construct_ret_t* , __MIDL_pfAgent_idl_0009 )
   at PfSvcClientClr.PfSvcClient.construct(ConstructTarget target, ConstructResult& result)
   at pfadfs.AuthenticationAdapter.ConnectToService(ConstructTarget constructTarget, Int32 lcid)
   — End of inner exception stack trace —
   at pfadfs.AuthenticationAdapter.ConnectToService(ConstructTarget constructTarget, Int32 lcid)
   at pfadfs.AuthenticationAdapter.OnAuthenticationPipelineLoad(IAuthenticationMethodConfigData configData)
   at Microsoft.IdentityServer.Web.Authentication.External.ExternalAuthenticationHandlerBase.

Looking at MultiFactorAuthenticationAdfsAdapter.config file closer, have noticed that the value of UseWebServiceSdk is True, so have changed it to true, re-run the Registration script and there were no errors after AD FS service restart.

Discover and protect from crypto miners in your network using pfSense firewall

In a raise of popularity of crypto mining there is a shift in the threat landscape. Attackers “are beginning to recognize that they can realize all the financial upside of previous attacks, like ransomware, without needing to actually engage the victim and without the extraneous law enforcement attention that comes with ransomware attacks,” Talos researchers write in a new post(http://blog.talosintelligence.com/2018/01/malicious-xmr-mining.html ).

One of the steps you can take to protect your network, is to block outgoing connection to the IP addresses associated with crypto mining pools. Those IPs are easy to get from SANS API (See isc.sans.edu/api for details).

I have used following PowerShell scrip to get the latest IP list.

$date = Get-Date -format "yyyyMMdd"
$url = "https://isc.sans.edu/api/threatlist/miner?xml"
$membersList = Invoke-RestMethod -Uri $url
$membersList | select threatlist -ExpandProperty threatlist |
select miner -ExpandProperty miner | select ipv4 -ExpandProperty ipv4 |
Sort-Object ipv4 -Descending |
out-file "D:\Temp\miners$date.txt"

After that sign in your pfSense firewall, go to Firewall – Aliases menu.

pfSense Aliases menu allows bulk IP addresses upload. Press Import button on the bottom of Aliases page and use the content of the TXT file created earlier to create the alias for the IPs associated with crypto mining pools. I would recommend giving the alias meaningful name which includes the date of creation (will make the firewall rule and aliases management easier as you update the list).

After creating the alias, go to your LAN rules and create the rule to block any connection from your LAN network to the CryptoMining alias and make sure the rule is on the top of the list (right after rules allowing access to pfSense management ports). Optionally you can select log to monitor what stations in your network tried the malicious outbound connection.

On regular basis you can update the IP list and create the new alias (with new date in the name). After that you can easily update the firewall rule by simply changing the destination to new alias.

Also its always recommended to place a default block all LAN rule for outgoing traffic to make sure only authorized connections are successful to the Internet from your hosts.