top of page

Kerberos Armouring (FAST)


#What is Kerberos Armouring

Pre-authentication is when the user sends the KDC an Authentication Service Request (AS_REQ) with an encrypted Timestamp. The KDC replies with an Authentication Service Reply (AS_REP) with the TGT and a logon session. The issue arises when the user's account doesn't require pre-authentication, it's a check box on the user's account settings. An attacker is then able to request a DC, and the DC dutifully replies with user encrypted TGT using the user's own NTLM password hash. An offline brute force attack is then possible in the hope of extracting the clear text password, known as AS-REP Roasting.

Kerberos Armouring cryptographically strengthens the channel between KDC and the User's pre-authentication and the TGT even when pre-authentication is not required.


Kerberos Armouring is Microsoft's own implementation of and Flexible Authentication Secure Tunnelling (FAST) as described in RFC 4851. Its only when 'Fail authentication requests when Kerberos armouring is not available' group policy has been applied is the implementation fully compliant with FAST, so for this article, I'll refer to as it as 'Kerberos Armouring' unless stated otherwise. 

#Kerberos Authentication Process

Kerberos Armouring alters Kerberos Authentication in the following way, highlighted in RED.

0. User logs on with Username and Password.

The client at startup establishes a session key based on its client's very strong password (Client Logon Session Key taken from the Client's TGT).

When a User enters their credentials, the credentials are passed to the client for processing and with Kerberos Armouring are combined with the Client Logon Session Key to create a Compound Authentication request to the KDC.

1. Kerberos authentication service request (KRB_AS_REQ)
The client requests a ticket from the KDC (AS) by sending the following info:

Users Authentication (Pre-Authentication) request

Timestamp (encrypted with users password hash and converted to a symmetric Users Secret Key and combined with the Clients Session Key)

TGT Service Request (originally clear text and now encrypted with Compound Authentication request)

Client IP
Client Principal name

2. Kerberos authentication service response (KRB_AS_REP)

KDC (AS) decrypts the timestamp with the Users Secret Key and the Clients Session Key, as this  is also known to the KDC

KDC (AS) validates the user request and replies with the TGT and Logon Session Key


Logon Session Key (encrypted with the Users Secret Key and the Clients Logon Session Key)



Ticket Granting Ticket (TGT) (encrypted with the KRBTGT Secret Key)

Logon Session Key

Time Stamp 

Users Authentication 


Group Membership

Client IP
Expiry date and time = 10 hours 
PAC File (Privilege Attribute Certificate) Data Structure contains authorization data controlling access to resources......

​The Client decrypts the Logon Session Key with the Users Secret Key and the Clients Session Key.

​The Client extracts the TGT from the decrypted Logon Session Key

In its simplest terms, the user's weak password is combined with the Windows client's much stronger password to become a compound password and near impossible to crack.

#Why enable the disable of pre-authentication

Disabling pre-authentication is I hope less of an issue nowadays, mainly affecting service accounts for Linux and legacy apps. Of course service accounts tend to have high privilege or domain admins. Services tend to age out over time, doesn't mean housekeeping and maintenance have removed those accounts.

Execute the following to find any account that doesn't require pre-authentication. 

Get-aduser -filter * -Properties DoesNotRequirePreAuth | where {$_.DoesNotRequirePreAuth -eq $true}

#Requirements for Kerberos Armouring

Windows 2012 DC's and Windows 8 are required as a minimum, going to assume that the DC's are higher than 2012.


Windows 7 does not support Kerberos Armouring and if the DC GPO is updated from 'Supported' to 'Fail unarmoured authentication requests' there's the potential that not only will Windows 7 users be angry but the entire Domain is inaccessible. Definitely coffee without biscuits meeting with the boss. 


Windows 2008 and Windows 7 ought to be dead and buried, replaced with Windows 10 so I'm not going into the details of compatibility, upgrade already.

#Enabling Kerberos Armouring

Support for Kerberos Armouring is enabled against the Domain Controllers Group Policy.


Open 'Group Policy Management' and browse to the Domain Controller container, edit the 'Domain Controller Default Policy'.

Browse to 'Computer Configuration > Policies > Administrative Templates > System > KDC'.

Enable 'KDC Support for Claims, Compound Authentication and Kerberos Armouring'.

Select 'Supported' to allow legacy Windows and Linux to authenticate.

Remaining in 'Group Policy Management', browse to the OU for the Windows Clients and create a new GPO.

