Does this tool support SharePoint 2013?

Topics: For TFSAdmin Developers, For TFSAdmin Users
Feb 21, 2013 at 5:03 PM
We are currently running TFS 2012 with SharePoint 2013 database version 15.0.4420.1017. When using the TFS Admin Tool version 2.2 to grant SharePoint permissions, the permissions do not work properly after they are committed. The users are added to the SharePoint portal site with the permissions specified in the TFS Admin Tool, but the user permissions are not respected by SharePoint. In other words, the users are listed in SharePoint Site Permissions with "Full Control", but running "Check Permissions" for that user results in "None". The users added by the TFS Admin Tool have the account format <Domain>\<UserName>.

Granting the permissions directly from the Site Permissions page in SharePoint allows the permissions to work, but creates a second user of the same name with a different account. The users created by SharePoint have the account format i:0#.w|<Domain>\<UserName>.

What is the "i:0#.w|" prefix added by SharePoint, and is this a bug in the TFS Admin Tool for not adding the same thing, or some quirk about SharePoint I don't fully understand?
Apr 9, 2013 at 12:15 AM
Edited Apr 9, 2013 at 12:16 AM
Hi tjanders,

We were also having this issue, so I did some research.

Turns out that SharePoint 2013 only supports Claims-based authentication (the "i:0#.w|" prefix denotes this mode of authentication). So only by granting rights directly in SharePoint (and verifying that you have the "i:0#.w|" prefix) can you get the new rights to work.

The TFS Administration Tool, on the other hand, grants rights using Classic mode Authentication (windows domain\user), which has been deprecated in SharePoint 2013. So until the Tool is updated to administer SharePoint rights using claims-based authentication, it won't work for SharePoint 2013 (and furthermore, you'll have duplicate entries for users in SharePoint permissions, one entry being for Claims-based authentication, and another for Classic mode authentication).

Here are some links that help explain this:

http://sharepointengineer.blogspot.com/2012/10/i0w-claims-or-classic-authentication.html#!/2012/10/i0w-claims-or-classic-authentication.html
(explains the meaning of the "i:0#.w|" prefix.)

http://technet.microsoft.com/en-us/library/jj906556.aspx
Key line: “The most common reason for failed authorization when you are using Security Assertion Markup Language (SAML) claims-based authentication is that the permissions were assigned to a user's Windows-based account (domain\user) instead of the user's SAML identity claim.”

http://extreme-sharepoint.com/2013/03/07/claims-based-authentication/
Key text: The latest version of SharePoint – SP 2013 – supports only Claims based Authentication. From Central Admin, when you create a web application, you can only specify authentication types and methods for claims-based authentication ( See below screenshot). [Note: Windows Classic mode authentication is deprecated in SharePoint 2013 and can be configured through Windows PowerShell only if needed. However, it is not recommended practice. ]

Hope this helps.

Leo
Coordinator
Apr 9, 2013 at 11:46 PM
Thanks for the detailed issue report.

I've had confirmation that TFS2012 and SharePoint 2013 in claims-based authentication mode is a supported configuration (* see below), so we'll make sure support for claims-based identities gets added to the TFSAdmin tool in a future release.
The TFS / Project Server Integration docs explicitly call it out as not supported, but it’s not clear whether that applies ONLY when integrating with TFS/Project Server
http://msdn.microsoft.com/en-us/library/vstudio/hh674251.aspx
Apr 13, 2013 at 9:55 PM
Edited Apr 13, 2013 at 9:56 PM
Hi gholliday,

One thing to keep in mind is that it seems that SharePoint 2013 supports ONLY claims-based authentication now. The way to Tool is now, it doesn create a permissions entry in SharePoint for classic-mode (Windows domain) authentication, but that entry doesn't grant the rights to SharePoint that it says (so if you use the Tool to give someone Full Control of a SharePoint portal, there is a classic-mode entry in SharePoint permissions that says "Full Control," but the user will get denied when they try anything on the portal.)

So I think that for SharePoint 2013, you not only have to support claims-based authentication, but you have to make sure the Tool never tries to grant classic-mode authentication as it does now. This is only for SharePoint 2013 -- TFS 2012 seems to support both modes, as you noted.

What I don't get is, if SharePoint doesn't allow classic-mode authentication anymore, why does it still let the tool create those entries in SharePoint permissions? Probably a bug that Microsoft needs to fix.

Leo
Developer
Apr 14, 2013 at 9:11 AM
Hi Leo
Please note that SP2013 still supports Classic authentication, but you can only configure it through PowerShell, not from the UI.
For more info abou sp2013 authentication, please refer to http://technet.microsoft.com/en-us/library/jj219571.aspx
Sep 4, 2013 at 7:40 AM
Hi gholliday,

In April you wrote that you will add support for Claims-based authentication in a future release of the TFS Admin Tool. Do you have any estimate for when this version will be released?
Dec 23, 2013 at 9:50 AM
Hello there,

It's almost 2014, are we ever going to see a new version that support SharePoint 2013?
Jul 1, 2014 at 6:45 PM
Can anyone tell me if there are any updates to the release of the new TFS Admin Tool that will support SharePoint 2013 Claims Mode Authentication? We have the exact same problem here. We are running SP 2013 with TFS 2013 and as of right now we can only provision the SP sites manually. Any help would be appreciated!
Jul 29, 2015 at 9:02 AM
Hi, I made a fix for this issue, that I published on my github account (didn't manage to make my git devs and this project's svn repo work together):

https://github.com/Vinzz/TFSAdminTool/tree/Notification

Cheers,
Vincent