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 open BDC Service Application UI from Central Admin site

Here is the issue definition that If we go to Central Admin – Manage service Applications -> Businees Datas Conectivity Service Application we obtain an error:

“Something went wrong” and a Correlation ID
Error message seen:
Event ID 8085 Event Viewer The BDC Service application Business Data Connectivity Service is not accessible. The full exception text is: Access is denied.
At logs:
SPIisWebServiceAuthorizationManager: SPIisWebServiceApplication with name ‘Business Data Connectivity Service’ and type ‘Microsoft.SharePoint.BusinessData.SharedService.BdcServiceApplication’ received request with ServiceSecurityContext whose primary identity has no valid data to check against ACL.
An exception occurred while writing a service call usage entry. Exception details: System.ObjectDisposedException: Safe handle has been closed
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
at Microsoft.Win32.Win32Native.GetTokenInformation(SafeTokenHandle TokenHandle, UInt32 TokenInformationClass, SafeLocalAllocHandle TokenInformation, UInt32 TokenInformationLength, UInt32& ReturnLength)
at System.Security.Principal.WindowsIdentity.GetTokenInformation(SafeTokenHandle tokenHandle, TokenInformationClass tokenInformationClass)
at System.Security.Principal.WindowsIdentity.get_User()
at System.Security.Principal.WindowsIdentity.GetName()
at System.Security.Principal.WindowsIdentity.get_Name()
at Microsoft.SharePoint.Utilities.SPUtility.GetCurrentThreadUserLogin(Boolean fFallbackToEnv)
at Microsoft.SharePoint.Administration.SPUsageManager.LogUsage(SPUsageEntry usageEntry)

The BDC Service application Business Data Connectivity Service is not accessible. The full exception text is: Access is denied.

From Central Administration Site when we try to open BDC service we have making a WCF request to Business Connectivity Service

Name=Request (GET:http://contoso.com:3760/_admin/BDC/ViewBDCApplication.aspx?AppId=ec61c2eb-a874-4dfd-8245-0476da3d2731)
WcfSendRequest: RemoteAddress: ‘http://contoso.com:32843/b02ca86c7cb94143bb8277579dbc505c/BdcService.svc/http&#8217; Channel: ‘Microsoft.SharePoint.BusinessData.SharedService.IBdcServiceApplication’ Action: ‘http://www.microsoft.com/Office/2009/BusinessDataCatalog/BusinessDataCatalogSharedService/MetadataObjectCreate&#8217;
WcfReceiveRequest: LocalAddress: ‘http://contoso.com:32843/b02ca86c7cb94143bb8277579dbc505c/bdcservice.svc/http&#8217; Channel: ‘System.ServiceModel.Channels.ServiceChannel’ Action: ‘http://www.microsoft.com/Office/2009/BusinessDataCatalog/BusinessDataCatalogSharedService/MetadataObjectCreate&#8217;

We have facing an authentication problem on Claims authentication. Looks that “User is not authenticated”

So it bring us to “Security Token Service” Application before calling BDC request

Claims Authentication af3y2 VerboseEx STS Call Claims Windows: Adding claim with type ‘http://sharepoint.microsoft.com/claims/2009/08/isauthenticated&#8217;, value ‘False’, value type ‘http://www.w3.org/2001/XMLSchema#string&#8217;, issuer ‘SharePoint’ and original issuer ‘SecurityTokenService’.
Claims Authentication af3y1 VerboseEx We are copying claim with type ‘http://sharepoint.microsoft.com/claims/2009/08/isauthenticated&#8217;, value ‘False’, value type ‘http://www.w3.org/2001/XMLSchema#string&#8217;, issuer ‘SharePoint’ and original issuer ‘SecurityTokenService’.

For Resolution and TroubleShooting suggestions

-> Check BDC Service Application has only Anonymous Authentication has enabled and “windows authentication” has disabled.
-> Check The Security Token Service Authentications are “Anonymous” and “Windows Authentication” has enabled.
-> Check IIS > SharePoint Web Services > Only Windows Auth should be selected.
-> Check BDC Service Application Anonymous Authentication Identity has set for “IUSR”
-> Check Top Level IIS Anonymous Authentication Identity has set for “IUSR”

1. Open IIS manager
2. Highlighted server name
3. Select Authentication from center pane
4. Highlight “Anonymous Authentication” and be sure it is Enabled
5. Click on “Edit…”
6. Select the “Specific User” radio box and click “Set”
7. Enter IUSR in the “User name:” box on the Set Credentials window.
— Note you do not need to enter a password.
8. Click OK to apply, then OK to apply.

Microsoft.Workflow.Client.AuthenticationException “Authentication Failed”

When attempting to publish a workflow in SharePoint 2013 . you may facing following problem.

System.InvalidOperationException: Operation failed with error Microsoft.Workflow.Client.AuthenticationException: Authentication Failed. Valid credentials must be provided for one of the following protocols: Bearer, Negotiate. HTTP headers received from the server – ActivityId: 440bd264-3528-4880-91c9-03247a2e5e10. NodeId: WFSERVER01. Scope: /SharePoint/default/e72269ca-0e8c-4bd6-800a-9499da19f233. WWW-Authenticate: Bearer realm=”22a5da47-566b-4e0b-90f9-76752903b68e”, client_id=”00000005-0000-000

TroubleShooting Steps
1) First you have to check installation and upgrades:
It is important that any Cumulative Updates (CU) for SharePoint Server 2013 and Workflow Manager are installed in a coordinated fashion. After an update has been performed, several Windows PowerShell cmdlets must be run in order to maintain the connection between the SharePoint Server 2013 farm and the Workflow Manager farm.
Check that you have Service Bus 1.1
Check that you have Workflow Manager 1.0 Refresh installed
Check that you have Workflow Manager 1.0 Refresh Client (must installed all SharePoint Servers)
Check that you have at least SharePoint 2013 SP1.
(Article Date: 24/12/2014)

