From the Archives: How do I know which claims were retrieved?

[Originally posted April 2013 - I've been asked a few questions on this recently so thought it was worth reposting.  Screen shots are from SharePoint 2010, but this still works in 2013. Enjoy!]


Many people know that I do a lot of work with Claims in SharePoint.  Claims based authentication was introduced in SharePoint 2010 for the purpose of both authentication and authorization.  SharePoint 2013 has only strengthened its use of claims by making Claims Based Authentication the default authentication mechanism, and relegating Classic Mode Authentication to only configurable through PowerShell. 


For a while, I've been a big proponent of using claims based authentication/authorization in general, and I tend to specialize in using claims for various security related purposes within SharePoint.  When working on enforcing security policies in SharePoint, you often get into a situation where you need to figure out why a particular policy is not doing what you expected it to do.  Sometimes its simply because the correct claim types or claim values were not retrieved.  As well, sometimes you need to figure out why your claims based authentication is not working the way you expected - again, this can simply because the claim values returned were not configured correctly for the user that is logging in.


Question is: When logged into SharePoint how do I know which claims were retrieved? 



To answer this, there is a free tool available from Microsoft that has been indispensable in helping with this kind of analysis.  The tool was created by Steve Peschka of Microsoft, so big shout out to him for writing it and making it freely available.  Its called the "SharePoint Claims Web Part".  A few people have been asking me about it recently - its a pretty simple process but I thought a blog post that goes into detail about where you get it and how you configure it would be useful.

Download

First, the web part must be downloaded from here. 

Install to the GAC

Next step is to install the included DLL to the GAC:

1.       Copy “SharePointClaims.dll” to each SharePoint web front end server in the farm (i.e. c:\SharePointClaims\)

2.       Open a command window (make sure you do this as an administrator) and navigate to the location where the file has been copied

3.       Run the command:   gacutil -if SharePointClaims.dll

Configure the Web Part

Next we must configure the web part to appear where we want it to appear.  I typically display it on the home page of the site collection I'm logging into so that its the first thing I see.  Here are the steps to do that:

1.       On each SharePoint web front end server, navigate to the physical directory where the web application is located (i.e. “C:\inetpub\wwwroot\wss\VirtualDirectories\443”) and open the web.config file.

2.       Add the following SafeControl entry to the web application's web.config file on all web front ends you are using:

<SafeControl Assembly="SharePointClaims, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d01fae4d46160aca" Namespace="SharePointClaims" TypeName="ClaimWP" Safe="True" AllowRemoteDesigner="True" SafeAgainstScript="False" />

3.       Issue an IISRESET using the command window.

4.       Log in to the SharePoint site using a Site Collection Administrator account and go to Site Settings.

 

5.       Select Web Parts under Galleries.

 

6.       In “Library Tools” select “Upload a Document”.

7.       Browse for the location of the file “SharePointClaims.webpart”.

8.       Accept the default settings.

 

9.   Navigate to the SharePoint page in which you want to view the claims retrieved.  Again, I usually add the web part to the Home site collection page, so its the first thing I see after logging in.  However, if you are deploying this to a production farm, you may want to add it to a site page that end users typically do not see.

 

10. Click Site Settings, then Edit Page, then the Insert Tab, and then the Web Part button in the ribbon.  Now click Add a Web Part.

 

 

11. Select “Miscellaneous” on the left panel, select “SharePoint Claims Web Part” in the middle panel and click “Add”.

 

 

12. The web part will appear. On the Page tab, click “Stop Editing” to return to the normal view.

     
The web part will now appear as follows and you can see all of the claims that were returned from any claims provider (trusted identity provider or custom claim provider) that SharePoint is configured with.

 

Hope this is helpful.

      -Antonio

Identity Management Challenges When Moving SharePoint to the Cloud

Thanks to everyone that RSVP'ed and everyone that made it out to our first Dallas SharePoint Meetup group!  As mentioned in the meetup site, we had to move the meeting from January 20th to January 26th to avoid a conflict with the DFW SharePoint User Group meeting.  I highly encourage everyone to attend those meetings as well as they bring in some great speakers!

The presentation I gave focussed on managing identities in an environment where collaboration platforms like SharePoint have been moved from on premise servers to cloud environments like Office365.  It also discussed how identity synchronization can be a solution to solving some of those challenges and provided a live demonstration of setting up a Directory Synchronization server and synchronizing those identities in real-time..

The presentation, which contains lots of screen shots of the live demonstration, can be found here:

http://www.slideshare.net/AntonioMaio2/identity-management-challenges-when-moving-share-point-to-the-cloud-antonio-maio

Please reach out if you have any questions at all.


The following questions were raised during the meetup, which I'm still looking for some information on and hope to provide some answers for at the next meetup (at the latest):

• Which protocol does Microsoft DirSync use to transfer identities from on premise Active Directory to Office 365?
• What are some of the best practices for managing identities when developing an extranet within Office 365?

I do hope everyone had a great time and learned something. 

Hope to see everyone again at our February meetup.
   -Antonio

A Practical Guide to Information Governance in SharePoint 2013

Back in November, the great people at the Houston SharePoint User Group (HSPUG: http://www.h-spug.org/) had me out to their user group meeting to speak about Information Governance in SharePoint.  My sincere apologies to the HSPUG community for the delay in posting this presentation and notes - don't want to make excuses, but the holiday season got really busy immediately after the user group meeting and I thought I had already posted it.

We had a great turnout!  Thanks to everyone that attended and for Theresa, Gene and all the organizers!  Great to hang out with folks afterwards at the SharePint.  Despite some audio/visual issues we went ahead with the presentation and there were some great questions and discussion afterwards.

The presentation deck I used can be found here:  A Practical Guide to Information Governance in Microsoft SharePoint 2013.

Some of the main points raised during the presentation, during the demonstration or at the SharePint were:

• Keep the process of creating an Information Governance Plan practical.  If a particular section or set of questions from a governance plan template you've found or downloaded doesn't apply to your company then skip it.  Certainly consider those sections or templates, but be careful not to slow down or cripple the process by debating too much over specific sections.  If you're not sure about a section applying to your organization or not, then just park it and move onto the areas that definetly apply to your organization.  I like to keep in mind the adage that "Some information governance is better than no information governance"!
• I recommend using a OneNote notebook within SharePoint with questions or questionnaires already listed or pre-populated.  I usually include a seperate section in my OneNote notebook for each of the following governance topics.  The topics used of course need to align with the business needs of the organization (again if a section doesn't make sense then remove it).
• Overview on Information Governance and on the Process the Organization will follow
• Operational and IT Management
• Site Administration and Managemenet
• Content Management, Policies and Procedures
• User and Permission Management
• Training
• References
• Using such a OneNote Notebook within SharePoint allows you to do the following:
• Review specific sections of information governance with your governance committee or working group right within SharePoint.  You can break up the governance planning process into multiple meetings that align with the sections in the OneNote Notebook.  Depending on the size and complexity of the organization each section may need multiple meetings.
• Answer governance questions, capture notes from the meeting, share governance recommendations and decisions right within the OneNote Notebook right as the meeting progresses.  Share the outcome of the governance commmittee meetings in real time with a larger audience or with the entire organization immediately (either during or immediatly after the meetings).  All that content resides within the OneNote notebook which is already posted to SharePoint and is updated as you take notes within the governance committee meetings.
• Check off sections and governance policies within the OneNote notebook as they are completed.
• Highlight questions or sections requiring work to a larger audience, as they are identified within (or immediately after) the governance committee meetings.
• Share governance decisions and policies with the organization much faster, instead of waiting for a report to be prepared after meetings are concluded.
• A great question came up: Any suggestions for how you work with different groups within an organization that differ greatly on opinion related Information Governance topics/policies?
• This is always tough, when you have individuals as part of the governance discussions and planning process that differ greatly in opinion and are not willing to come to a compromise or hear each other out. 
• My suggestion is to keep the governance planning process really focussed on addressing the business needs for managing information, sharing information and/or protecting information such that it benefits and aligns with the business.  Information governance plans should not simply conform to or service any particular individual's opinions or comfort level.  In cases of significant or continual disagreement, the discussion often needs to be raised above a particular department or individuals's opinions.  Always try to keep the discussion focussed on what the business needs. 
• One approach is to creating smaller working groups around specific sections or concerns and take particular topics out of the larger governance commitee.  This can allow a particular topic to be debated and researched while the remaining govenrance planning process continues to progress.
• Another approach is to designate 1 individual to own a particular topic that might be contentious (a person that is not emotionally or personally attached to the topic) and have them research that topic and come back with impartial recommendations or best practices for the governance commitee or working group to consider.
• This type of situation also highlights the need to elect a strong leader for the governance planning process.  At some point, if a topic is debated and debated with no resolution, sometimes a decision simply needs to be made by 1 person and everyone needs to try to live with it for some time. That decision could include simply parking that particular topic and moving onto other information governance related topics or decisions.  Ultimately, you want to ensure that the entire information governance planning process is not crippled by 1 particular topic or debate.

 
If you'd like more information on my governance planning template, please reach out via email at antonio.maio @ protiviti.com.
 
Thanks again HSPUG for having me!
   -Antonio
 

Identity Synchronization between Active Directory and SharePoint Online - Part 2

This article is the second in a series on how to configure identity synchronization between on premise Active Directory and SharePoint Online within Office 365.

Part 1

In the previous post in this series we started this topic by covering the following:

-          Introducing the concepts of Identity Synchronization and Federation

-          How to synchronize a .local domain

-          How to prepare Active Directory for Directory Synchronization

                                                                                           

You can access part 1 in this series here: http://sharepoint.protiviti.com/blog/Lists/Posts/Post.aspx?ID=142.

 

We’ll continue here with the step by step process of setting up Directory Synchronization between your on premise Active Directory domain and your Office 365 tenant.

Setup Your Domain in Office 365

The next step in the process of setting up directory synchronization is registering your domain in your Office 365 tenant.  You do this by logging in to your Office 365 tenant as a tenant administrator and clicking DOMAINS in the left hand menu.

You’ll see your Office 365 domain listed (*.onmicrosoft.com), but you need to add your on premise domain to this list and Microsoft needs to verify that you own that domain.  This must be a publicly routable internet domain and it must be the same domain that you setup as the Alternate UPN Suffix in the 1^st post in this series.

 

Click +Add domain in center of the window.   

There are 3 steps in the process of adding a domain:

Step 1 here, specifying the domain name and confirming ownership is the most critical step to Directory Synchronization. 

 

-          Click Start Step 1 and specify the domain name.  In my case I used maiolabs.com.  Click Next.

-          Now you’ll need to confirm that you own this domain.  This can be done a couple of different ways.

If your domain is managed at GoDaddy, Office 365 will allow you to confirm ownership simply by performing a secure login to your GoDaddy account that you use to manage this domain.  To do this, click Confirm Ownership on the screen above.  A window will appear asking you to sign into your GoDaddy account.

If you use this option to confirm ownership of your GoDaddy domain, the process will complete immediately and you can continue to Step 2 and Step 3 with adding a domain. 

Alternatively, if you manage your domain elsewhere, you can follow the manual steps required to verify ownership.  Simply click Follow the manual steps in the window above.

The manual steps require you to add a particular record to your DNS configuration at your DNS hosting provider.  I typically add the TXT record with the code specifically provided by Microsoft here because it’s quite simple to do.  Once added to the DNS record, you’ll have to come back here and click Done, Verify Now.  This typically does not work immediately after adding the DNS record.  You usually have to wait several hours for the record to be updated and accessible.  You can return to DOMAINS in your Office 365 tenant later and try to verify again. 

Ensure that you spell the code correctly when you add it.  It can take up to 72 hours for the updated DNS record to be accessible by Office 365 to verify ownership, and you don’t want to have a typo require you to have to wait excessively. 

Once the domain ownership is verified, you must proceed through Step 2 and Step 3 in the process of adding a domain, however each step allows you to skip that step once you’re into it.  Once Step 3 is complete, your publicly routable internet domain will now appear in your domain list with the status Setup complete.

 

Activate Directory Synchronization in Office 365

The step in this process is to activate directory synchronization in your Office 365 tenant.  You do this by clicking USERS in the menu on the left and then clicking Set up beside Active Directory synchronization.

Clicking Set up will bring up the following screen.  Click the Activate button.

This will bring up a confirmation window which contains a very important point about this process.

The important point here is that once identities and groups are synchronized to Office 365 from an on premise AD domain, those objects can only be edited within the on premise AD domain.  Click Activate here to continue.

Installing and Configuring the Directory Synchronization Server On Premise

Now it’s time to actually install and configure the Directory Synchronization server - this server application is also called DirSync and the install file is DirSync.exe.  You can download DirSync.exe by clicking USERS in the left hand menu, then clicking Set up beside Active Directory synchronization as shown above, and then clicking the Download button.

DirSync must be installed on a domain joined server.  In its earlier releases DirSync had to be installed on the domain controller itself, but now it can be installed on its own dedicated server, which is recommended.   Ensure that you have the following prerequisites in place for the Directory Synchronization Server before proceeding with the install:

-          Domain joined to the Active Directory forest you will be synchronizing.

-          64 bit Windows Server Operating System (2008 with SP1 or later, 2008 R2 with SP1 or later, 2012, 2012 R2, all either standard, enterprise or data center)

-          .NET 3.5.1 and .NET 4.0 Frameworks must be installed

-          PowerShell must be enabled in Windows Server 2008

Other notes:

-          Access to the computer running DirSync should be limited to users who have access access and permissions to make changes to the Active Directory domain controllers.

-          Ensure that Microsoft Online Sign-In Assistance is not already installed.  If it is, uninstall it.  The DirSync installation will try to install this and the entire installation will fail if it is already installed.

-          Only 1 instance of DirSync can be installed within an on premise AD forest

-          DirSync will synchronize all domains within the AD forest

To install and run DirSync, you must have the following permissions:

-          Local administrator permissions to the computer running the Directory Synchronization server

-          Administrator permission to the local Active Directory forest (part of the Enterprise Administrators group)

-          A service administrator in the Office 365 tenant

During the DirSync install process, you’ll need to provide the username and password for the on premise Active Directory administrative account and the service administrator for Office 365.  When installing DirSync, the Configuration Wizard will create a service account that is used to read from the local Active Directory and write to Azure AD. The wizard creates this account using both your local Active Directory admin permissions and your cloud admin permissions, which must be provided during the installation process.

You can deploy and host DirSync within an Azure VM as long as you have network connectivity  between your on-premises network and your Azure Virtual Network.  However, that's beyond the scope of this article.

Installing DirSync.EXE

Once you’ve downloaded DirSync.exe to the Directory Synchronization server, start the installation process:

-          Welcome screen - click Next

-          Accept the EULA and click Next

-          Select the installation folder and click Next

-          The installation process takes about 10 minutes

-          When the installation process is complete, ensure the Start Configuration Wizard now check box is on and click Finish

DirSync Configuration Wizard

Once the configuration wizard starts, you’ll be asked to specify the Azure Active Directory Administrator credentials.  Enter the username and password of the service administrator account for Office 365 and click Next.

Click Next.  You’ll then be asked to specify the Active Directory Enterprise Administrator credentials.  Enter the username and password for an administrative user that is part of the Enterprise Administrators group of the local Active Directory and click Next.

-          You’ll then be asked if you would like to Enable Hybrid Deployment.  This feature allows Office 365 (Azure Active Directory) to write changes to identities back into the on premise Active Directory.  An example of this is if a user changes their password – with a Hybrid Deployment, this change will be synchronized back to the on premise AD.  Select Enable Hybrid Deployment and click Next.

-          You’ll then be asked to Enable Password Sync.  This feature allows password changes within the on premise AD to be synchronized to Office 365.  Although this is not true single sign on, it does make the end user experience much better because they use the same username and password for both on premise resources and Office 365, even as passwords change.

Once the configuration process is complete, you’ll be asked to run your 1^st directory Synchronization.

Click Finish.  The directory synchronization process will begin immediately.

If you return to Office 365, click USERS in the left hand menu and then Click Active Users, after a few minutes you’ll see user accounts and groups from the on premise AD appearing in your Office 365 tenant.

My on premise user accounts here are obviously dwarfs.  J  You’ll notice that user accounts that are synchronized from on premise AD have a status of Synched with Active Directory and, as mentioned earlier, cannot be edited in Office 365.

In order to login to Office 365 and SharePoint Online with these new users, you’ll still need to assign an Office 365 license to each user individually here.  This directory synchronization process will now occur automatically every 3 hours.

Once licenses are assigned, user accounts that were synched from on premise AD can now login to Office 365 using their same on premise username and password!