Kerberos Replay Errors / SP2010 / Win2k8R2

Question

Hi All,

We have a Sharepoint instance configured, and we are using Kerberos authentication which I have proven to be working correctly.

However, after some usage by users, we start to get failing Kerberos authentication, with the following message being logged in the security log:

  A replay attack was detected.

Subject:
    Security ID:        Domain\SeviceAccount
    Account Name:       ServiceAccount
    Account Domain:     Domain
    Logon ID:       0x125140

Credentials Which Were Replayed:
    Account Name:       My.User
    Account Domain:     Domain.fqdn

Process Information:
    Process ID:     0x183e9b0
    Process Name:       C:\Windows\System32\inetsrv\w3wp.exe

Network Information:
    Workstation Name:   -

Detailed Authentication Information:
    Request Type:       KRB_AP_REQ
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -

This event indicates that a Kerberos replay attack was detected- a request was received twice with identical information. This condition could be caused by network misconfiguration

 

Does anyone have any ideas what may be causing this?

Running 2010 with the April CU on 2K8R2.

 

Thanks for your help,

 

Tim.

 

 

 

 

Answer 1

Hi Tim,

 

A replay attack on Kerberos V exploits the final message, KRB_AP_REQ, presented in Figure 1. The contents of this message were discussed earlier. The KRB_AP_REQ will usually be inside an upper layer protocol message, such as the SMB Session Setup AndX or the LDAPv3 Bind Request. If an attacker is able to access the network traffic from the victim, he will be able to extract the KRB_AP_REQ sent by the victim. In a replay attack the attacker simply attempts to re-use this message to authenticate himself to a server. In some cases the server will accept the replayed message sent by the attacker allowing him full access to the service with the victim’s credentials.

 

Accessing network traffic from the victim is essential for the attack to succeed. This can be accomplished in many ways. A common attack known as ARP spoofing uses forged ARP-reply packets allowing the attacker to impersonate the victim’s default gateway.

 

For more information about how to prevent replay attach when using Kerberos, please refer to the following article:

 

http://users.tkk.fi/u/autikkan/kerberos/AIWSC03_kerberos_replay_attacks.pdf

 

Thanks,

Rock Wang

---

Regards, Rock Wang Microsoft Online Community Support

Answer 2

Hi Rock,

 

Thanks for the article, but why are we seeing this during normal operation of SP2010? We aren't under attack from anywhere, we are on an isolated network segment in our test lab. 

 

Tim.

 

Answer 3

Hi,

 

From your reply, I think you can ignore this error. If you want to know the root cause, you can NetMon or Wireshark to analyze the packet when the replay occurs.

 

Thanks,

Rock Wang

---

Regards, Rock Wang Microsoft Online Community Support

Answer 4

Hi Rock,

 

We can't ignore this as it stops our users authenticating against SharePoint, a fairly fundamental issue. I think it may be time to open a case with PSS...

 

Tim.

Answer 5

Hi Tim,

it's been almost a year, but did you ever get this sorted!? I just started having this on a Report Server setup, and can't find anything about it anywhere!

Regards
Mikael

---

Mikael L

Answer 6

I'm seeing this alert and interested in the outcome of the case. Thanks.

---

LS@SPS

Answer 7

Hi LS_SPS,

I managed to solve this (for my purposes atleast), and in our environment it was our IPS (Intrusion Prevention System) that was dropping some of the packets since it thought that the kerberos tickets was malformed!
So if you've got a firewall/IPS in between, check that one.

Regards
Mikael

---

Mikael L

Answer 8

Im also having this problem with SharePoint 2010 and SQL Reporting Services which are configured with kerberos. Fairly frequently users receive a password prompt when viewing reports and a 'replay attack was detected' event is logged to the security log on the WFE server. We're not using any firewalls/IPS, its just a straightforward direct connection to the WFE from the client.