If you want to use Workflows with Microsoft supportability you need to have latest bits is running.

2) Check Network connections. (Dont miss this step is very important , Even Some Scenarios it looks working while you can save workflows and Worflow Manager Service looks connected but this issue can happen)
SharePoint Servers (WFEs) must able to reach Workflow Manager web site
And also it is a requirement that from Worflow Manager Machine (if it is a different machine) must able to browse the site url which you use to register-spworkflowservice.
Ping both machines that have ip communication
And also Check Proxies

3) Check all host file entries on every server that is there something preventing network communication .

4) Check Firewall rules and communications.

5) Test your credentials are correct or not .

7) Check Workflow Services are running , Workflow Manager Web Site is up and Application pool is alive.

8) If workflow manager is hosted on a different machine check IIS configuration that you have Windows Authentication is enabled.

9) Try re-register workflow service by scopename;
Register-SPWorkflowService -SPSite ‘http://mywebsite&#8217; -WorkflowHostUri ‘https://workflowhost&#8217; -AllowOAuthHttp -scopename “SharePoint”  -Force

10) If it doesnt work ; unregister the Workflow manager from the sharepoint farm
Get-SPWorkflowServiceApplicationProxy | Remove-SPServiceApplicationProxy
and run
Register-SPWorkflowService -SPSite ‘http://mywebsite&#8217; -WorkflowHostUri ‘https://workflowhost&#8217; -AllowOAuthHttp -scopename “SharePoint”  -Force
this will recreate the SPWorkflowServiceApplication Proxy.

(Dont Forget make an iisreset after use “Register-SPWorkflowService”)

11) Verify you have using latest activities are updated through the Workflow Manager.

$credential = [System.Net.CredentialCache]::DefaultNetworkCredentials
$site = Get-SPSite(<siteUri>)
$proxy = Get-SPWorkflowServiceApplicationProxy
$svcAddress = $proxy.GetWorkflowServiceAddress($site)
Copy-SPActivitiesToWorkflowService -WorkflowServiceAddress $svcAddress -Credential $credential -Force $true

Make your test with creating a new workflow and publish.

 

 

 

SharePoint 2010 Form based authentication problem Event ID:1315 and Event ID:8306

Assume that you have a SharePoint 2010 site with configured as Claim Based Authentiction with custom SQL Membership . You have move your site and membership database to another server and you have facing with connection problems on existing SQL MemberShip users by getting this fallowing errors

In ULS Logs:

11.13.2012 15:40:18.20 w3wp.exe (0x18C8) 0x17C8 SharePoint Foundation Claims Authentication 0000 Unexpected Password check on ‘user@mail.com’ generated exception: ‘System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).’.

