Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: Questions for Microsoft?/Matrix updates

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: Questions for Microsoft?/Matrix updates

Chronological Thread 
  • From: Eric Goodman <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates
  • Date: Wed, 27 Mar 2013 21:32:04 +0000
  • Accept-language: en-US
  • Authentication-results:; dkim=neutral (message not signed) header.i=none

I’ve been looking at the documents Brian sent as background for my task of updating the last three IAP elements in the Requirments and Gaps chart, especially for - Resist Replay Attack (B, S)


It looks like the main Kerberos authentication vulnerability in a Windows-native environment is man-in-the-middle attacks. Quoting:


“This [Windows’ caching of used credentials to prevent replay] makes replay attacks more difficult…the attacker must now use an active man-in-the-middle attack”


To my way of thinking, a man-in-the-middle attack is a completely different kind of attack than a replay attack; prior to reading this I would not have put any “man in the middle” attacks in the risk column for “resist replay attacks”. Should I include man-in-the-middle attacks here? Once you’ve got a man in the middle attack scenario, you’re at risk for more than just replay attacks….


The second link describing Kerb armoring/FAST settings make it sound like it’s only reliably relevant to security when there are Windows 2012 domain controllers in the domain AND the clients are running Windows 8, which is no doubt an uncommon combination at the current time. So I’m not clear this is a viable configuration recommendation at this point. Either way, I don’t think it’s an Alternate Means, and so it would go in the base AD Silver cookbook.


Finally, all of the links refer to authentication based on Kerberos. Brief Googling finds many papers that indicate that NTLMv2 (and of course the other less secure authentication models) are all susceptible to replay and reflection attacks, so likely fail that test without further mitigation (e.g., protected channel, or some such).



In any case, I’ve made some notes in the matrix. In doing so, I’ve assumed that the man-in-the-middle attack *is* relevant to the “resist replay” requirement.


--- Eric



From: [mailto:] On Behalf Of Brian Arkills
Sent: Monday, March 25, 2013 9:00 AM
To: ''
Subject: [AD-Assurance] RE: Questions for Microsoft?


Ah, I stuck some of those links in the original InCommon AD cookbook:




But it looks like the 2nd link I had included--which describes how one could execute a MITM replay against Kerberos--is now dead. A replacement link for that is at:


The paper suggests several possible mitigations. And note that the 1st link is one of the usual suggested mitigations, which the paper says is insufficient to protect against these attacks.


RFC 4120 describes a Kerberos pre-auth framework which can be used to protect the initial session key exchange. Microsoft implements this in WS12:, and conveniently turning that support on is required for many of the WS12 features.


From: Brian Arkills
Sent: Sunday, March 24, 2013 7:28 PM
Subject: RE: Questions for Microsoft?




From: [] On Behalf Of Capehart,Jeffrey D
Sent: Thursday, March 21, 2013 12:19 PM
Subject: [AD-Assurance] Questions for Microsoft?


Is there a list of questions for Microsoft prepared yet?


Kerberos Authentication for Microsoft Active Directory

·         Kerberos Authenticator Prevents Packet Replay

[BA] Windows domain controller issued Kerberos tickets can be subjected to man-in-the-middle replay attacks, unless you've deployed WS12 domain controllers and turned on the FAST feature, sometimes also called Kerberos armoring. Somewhere I've got a link that explains how to exploit this. And it should be easy enough to find the RFC and MS documentation that talks about this mitigating new feature/extension.

Archive powered by MHonArc 2.6.16.

Top of Page