Edit the new GPO and browse to 'Computer Configuration > Policies > Administrative Templates > System > Kerberos'.

Enable 'Always Send Compound Authentication First'.

Enable 'Kerberos Client Support for claims, compound authentication and Kerberos armouring'

Enable 'Fail authentication requests when Kerberos armouring is not available'

Enable 'Support compound authentication'

#Warning Will Robinson 

Failure to set the following Group Policies on the Domain Controllers OU before setting 'Fail unarmoured authentication requests' will render the Domain inaccessible. The DC's must support compound authentication.

'Computer Configuration > Policies > Administrative Templates > System > Kerberos'.

Enable 'Always Send Compound Authentication First'.

Enable 'Kerberos Client Support for claims, compound authentication and Kerberos armouring'

Enable 'Fail authentication requests when Kerberos armouring is not available'

Enable 'Support compound authentication'

#The Environment is now 2019

Domain Controller is a 2019 @ with a fqdn of DC19-1@TRG.LOC

Windows 10 client is @ with a fqdn of WIN2004-1@TRG.LOC

Windows 7 client is @ with a fqdn of WIN7-1@TRG.LOC

The attacker is using Kali @

#How Kerberos Armouring is to be tested

An assumption is that the domain users are known or can be guessed and saved as users.txt. Anonymous ldap bind has not been permitted since Windows 2003, so it's not possible to search AD without authenticating first. Any compromised client will provide a list of users with 'net users /domain' command. 


AS_REQ, pre-authentication is secured by Kerberos Armouring when a user's account is set to NOT require pre-authentication

Impacket is installed on Kali and the following command executed: -dc -ip trg.loc/ -usersfile users.txt -format john -outputfile preAuthHash.txt

Each of the options for the KDC Group Policy 'KDC Support for Claims, Compound Authentication and Kerberos Armouring' will be tested in turn:

  • Supported

  • Always Provide Claims Results

  • Fail authentication requests when Kerberos armouring is not available


#Supported and Always Provide Claims Results

The results unsurprisingly for 'Supported' and 'Always Provide Claims' are the same. The DC responds with an AS_REP for any account that is listed in the 'users.txt' file and the 'Do not require kerberos pre-authentication' is set.

Now for the attack itself.

Download and install Impacket, following the instructions (here).

CD into the examples directory and execute the following command.

python3 -dc -ip trg.loc/ -userfile users.txt -format hashcat -outputfile preAuthHash.txt

Review the output.

cat preAuthHash.txt

Run 'preAuthHash.txt' through hashcat.

The password file is rockyou.txt, extracted from /usr/share/wordlists/rockyou.txt.gz and copied to the Documents folder.

hashcat -m 18200 --force -a 0 preAuthHash.txt /home/user/Documents/rockyou.txt


#Fail unarmoured authentication requests Results

Setting 'Fail unarmoured authentication requests' does prevent AS_REP Roasting and the capture of the TGT.


Enabling Kerberos Armouring only protects accounts that do not pre-authenticate, preventing offline brute force attacks from AS-REP Roasting. The default behaviour for users' accounts is that pre-authenticate is enabled and encrypted by the user's password hash, Kerberos Armouring does not provide any security benefits.

Enabling Kerberos Armouring in 'Supported' or 'Always Provide Claims' doesn't prevent queries against the KDC from an attacker using Impacket. The attack is against KDC, the clients are bypassed and having Kerberos Armouring enabled doesn't provide any additional protections.


AS-REP attacks are only prevented when Kerberos Armouring by setting 'Fail unarmoured authentication requests', aka FAST. Doing so does pose a bit of an issue for heterogenous systems running Linux, MFD's and network devices inc proxies that require authentication, legacy apps and Windows 7, any normal environment. Enabling FAST only works in pure Windows environments running Windows 8 and above. The question has to be asked, why are users or service accounts exist in the domain that do not pre-authenticate?


#What's next when Kerberos Armouring fails to deliver????

  • Audit the system for any accounts that do not pre-auth by executing:

Get-aduser -filter * -Properties DoesNotRequirePreAuth | where {$_.DoesNotRequirePreAuth -eq $true}

  • Validate any account, is it still required?

  • Review any permissions of accounts that are required. Does it really require Domain Admin?

  • Reset the passwords to something complex and long, not forgetting to update the services using the account.

  • Monitor those accounts.

bottom of page