11.13.2012 15:40:18.20 w3wp.exe (0x18C8) 0x17C8 SharePoint Foundation Claims Authentication fo1t Monitorable SPSecurityTokenService.Issue() failed: System.ServiceModel.FaultException`1[Microsoft.IdentityModel.Tokens.FailedAuthenticationException]: The security token username and password could not be validated. (Fault Detail is equal to Microsoft.IdentityModel.Tokens.FailedAuthenticationException: The security token username and password could not be validated.).

and In Event logs
Presence of Event ID 8306 in the Application Event Log
11/08/2012 03:29:11 PM Error SERVERA 8306 Microsoft-SharePoint Products-SharePoint Foundation Claims Authentication DOMAIN\User An exception occurred when trying to issue security token: The security token username and password could not be validated..

Presence of Event ID 1315 in the Application Event Log with Event code: 4006
Event message: Membership credential verification failed.

The problem is here if you try to login site with one of existing FBA user even password is correct , cound not able to validate password . If you create a new FBA user , there is no problem on login.
The main cause of this issue could be changes of the Machine Key.

Why ?

The Password information is stored in the aspnet_Membership table in Asp.Net Membership database . The   SqlMembershipProvider allows for passwords to be stored in the database    using one of the following three techniques:

  • Clear – the password is stored in the database as plain-text. I strongly        discourage using this option. If the database is compromised – be it by a hacker        who finds a back door or a disgruntled employee who has database access – every        single user’s credentials are there for the taking.
  • Hashed – passwords are hashed using a one-way hash algorithm and a randomly        generated salt value. This hashed value (along with the salt) is stored in the database.
  • Encrypted – an encrypted version of the password is stored in the database

The password storage technique used depends on the SqlMembershipProvider    settings specified in Web.configThe default behavior is to    store the hash of the password.
the particular encryption or hashing algorithm used by the SqlMembershipProvider is determined by the settings in the <machineKey> element.

for more information:
http://www.asp.net/web-forms/tutorials/security/membership/creating-the-membership-schema-in-sql-server-vb
http://www.asp.net/web-forms/tutorials/security/introduction/forms-authentication-configuration-and-advanced-topics-vb

So if you have move your site to another server you may consider that the MachineKey if anyhow is changed , the existing users’ passwords can not be validated.

1) First Check for the MachineKey values in web.config for related your FBA SharePoint site. If you have any difference on target site make them equalize.
2) Also don’t forget to check other servers in your farm for the same site should be same MachineKey. If any difference in MachineKeys may cause integrity problems.

Somehow If the data integrity has broken , recreating users or forcing the users reset their password will help about the issue.

 

Unable to create DataSource with using Excel Service in DashBoard Designer

The symptoms are when you lunch PerformancePoint DashBoard Designer and try to create a new Data Connection like
Right Click Data Connections and select “New DataSource” -> Excel Services and Click Ok. you should have get an error like
“An unexpected system error has occured.Additional details have been logged for your administrator.”

In ULS Logs you can see the fallowing error:

An unexpected error occurred.  Error 8205.  Exception details: System.Web.Services.Protocols.SoapException: You do not have permissions to open this file.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.PerformancePoint.Scorecards.Client.ExcelService.OpenWorkbook(String workbookPath, String uiCultureName, String dataCultureName, Status[]& status)
at Microsoft.PerformancePoint.Scorecards.DataSourceProviders.ExcelServicesDataSourceProvider.GetCubeMetaData(Boolean extendedMetadata)
at Microsoft.PerformancePoint.Scorecards.Server.PmServer.GetCubeMetaDataForDataSourceHelper(DataSource dataSource, Boolean extendedMetadata)
at Microsoft.PerformancePoint.Scorecards.Server.PmServer.GetCubeMetaDataForDataSource(DataSource dataSource)

The cause is Anonymous Authentication is not supported if you need to connect Excel Services by DashBoard Designer.

“You cannot connect to an Excel Services data source when the site or library containing the workbook you are trying to connect to is set to Anonymous Access.” http://technet.microsoft.com/en-us/library/ff191193.aspx

For solution
1) Disable “Anonymous Authentication” from IIS Management Console -> Authentication -> Anonymous Authentication

2) If you still need anonymous authentication than extend the site without Anonymous Authentication.

Sharepoint 2010 – Basic Authentication and Php .net web service connection.

A few days ago i have faced a problem that an application which coded with php try to connect sharepoint web services. And it didnt not succeed because of authentication of sharepoint system was windows authentication. PHP application support basic authentication so sharepoint does also. But the problem is when change authentication to basic or enable basic authenticaition for production site cause a security risk . So  SSL should be use but in our case it is one of out of issue.

so what we did , extending current site to new web application from Central Administration and enable basic authentication for extended site. Secure this extended site for specific application server that running php via Firewall rules and voila . Also suggested for external connection for this site using vpn or also able to use ssl if they able to change their code for it.

For Enabling Basic Authentication fallowing defined above senario :

1)  Extend your sharepoint site from Central Administration .

2) Enable basic authentication from IIS management console for extend web application. 

3) Select Authentication Provider for your newly extended site.

4) Enable Basic Authentication from configuration.

 

its done 🙂