Cliams Authentication

Sep 26, 2013 at 2:08 PM
This tool doesn't support Claims Authentication. Will there be a fix for it?
Coordinator
Oct 3, 2013 at 8:07 AM
Hi, can you provide more information with the issue you are facing? Claims Authentication is supported by the tool, but I guess the root cause is something else. Please provide more information if possible and the log file information.
Dec 19, 2013 at 7:05 AM
Hi sagarwal04,
Yes, it is possible to authenticate with claims "SP2013 is all about claims", but if the question is more what will happen when you have multiple Claims providers in the same web application and you want to choose a specific one and authenticate with the tool "SPCB2013.exe".
Then recommend the following steps:

If you try to access to AD claims you should be redirect to the authentication page:
If you try to access to Custom claims you should be redirect to the authentication page of that Custom Claim:
https://[site]/_trust/default.aspx?trust=blablablabla.Page
Then will depend in the authentication of the custom claim....

Question to BdeJager:
I didn't give a look in the code but are you making direct authentication access to Site and send the credentialcache directly there, "correct"?
If i say something you don't agree please inform me.

Kind regards,
Andre Lage
Coordinator
Mar 2, 2014 at 6:09 PM
Edited Mar 3, 2014 at 6:24 AM
Andre,

The authentication is done via setting the credentials on the ClientContext object. Authentication is done via 2 properties: ClientContext.AuthenticationMode and ClientContext.Credentials. Depending on the authentication type (selected in the dropbox) these are set.

Connecting to SharePoint Online, then AuthenticationMode = Default and the SharePointOnlineCredentials class is used.
this.ClientContext.AuthenticationMode = ClientAuthenticationMode.Default;
this.ClientContext.Credentials = new SharePointOnlineCredentials(this.UserName, this.Password.GetSecureString());
Connecting to on-premise, means AuthenticationMode = Default and the NetworkCredential class is used.
this.ClientContext.AuthenticationMode = ClientAuthenticationMode.Default;
this.ClientContext.Credentials = CredentialCache.DefaultNetworkCredentials;
or
this.ClientContext.AuthenticationMode = ClientAuthenticationMode.Default;
this.ClientContext.Credentials = new NetworkCredential(this.UserName, this.Password);
I'm not sure how this relates to multiple authentication types. I don't have a test environment for this. Ant thoughts?
Mar 2, 2014 at 6:34 PM
Edited Mar 2, 2014 at 6:35 PM
Hi BdeJager,

Thank your for the answer.
This issue for me came in the following steps,
Multiple authentication, for example FBA or AD or other one in Same web application.
For example when you authenticate with your tool for AD Method he redirect to
https://[site]/_windows/default.aspx?ReturnUrl=%2f_layouts%2f15%2fAuthenticate.aspx%3fSource%3d%252F&Source=%2F
What is correct and defined in the OOB SP Page
"You can validate this url redirects with fiddler" or web.config
Then if you make what i wrote before, the authentication will work with your tool.

Even this authentication method (code) what is correct. The problem came with the redirection from SharePoint when we access to the Site from Claims.
PS: I just try to understand if you make the direct authentication (Site) or you taking care about this redirections, but looks is direct connection/authentication to Sites.

Thanks for your attention and improves in the new Version 1.3,
Kind regards,
Andre Lage
Coordinator
Mar 3, 2014 at 6:21 AM
Hi,

If I understand correctly this issue is only applicable when two authentication types are used with one authentication provider? This results in one URL (host header) to authenticate with and you can't choose your authentication mechanism by using a different URL (like with zones).

The only way is changing the URL can be done by either https://[site]/_windows/default.aspx?ReturnUrl= or https://[site]/_trust/default.aspx?trust=.

Building the ClientContext is bases on a URL (see SiteAuth.cs). When using your method specified you determine the authentication mechanism. It seems you get an exception (you can check the logs by setting logging level to Verbose). Although this exception is raised the ClientContext is not cleared. I did not incorporate this in code.

This results in a ClientContext which is authenticated based on the URL and thus authentication type (AD or Claims). Afterwards you can connect your site, because the ClientContext is already loaded.

I guess this is what happens.
Mar 3, 2014 at 6:30 AM
Hi,

Yes, basically to warn other people,
I believe this will happen to other people, nothing more and off course give you my feedback about the tool or you can create a guidance to them "If you think is needed".

Kind regards,
AL
Mar 12, 2014 at 12:43 PM
Edited Mar 12, 2014 at 12:44 PM
Hi, I'm having problems with federated authentication as well when connection to a SharePoint Online site collection. Shows a message box saying it could not determine the realm for federated sign-in. The same credentials (and site) and work separately in a web application I've got using the SharePointOnlineCredentials and default authentication mode (no further info required).
Here's some excerpts from the log file:

12-03-2014 12:32:29.612;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782;Identity Client Runtime Library (IDCRL) could not look up the realm information for a federated sign-in.
12-03-2014 12:32:29.736;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782;Microsoft.SharePoint.Client.IdcrlException: Identity Client Runtime Library (IDCRL) could not look up the realm information for a federated sign-in.
12-03-2014 12:32:29.739;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782; at Microsoft.SharePoint.Client.Idcrl.IdcrlAuth.GetUserRealm(String login)
12-03-2014 12:32:29.741;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782; at Microsoft.SharePoint.Client.Idcrl.IdcrlAuth.GetServiceToken(String username, String password, String serviceTarget, String servicePolicy)
12-03-2014 12:32:29.744;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782; at Microsoft.SharePoint.Client.Idcrl.SharePointOnlineAuthenticationProvider.GetAuthenticationCookie(Uri url, String username, SecureString password)
12-03-2014 12:32:29.746;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782; at Microsoft.SharePoint.Client.SharePointOnlineCredentials.GetAuthenticationCookie(Uri url, Boolean refresh)
12-03-2014 12:32:29.748;JIMIT-PC;SPCB2013.exe;1.3.0.0;General;0;Exception;52a3de58-d452-4603-ac23-4260c57da782; at Microsoft.SharePoint.Client.ClientRuntimeContext.SetupRequestCredential(ClientRuntimeContext context, HttpWebRequest request)
Coordinator
Mar 14, 2014 at 1:50 PM
Hi jimitndiaye,

A colleague of mine had the same issue, but eventually he used the wrong username and password combination. Could you verify you are using the right set of credentials with the site collection URL?

Thanks!
May 18, 2014 at 11:56 PM
Did you have any luck with this? I get this error when running from one SharePoint 2013 VM, but not from another, even though both systems are on the same network, and I'm using exactly the same information to connect. At least one other post online I found suggests that it's a client-side problem that can be fixed with an update, I just haven't figured out exactly which update!