AD FS 2012 R2 provides an interesting feature called Extranet Lockout Protection, where the intent is to protect AD accounts from malicious lockout from external access attempts. Previous versions of AD FS had no native mechanism to protect AD from such hammering attempts. For details on the feature please review this post.
One issue that can occur when extranet lockout protection is enabled is around how it deals with AD accounts that have had no bad passwords submitted against them. Bad password attempts are stored in the BadPwdCount attribute in AD, and are stored on the server that processed the failed logon request.
In this post we will look at the account called Vanilla-1 - this is an account that has not had a single wonky password submitted to it. Making sure there were no password typos was the most stressful part of writing this post! To see BadPwdCount on the Windows 2012 R2 DC, we can use the Get-ADDomainController cmdlet to enumerate all domain controllers. This lab has two domain controllers, which is why there are two lines returned. This collection is then used in the ForEach loop to enumerate the user’s properties on each DC passed to it as shown below:
Get-ADDomainController -Filter * | ForEach { Get-ADuser "Vanilla-1" -Properties * -Server $_ } | Format-Table Name, PasswordLastSet, BadPwdCount
For comparison, note that a separate account User-2 has 4 and 1 BadPwdCount reported from different DCs.
In the above example we are looking at one specific account, if you wanted to dump all user objects, then change the filter for the Get-ADUser cmdlet:
Get-ADDomainController -Filter * | ForEach { Get-ADuser -Filter {(ObjectClass -eq "user")} -Properties * -Server $_} | Format-Table Name, PasswordLastSet, BadPwdCount
Now that we have verified that the BadPwdCount is not set for Vanilla-1, let’s try and logon to AD FS 2012 R2 using this account. The URL we will hit is:
https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm
And we get the lovely error below:
An error occurred
An error occurred. Contact your administrator for more information
Activity ID: 00000000-0000-0000-0b00-0080000000d2
Error time: Tue, 15 Jul 2014 19:08:55 GMT
Cookie: enabled
User agent string: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; BRI/2; MS-RTC EA 2; MS-RTC LM 8; InfoPath.3)
(I’ll come back to why the Activity ID is highlighted in a moment)
Since AD S auditing is enabled, post on that coming up soon, we can see the below in the security event log on the AD FS server:
Looking at the details of the failed AD FS events we can see EventId 300 stating that there was an error enumerating the AD account.
Then EventID 413 is logged when processing the request:
How do I know for sure that these events map to the failed logon shown in the IE screen capture? Well apart from the fact that this is my lab and no-one else is using it? Remember the Activity ID that was highlighted in red? Go back and look at the IE screen capture. Notice that they are the same? This is how we can correlate between a client and lots of logged events.
Making It Right
Now that we have the background how to address this? Brian Reid who has forgotten more about transport than I know, kindly added a comment to the initial blog post. As Brian points out this issue is discussed in 2971171 - A new Active Directory user cannot log on from the AD FS server when the server is running from a GMSA account. Before this can be installed, the April 2014 2012 R2 must be installed – this is KB 2919355. This lab machine was updated with this when the April update was first released:
What is not totally clear though is the fact that this lab is *NOT* using a GMSA account – it is using a standard service account. However, installing the update did resolve the issue.
Time For A Do-Over
After installing the AD FS 2012 R2 update, let’s try this again. Things are much better, and the account Vanilla-1 is able to logon to AD FS.
In the security event log, we now see successful events when Vanilla-1 logs on to AD FS.
EventID 4624 shows Vanilla-1 as a successful logon:
And to make sure that I did not fnangle anything in the background (like making a typo in the password), note that the bottom command was taken 3 minutes after the screenshot above. The BadPwdCount is the same as the start. Phew – I did not typo the password!!
AD FS Updates
Just like all software components AD FS needs maintenance. In the Office 365 portal, the notification page has been alerting admins that a performance issue exists with AD FS 2012 R2 and that a hotfix must be installed. This issue was originally fixed in KB 2971171 - A new Active Directory user cannot log on from the AD FS server when the server is running from a GMSA account
This update is now superseded. Please ensure that your base Windows Server is fully patched, and review the list of AD FS updates
Updates for Active Directory Federation Services (AD FS)
The below updates have also been superseded, so please reference the above list of AD FS updates.
-
2912221 - AD FS proxy is no longer trusted by a Windows Server 2012 R2-based AD FS server after transient network connectivity interruptions occur
-
2948086 - 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in
-
2927690 -Update enables an alternative logon ID in AD FS in Windows Server 2012 R2
-
2964733 - AD FS device authentication is slow or fails in Windows Server 2012 R2
Not related to AD FS 2012 but the same maintenance is also needed for AD FS 2.0 – Updates are also available for those older builds, for example Update Rollup 3 for AD FS 2.0.
In addition to break fix, KB 2927690 also lights up the alternative logon capability. It pays to stay current on updates!
Update 30-3-2016: added reference to AD FS update page, and indicated the original updates have been superseded.
Cheers,
Rhoderick
