0

AD FS 2012 R2 – An Error Occurs When BadPwdCount Not Set

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:

image

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.

image

 

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:

ADFS 2012 R2 An error occurred. Contact your administrator for more information

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:

ADFS 2012 R2 Audit Messages When BadPwdCount Is Not Set

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.

ADFS 2012 R2 EventID 300 - Failed AD Account Lookup

Then EventID 413 is logged when processing the request:

ADFS 2012 R2 EventID 413 - Error Processing Token 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:

April 2014 2012 R2  Update Is Installed

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.

ADFS 2012 R2 Update 2971171 Is Installed

 

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.

YAY!!! Successful Logon After Installing ADFS 2012 R2 Hotfix

In the security event log, we now see successful events when Vanilla-1 logs on to AD FS.

Success Audits After Installing ADFS 2012 R2 Hotfix

EventID 4624 shows Vanilla-1 as a successful logon:

Successful Logon With Test Account To ADFS

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!!

image

 

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

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *