SharePoint User A authenticated as User B

How could that happen ?

Let me give a some information about the problem:

Issue:
Intermittently Users authenticated with reverse proxy, impersonate incorrectly and User A may become User B . Based on user privileges , end users experiencing either access denied or having different user identity and permissions.

Receipts

  • 1 In the middle Device ,who redirects authentication or re-authenticate. (I am not meaning a hacker device , if you are using SSL, it is not possible easily but your system admins can). It is mostly a Reverse Proxy configured officially by your system admins.All most every modern proxy has a feature that uses Port Sharing or Re-use Session functionality. It is perfectly fine , provides high performance , prevent reauthentication and port exhaustion problem.It is works for well almost every scenario . Almost!!!
  • Session-Based Authentication , (Like NTLM or Certificate Authentication). In our scenario,We have one web application with two Authentication Provider , 1 for default CBA/NTLM and 1 for CBA/Form-Based Authentication. (Issue happens on CBA/NTLM part)
    • This configuration provides another authentication layer on SharePoint ,and force SharePoint to use Federated Authentication mechanizm , so you will see Fed Auth cookies are in use.

Some important information:

Federated Authentication over CBA/NTLM. Despite the fact that it is a token/cookie based architecture, it is depending on NTLM authentication under the cover. It means it is still a Session Based Authentication.

Why we have a problem:
Because Any middle device setting for “same TCP session re-use” is not suitable/unsupported for any “Session Based” authentication type.

The issue, It is not related directly SharePoint implementation , It is related that how the Session Based Authentication works.

Also same problem may occur ; faulty middle device software and other incorrect configurations.

How the issue happens,
Lets have a look in details for Federated Authentication over CBA/NTLM.

In TCP/Network Layer – We don’t have any authentication in this layer.
We have two end points . Point A (Reverse Proxy) to Point B (SharePoint WFE)
Before autentication a TCP connection estabilishes between that two points.

Example
Point A – IP 10.10.0.5 , Source Port : 45000  -> Point B – IP : 10.10.0.25 port 443
We are now calling this “A TCP Channel” or “A TCP Session” .

After TCP connection is estabilished then HTTP start to work in that channel.

HTTP Layer
User go to the server anymously first , the server provides authentication challanges it supported. And user provides its credential assets . This is called NTLM Handshake;

NTLMNTLM2

TCP Channel should not closed until NTLM handshake complete. It is a requirement for
NTLM authentication . Thats why , all modern web servers , use a standart/feature called HTTP Keep Alive which provides “Persistent Connection” not only NTLM handshake duration , also several requests are handled in same TCP Channel until Client or Server close the connection.

Keep-Alive-Sessions

After NTLM HandShake completed , IIS Stores the Session Information ,
TCP Channel  X  -> [Point A]  [IP], [Port] <=> Identity : Authenticated User A.  (Or Anonymous)

(If we don’t use , HTTP Keep Alive,  For every request we need to do re-authenticate . (it is not a session based authentication it is called Request Based Authentication . Well NTLM fails in that scenario. You will see flooding 401 responses on NTLM handshake.)

CBA/NTLM

Now SharePoint come in the scenario , It builds claims and tokens on IIS/NTLM Identity , creates the tokens via Security Token Service , caches the tokens with Distributed Cache or Local Cache.

SharePoint and IIS believe and trust , underlayer TCP Session belong to only one verified authenticated identity.

If you have more than one authentication provider , SharePoint also builds Federated Authentication Cookies , default 5 days duration .Cookie – Token pairs must be match for user verification.
Fed Auth Cookie sent to client with last response in NTLM handshake (Status 200 or 302).
and corresponding Token has been cached in server (default 10 hours).

All incomming requests are considered valid/authenticated based on Fed Auth Cookie – Security token pair.

What happens if SharePoint can’t find token in the cache:
If the cookie valids , It rebuilds the token  and cache the token again and updates the cookie.  (You will have another 5 days, “sliding” )
It do not re-authenticate.

What happens if the Cookie expires: Well you need to reauthenticate.

What happens if the TCP Channel closed : you need to reauthenticate. But sometimes it is not happen! Even client send close channel , in the middle devices can prevent it. Because It wants to reuse that TCP Channel.

So far so good,

But what if someone , some other user  use the same TCP Channel and send requests to the server . Well exactly what is happening if the reverse proxy does in session-reuse functionality.

SharePoint and IIS believe and trust , underlayer TCP Session belong to only one verified authenticated identity.Because how the bible says for Session-Based Authentication works.

Problematic Scenario:
Lets assume User A authenticated , have a valid cookie and continue communication without re-autheticate using Cookie-Token pairs for validation.

In mean while User B make a request (anonymous first) from same TCP Channel and requesting authentication.It is NTLM.  Well the TCP Channel is not closed , it is the same channel,  There is no possibility to understand it is the different user, Server reuthenticate the user.

After NTLM HandShake completed , IIS Stores the Session Information by overriding ,
TCP Channel  X  -> [Point A]  [IP], [Port] <=> Identity : Authenticated User B.  (Or Anonymous)
IP is the always Reverse proxy it isn’t changed.Also we have using the same TCP Channel so the port also same. It is absolute override.

Now the channel is belong to USER B instead of USER A.
Well User A still have no issues, he has a valid cookie and we have a valid token , so User A and User B communicates with the server without any problem in same tcp channel.

But the problem happen when the token is missed/expired (default 10 hours) .
What SharePoint does , verify the channel in that point ,ask to the IIS what was the Identity  ? IIS tells : it is UserB . SharePoint recreates the token and updates the cookie for UserB in a request which belong to UserA.
Now User A gets inccorect cookie and have inccorect token cached . It becomes User B by now.

Depends on permissions , either facing access denieds or have access UserB’s resources.

This problem is called “Session Hijacking“.
This is not a security hole in Sharepoint ,IIS or NTLM .

An anology :
Lets assume , you have a internet faced web site under authentication have must protected resources and if you enable anonymous access on that server in same resources .Is it considered security hole in authentication mechanizm or your code ? Of course not.

Well, there is still a security issue because of unsupported or incorrect configuration . Also it is not depended on Sharepoint, It may happen any ASP.NET application on any kind of Session-Based Authentication.

In conclusion,

Any “Session Based” authentication (like NTLM, Certificate auth etc.)  to work needs one TCP Channel per authenticated user.

SharePoint Federated Authentication for Claims Based Authentication over NTLM is depending on the underlying NTLM Authentication. NTLM is a session based authentication . Any middle device setting for “same TCP session re-use” is not suitable/unsupported for these type of authentications.

Suggestions:

  • Disabling “TCP Channel/Session re-use” feature in middle devices
  • Update in the middle devices firmware for any faulty software
  • Not using Session-Based Authentication with Reverse Proxy “Session re-use” feature or changing authentication type for any/suitable “Request-based” authentication or “token based” authentication (like ADFS) or Form based authentication.

Note: Don’t mess with “Session ” that is TCP level Session/Channel, not an application level session object or structure !! (OSI Layer 5)

Advertisements

Unable to send email from SharePoint

You have configured your SharePoint Outgoing Email but even the configuration correct you could not able to send emails from SharePoint.
For more information about how to configure outgoing emails on SharePoint please check following article:
http://technet.microsoft.com/en-us/library/cc263462.aspx

So what you can do;

First Check the ULS Logs ; You may facing following error;

Failed attempt 1 sending mail to recipients: bugra@contoso.com . Mail Subject: System Account has invited you “Blog Members”.
Error: SmtpException while sending
email: System.Net.Mail.SmtpException: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1
Client was not authenticated
at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode,
String response)     at
System.Net.Mail.SmtpTransport.SendMail(MailAddress sender,
MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode,
SmtpFailedRecipientException&

 

Usually this problem not caused by SharePoint it self, It is happening when SharePoint connects to Exchange server but Exchange is not authorize SharePoint to send emails. Why ? Because by design SharePoint use anonymous authentication to connect Exchange and OOB you can not configure SharePoint for any other authentication for using SMTP emails . If the recieve connector of the Exchange will require authentication that would be the problem .

You can test your stmp server by telnet client for anonymous authentication. or may collect Network Monitor logs that what is the communication and what is the authentication when SharePoint is trying to send emails.

For Telnet test;
1) Start a command prompt with administrator priviledges.
2) type following command:
telnet <Your SMTP server IP> 25
type EHLO

250-SIZE 15360000
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH NTLM ***** Server requires NTLM .
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW

 

In network trace you can detect as

Frame: Number = 1087, Captured Frame Length = 316, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-50-56-B3-16-5A],SourceAddress:[38-22-D6-D4-49-80]
+ Ipv4: Src = 10.10.100.20, Dest = 10.20.100.59, Next Protocol = TCP, Packet ID = 9437, Total IP Length = 302
+ Tcp: Flags=…AP…, SrcPort=SMTP(25), DstPort=46805, PayloadLen=262, Seq=41429760 – 41430022, Ack=1350847993, Win=256 (scale factor 0x8) = 65536
– Smtp: Rsp 250 -<server> Hello [10.20.100.59], 262 bytes
– Response: 250 -<server> Hello [10.20.100.59]
ReplyCode: 250, OK, queuing for node node started, or Requested mail action okay, completed
+ ReplyMessage: -<server>  Hello [10.20.100.59] —-> Sharepoint opens session with 10.20.100.59
ReplyMessage: 250-SIZE
ReplyMessage: 250-PIPELINING
ReplyMessage: 250-DSN
ReplyMessage: 250-ENHANCEDSTATUSCODES
ReplyMessage: 250-STARTTLS
ReplyMessage: 250-X-ANONYMOUSTLS
ReplyMessage: 250-AUTH NTLM —-> Exchange providing NTLM.
     ReplyMessage: 250-X-EXPS GSSAPI NTLM
ReplyMessage: 250-8BITMIME
ReplyMessage: 250-BINARYMIME
ReplyMessage: 250-CHUNKING
ReplyMessage: 250-XEXCH50
ReplyMessage: 250-XRDST
ReplyMessage: 250 XSHADOW

For Resolution:
You can
1) Giving SharePoint Computer account mail submit priviledges
2) Creating a new Recieve Connector on Exchange for SharePoint and provide only anonymous auth.

 

Multiple application pool identity senario when using NLB with kerberos auth for Sharepoint

First of all i assume that your farm is running behind a NLB cluster and configured using kerberos authentication successfully.

Here is the scenario:

Sharepoint 2010 WFE1 :
->IP: 192.168.10.5  FQDN : wfeserver1.contoso.com  , Windows 2008 server SP2 x64 , IIS 7.0

Sharepoint 2010 WFE2:
->IP: 192.168.10.7  FQDN : wfeserver2.contoso.com , Windows 2008 server SP2 x64 , IIS 7.0

NLB:
NLB Cluster IP : 192.168.10.200   FQDN: nlb1.contoso.com

We have 2 sharepoint application running on port 80:
App1: already configured using Kerberos Auth  :
Host Header : http://istanbul.contoso.com  AppPool account : Contoso\bugra

App2 : is using NTLM (just now)
Host Header : http://ankara.contoso.com  AppPool account Contoso\postman

In order for Kerberos authentication to work we configured:
When you run IIS in a clustered environment or in a load-balanced environment, you access applications by using the cluster name instead of by using a node name. This scenario includes network load balancing. In cluster technology, a node refers to one computer that is a member of the cluster. To use Kerberos as the authentication protocol in this scenario, the application pool identity on each IIS node must be configured to use the same domain user account. To configure each IIS node to use the same domain user account, use the following command:
Setspn –A HTTP/CLUSTER_NAME domain\username
http://support.microsoft.com/kb/929650

(Note: I could able to manage kerberos authentication without defining any SPN to NLB cluster on Windows Server 2008 R2. )

Defined SPN’s:

According to  KB  : SPN for the NLB cluster name: ***
SetSPN -A HTTP/nlb1.contoso.com     Contoso\bugra
SetSPN -A HTTP/nlb1     Contoso\bugra

SPN for the cluster node:
SetSPN -A HTTP/istanbul.contoso.com    Contoso\bugra
SetSPN -A HTTP/istanbul    Contoso\bugra

What happens if I want to configure an additional web application “ankara.contoso.com” , running under a different application pool “Contoso\postman”  also running Kerberos authentication ?

What about the NLB SPNs – they have a different account. This should be a problem of a duplicate SPN for NLB .Sure it is not able to do it like this way.

Solution:
1) Create another DNS A record on NLB Cluster ip:
ex:  host  A  newnlbrecord.contoso.com 192.168.10.200

2) Create SPN for this FQDN:
SetSPN -A HTTP/newnlbrecord.contoso.com     Contoso\postman
SetSPN -A HTTP/newnlbrecord Contoso\postman

And dont forget to create for your app:
SetSPN -A HTTP/ankara.contoso.com    Contoso\postman
SetSPN -A HTTP/ankara Contoso\postman

end of article.