Securing SharePoint 2013: It All Begins with Deployment

This post is the first in a series where I'll introduce various concepts and considerations for security in Microsoft SharePoint 2013.  These articles will serve as an introduction to those that are either new to SharePoint, or to those that have SharePoint up and running and are looking at the various out-of-box and third-party options available to secure their sensitive information.

---

 

Securing Microsoft SharePoint starts at the time of deployment. When first deploying SharePoint to a staging or production environment there are specific best practices that must be employed to ensure a secure and well managed environment. In particular, using appropriate user accounts for various necessary functions is a critical step. This concept is not new to Microsoft SharePoint 2013 as it also applies to Microsoft SharePoint 2010. However, it is of significant importance and therefore deserves mention again.

The purpose of using multiple accounts is to ensure proper separation of responsibilities and activity auditing. Best practices recommend that least privilege user accounts are used for specific deployment and management functions. In other words, specific user accounts are created for very specific functions and those accounts are granted only the privileges required to perform that function—nothing more.

There are varying views on how many user accounts are necessary when deploying Microsoft SharePoint, but most experts agree that at minimum 3 different accounts are necessary to deploy SharePoint to enterprise environments.

1.      Setup User Account
This account will be used specifically for running the SharePoint setup wizard, the product configuration wizard and for installing any patches, service packs, cumulative updates or hot fixes. You must login with this account when running the SharePoint setup and configuration wizards, or if you are installing any updates.

This account must be a domain user account and added to the local Administrators group on each server in the SharePoint farm.  An example of how this account is often named is: domain\sp_setup_user

The Setup User Account should not have any special administrative privileges on the SQL Server system as long as SQL Server is on a separate system or VM from the SharePoint servers. When running the SharePoint setup and configuration wizards, these processes will use the Setup User Account credentials to create databases and SQL logins for other SharePoint accounts. However, despite the lack of administrative privileges to the SQL Server system (as recommended above), before starting to setup SharePoint, you must assign the Setup User Account to the securityadmin and dbcreator roles in SQL Server.

2.      SQL Server Service Account
This account is used specifically by SharePoint when it tries to access data from SQL Server. The SharePoint setup wizard will request this account during the setup process, so you should create it before you begin the SharePoint setup. It needs to be assigned to MSSQLSERVER and SQLSERVERAGENT services when you install SQL Server. An example of how this account is often named is:  domain\SQLService

The account requires no special domain permissions. This account will be given all appropriate rights to SQL Server during the SQL Server setup process. Best practices dictate that this account needs to be a user account in the Active Directory domain and it should be secured according to your IT security policies.

3.      SharePoint Farm Account
This account is the farm administrator’s account and it is all powerful within SharePoint. This account will be used by the Farm Administrator to login to the SharePoint Central Administration console. This account is used to actually run the SharePoint farm. For example, during the setup and configuration process, several critical SharePoint services (including the timer service) will be configured to use the Farm Account as the identity under which they run. An example of how this account is often named is: domain\sp_farm_user

When running the Product Configuration Wizard, you will be asked to specify this account. The wizard will use the credentials you are logged in as (that is the Setup User Account) to give the Farm Account ownership of the Config database.

There are some exceptional cases where additional user accounts are needed when deploying SharePoint. For example, if specific SharePoint services require their own account for specific auditing and security purposes. For each SharePoint deployment accounts, there are some general best practices to consider:

• All accounts should be Active Directory domain accounts, so that credentials, password expiry, and general user account management can be centralized. Local user accounts on the servers involved should not be used. This is especially important in the case of critical infrastructure like SharePoint.

• Do not use personal accounts when deploying SharePoint. The Setup User Account becomes owner of the SharePoint farm. The Farm Account becomes dbowner of the SharePoint Config database. There are many places where the account, and its email address, get integrated into the farm. Ensure that you use a dedicated account for the Setup User Account in particular, so that the farm isn’t owned by your personal account which has privileges on other systems. In addition, personal accounts change if your role changes, so it is important that a personal user account is not left owning the SharePoint farm.

• Configure one centralized email account for all managed service accounts—do not use a personal email address. The setup user account (and other service accounts) should have an email addresses reflecting that they are part of the SharePoint infrastructure. For example, assign all accounts the address “sharepointservice@company.com” as the email address in Active Directory. When SharePoint sends out periodic notifications related to server health and maintenance, with just one centralized email address, all notifications related to SharePoint will go to a single email inbox that can be monitored by the entire SharePoint team.

User account best practices are also covered in great depth in the Microsoft SharePoint 2013 Deployment Guide, which can be downloaded from here:

http://www.microsoft.com/en-us/download/details.aspx?id=30384.

SharePoint administrators are encouraged to review the necessary details in this comprehensive document to determine the user account requirements for their environments.

 

   -Antonio

Protecting Your Social Media Accounts from Hacking

So, this post is not about SharePoint; but it is a computer security topic that is becoming increasingly important in our social media charged world: How to protect our many social media accounts from hackers.

I came across a great article in the Globe and Mail recently, that I wanted to share with people which presents 10 concrete steps to protect businesses from having their social media accounts hacked. 

http://www.theglobeandmail.com/report-on-business/small-business/sb-tools/top-tens/ten-ways-to-protect-your-workplace-from-twitter-hacking/article14084647/

Social media accounts present hackers with another attack vector by which to compromise organizations.  Often, due to social media still being quite new for many businesses, they lack corporate security policies around social media - policies like who can use those accounts, how are those accounts secured, what type of corporate information can be shared via social media, etc.  Sometimes, due to the often informal nature of social media, individuals may feel that these accounts fall outside the realm of corporate information security.  However, social media and their related accounts (Facebook, Twitter, Instagram, etc.) can often be easy inroads into a businesses' computer infrastructure for those that would either steal corporate intellectual property, or try to compromise computer security for other criminal purposes.

The article goes through 10 best practices which are very practical steps that I see many large enterprises adopting in my own work.  Some of them are very common sense but quite critical to organizations protecting their information:

• Provide employees with easy to follow guidelines
• Define what's confidential

Some of the other steps discussed are slightly more nuanced but definitely important to include when developing a corporate security strategy:

• Look at your employees differently
• Be social but be smart
• Don't link all your accounts

Overall, if you or your business engage in social media at all, I highly recommend giving this article a thorough read.

In the spirit of full disclosure, the article happens to be written by my wonderful wife Laura Maio (twitter: @LJMaio).  :-) 
   - Antonio

How to Disable the Windows Explorer View in SharePoint

In working with several customers to secure sensitive information in SharePoint, we've found that there are times where some customers still want to use the Windows Explorer view in SharePoint. This is due to a couple of reasons:

• The fact that many users are used to copying/moving files and folders through an Explorer window.
• Its one of the only ways in SharePoint to copy multiple folders at a time into a SharePoint library.

However, we have found that the Windows Explorer view does have several inherent security holes and these holes do pose significant risk to customers in the military or DOD environments. For example, if SharePoint permissions only give a user read access to a file, often users are still able to rename the file through the Windows Explorer view. In some cases users with read access to certain files are even able to delete those files.  There are other similar holes.

As well, Microsoft has stated that when using claims based authentication with SAML security tokens that the Windows Explorer view in SharePoint 2010 does not work:  http://technet.microsoft.com/en-us/library/hh706161.aspx.  It goes on to say that this feature (and others) do not work because claims based authentication does not generate a Windows Security Token which is required for this feature.  From my experience in this situation the explorer view partially works in that it can be accessed but it does not respect ACLs correctly.

As a result, we often recommend to customers that they "turn off" the Windows Explorer view in SharePoint and force users to use the web view. With SharePoint 2013, this option is even more viable because the web view now allows users to drag and drop files from their Windows desktop into the web browser and have those files copied into the SharePoint library. An awesome feature if I may say so!

"Turning off" the Windows Explorer view is a bit of a misnomer though. There is no way, that I can find to completely turn off the Explorer View to SharePoint from the SharePoint server. However there are several methods for preventing end users from accessing these Windows Explorer view. This blog post will describe each of these methods in detail.

Method #1

Administrators can disable access to the Windows Explorer view by modifying the “User Permissions” on the web application. This is done within Central Administration:

• Click Manage Web Applications and select your web application
• Click the User Permission button in the ribbon
• Find the “Use Remote Interfaces” permission in the list and uncheck it (this will also automatically uncheck the “Use Client Integration Features” permission as well)

This will disable the “Open in Explorer” button in the SharePoint ribbon for all libraries in all sites in the web application.

There is a problem with this method though - it also disables all access to open documents in SharePoint from the open dialog in MS Office applications. As well, access from SharePoint Designer and access from all client object model applications will be also be disabled. Please note that the Open Dialog, like the Windows Explorer view also does not fully respect SharePoint permissions. So, this method may or may not work for your environment.

Method #2

I have found that simply removing the “Open in Explorer” button all together from the SharePoint ribbon can be an effective way to prevent access through the Explorer view. There is a good blog post here on how to accomplish this here.

[previous link was incorrect - this is now fixed]

This method is effective because you open Windows Explorer on your desktop and paste the URL to a SharePoint library Windows will automatically open a web browser and navigate to the SharePoint web view of the library. It does not actually open in Windows Explorer. This allows the open dialog in Windows to still navigate to a file in a SharePoint library and open it, but prevents users from effectively using the Explorer view.

This method of course may not be fool proof, meaning a malicious user may still find a way around it. However it would cover 95% of cases where end users are simply trying to open documents that they are permitted to access. As well, this method still allows users to open SharePoint documents from the Open dialog in MS Office applications, SharePoint Designer and client object model applications.

Method #3

A third method that is effective and allows you to still maintain client object model access and access through the Microsoft Office open dialog is the following procedure which modifies the permissions required to access the Open in Explorer button. This procedure will result in the “Open in Explorer” button in the SharePoint web interface to still be visible and enabled, but to only be accessible by users that have the “ManageWeb” permission on the site. This would allow you to configure SharePoint to allow site owners to have access to the Windows Explorer interface, but not regular users that only have contribute permissions. Follow these steps to accomplish this:

• On the SharePoint 2010 server navigate to the folder \Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\CONTROLTEMPLATES
• Make a copy of the file DefaultTemplates.ascx
• Open DefaultTemplates.ascx in Notepad:
• Search for the following string ID=”OpenInExplorer”
• Below that string change PermissionString=”UseClientIntegration” to PermissionString=”ManageWeb”
• You will find 2 instances of ID=”OpenInExplorer” – you’ll need to make the change in both places
• Save the file and issue an IIS Reset

You’ll then find that a user that is a site owner can click on the “Open in Explorer” button and still access SharePoint through the Explorer interface, but users that are not site owners (or who do not have the Manage Web Site permission) can click on the button but they’ll get an “Access Denied” message. This works even if a user tries to create a shortcut to a URL and access the Explorer view from that shortcut, or if they try to map a network drive to the SharePoint library URL - if they don't have appropriate permissions they will receive an "access denied" message:

Method #4

A 4th and probably more extreme method is to in fact disable WebDAV itself on the IIS Web Server. To accomplish this follow these steps:

• Click the Windows "Start" button on your Web server, and select "Administrative Tools." Click "Internet Information Services Manager" to open the configuration utility.
• Click the Web server name in the left panel. A list of websites expands. Click the website name you want to edit, and click "Web Services Extensions" in the website directory.
• Right-click the WebDav entry in the list of extensions, and click "Prohibit," then click "OK" to confirm that you want to disable WebDav.

Please note: I have not tested this last method myself so your mileage may be different. Ensure that if you go this route that you fully test the SharePoint server and determine if access to files through other mechanisms (MS Office Open dialog, SharePoint Designer, client object model applications) is also affected. As well, these instructions may vary slightly depending on your version of IIS.


- Antonio

Today's Presentation at SPTechCon: Introduction to Security in Microsoft SharePoint 2013

Thank you to everyone that attended my session this morning at SPTechCon Boston 2013.  We had a pretty packed room and some really great questions.  I really appreciate everyone making the time to attend at 8:30am after the excellent party that Axceler hosted last night.

Its been an awesome show here!  This is my first time speaking at SPTechCon and I have to say that the show staff have provided great support to the attendees and the speakers.  Big thanks to Dave, Staci, Katie and their crew.

In addition to the conference site, my presentation slides can also be found here: 

Introduction to Security in Microsoft SharePoint 2013

My contact info is in the slides and on this site.  Please do reach out if you have any questions or feedback at all.

Enjoy the rest of SPTechCon and Boston.
   -Antonio

Why do Enterprises or Governments secure their information?

This post is the first in a series that will review fundamental security features in Microsoft SharePoint 2013.

When I speak about SharePoint security I often start off with a discussion about why organizations secure their information. What really drives people to implement secure measures to control and govern information?  For a business owner or C-level executive it may be obvious, but for the average employee it may not be.

To be clear, this article is not intended to deal with people’s personal information. It specifically talks to how enterprises or governments deal with and secure their sensitive internal business information. So let’s begin here...

What drives people to secure information?

We’ve all heard statistics about how the information we’re creating and storing is growing at an exponential rate. Many of us now regularly measure database sizes in Petabytes. In fact, most enterprise content is unstructured data (ex. documents) which of course poses its own challenges for management and security. In a 2013 eWEEK article, Gartner analysts predicted that enterprise data will grow by 800 percent over the next five years, and that 80 percent or more of that new data will be unstructured.

We often hear how organizations are centralizing the storage and access to information in order to promote better collaboration, but for many this raises security concerns that must be dealt with – by the way, SharePoint provides just such an excellent platform on which to accomplish this.  We also know that every organization has some meaningful amount of information that is considered sensitive. We often hear about how that sensitive information must be secured, controlled and governed. 

However, for many individuals who own or have responsibility for this information usually treat its security as an afterthought. Why is that? With all the statistics and talk about the amount of information we’re generating, how centralizing it promotes collaboration but raises security concerns and with the large amount of that information that’s considered sensitive to organization, why is its security not top of mind.

From my experience in the security industry over the last 15 years, working with many large organizations around the world and with many individuals who own content or are responsible for content, I’ll put forward a theory: people feel a true need to secure information when they have a personal connection to it, when they truly understand the risk which exposure of that information poses and when the impact of such an exposure affects them directly.

Rarely do people secure information for the good of securing information or because it’s the right thing to do. There are of course exceptions, but in general people are looking out for themselves, not the good of the organization. This isn’t a pessimistic view. I believe it’s just natural human behavior... at least it is today. Culture is slowly changing on this front so who knows how people will feel or think of securing information in the next few years.

Let me summarize the cases in which I have seen people really driven to secure their information. I have found that certain people (outside the security industry) will be driven to secure information for very specific reasons. I’ve categorized each as a set of risks and summed them up in a high-level driver.

1. Reducing Your Liability
For many industries, the exposure of sensitive corporate information can have very negative impacts to business. The risks include:

• Compliance violations that result in extremely heavy fines (depending on the industry)
• Sanctions and legally imposed restrictions on business
• Loss of business reputation (this could be bad PR and of course possibly result in loss of customers)

These are of course very significant risks to the business - they are liabilities to the business. I group these types of risks under “Reducing your liability”.

Exposure of this type of information may be malicious, but more likely it will be inadvertent or accidental. A business owner or a C-level executive will likely be very concerned about such risks and be driven to secure sensitive information in order to protect the business. Business owners, C-level executive, board members are typically very motivated to reduce these liabilities. This is typically because they are better positioned to understand the risk and the impacts can directly affect them personally (bottom line, law suits, the buck stops with them, loss of employment, etc.).

The same risks exist for government departments, when you consider government departments can have their budgets cut, such exposures can hit the media very hard or department heads can lose their jobs.

The average employee may or may not be concerned about these risks to the business or department. Depending on the employee, they very likely don’t even understand how these impacts can affect the business nor what information is sensitive to the business.

2. Protecting Your Investments
This particular category of risks typically applies to enterprises, much more so than governments. The risks include:

• Loss or theft of intellectual property (know how, designs, plans, budgets, vision documents, etc.)
• Exposure of customer lists
• Exposure of acquisition/merger information or budgetary/accounting data
• Loss of competitive advantage
• Compromising of internal (or external) business systems – which could have a trickle-down effect of loss of customers of course

Once again, a business owner or C-level executive will likely be very concerned about such risks and be driven to secure sensitive information in order to protect the business. This type of data loss or exposure of sensitive information can greatly affect the business’ performance. For these types of individuals their compensation or bonus is typically highly tied to the business’ performance. A CIO or CISO will typically be measured critically (or terminated) when these types of exposures occur.

For a typical employee, although part of their salary/bonus might be tied to company performance that percentage is typically much lower than that of executives. As well, they often will not understand which information is sensitive and how the loss of that information will affect the business. Unless you have a clear way to identify which information is sensitive and can effectively educate employees on how they should handle that information, their ability (and desire) to help protect against data loss will be limited.

3. Public Safety or Mission Success
This category typically applies to government agencies like departments of defense throughout the world, Homeland Security in the US, as well as other government departments. The risks include:

• Exposure or theft of classified mission data (which can compromise military missions and endanger personnel)
• Exposure of homeland security information (which can endanger the general public)
• Compromising of critical government services and security systems

In these cases, the personnel that deal with the data involved are typically well trained in how to handle this type of sensitive information. As well, often people go into these areas of work because they have a desire to be part of the public service, or they wish to work in a military or service that protects the public safety. As such, this particular category may be an exception to the theory I put forward earlier. 

There have been some high profile leaks of classified government information in the last few years, but in general the people that work and deal with this type of information do tend to protect it because they understand the very negative and dangerous impacts that can happen with its exposure and because typically protecting this information is the right thing to do.

4. Health Information
This represents a new risk category in recent years that I’ve been researching lately. I’ve been to a few sessions that specifically talk about the impacts that can occur when personal health information is stolen or exposed. This leans more towards the personal information side (which I said I wasn’t going to talk about) because we are talking about personal health information. However, it’s included here because it affects the companies and government agencies which store/manage that information.

For example, in the state of Florida a personal health identity can be illegally purchased for approximately $56,000. For a non-insured individual purchasing such an identity they can make use of it to illegally get health care, causing the original owner of that insurance plan to have their premiums used without their knowledge. Even more dangerous than that, the person illegally using the health identity can cause data within the health record to be modified. For example, if their blood type is type A and that gets applied to the original health record, but the original owner has type B-negative. If the original owner of the insurance plan is then in an accident and needs a transfusion, this record modification could have extremely dangerous consequences.

In this case, government agencies and health care organizations that manage personal health information must insure that proper security measures are put in place in order to prevent these types of risks or exposures from happening. In these cases, typically both the administrators and the employees working in the health care industry do care about these types of risks, and are starting to get a sense for the very dangerous impacts that can occur. The health care industry has traditionally been slow to adopt technology solutions, but that has been changing in recent years.

Overall
(I realize this first post in fact has nothing to do with SharePoint, but I believe these concepts are important to understand when we generally look at implementing security measures.)

To summarize, in many businesses and organizations the average person tends to feel a true need to secure information when they have a personal connection to it, when they truly understand the risk which exposure of that information poses and when the impact of such an exposure can affect them directly.

The ideal situation in any organization would be if each and every individual does in fact care about securing and properly handling sensitive information. This is really what we should be striving for, and many of organizations are starting to tackle this head on.

We have found that the best way to achieve that is to involve all employees in the organizations security strategy. This is done through education, as well as traditional security mechanisms - education of employees so that they understand which information is sensitive and how they should handle it, and so that they are aware of the very real impacts of information exposure, both to the business and to them personally. As well, make employees accountable when they handle sensitive information, and that accountability needs to be obvious (for example, if someone prints a sensitive document their name should be stamped all over it, so that if they leave it in a hall way everyone knows who left it).

This type of education and accountability helps ensure all employees feel the real need to secure the organizations information and its one of the best lines of defense against both inadvertent and malicious exposure of sensitive information.

SPTechCon Boston 2013 – Introduction to Security in Microsoft SharePoint 2013

Session: 8:30am to 9:45am on Wednesday August 14, Room: Back Bay D

I’m at the SPTechCon Conference in Boston this week. This conference is held twice a year, once in San Francisco and once in Boston, and it always gets a good crowd - today (Sunday) is no exception. The SPTechCon crew always puts on a great show!

On Wednesday morning this week, starting at 8:30am, I’m giving a session titled “Introduction to Security in Microsoft SharePoint 2013”. You can find details about the session here: http://www.sptechcon.com/boston2013/classes.html. It’s an intermediate session providing high-level information about why we secure our information and on SharePoint security features, but it also it dives deeper into a couple of those security features that are fundamental to organizations securing their information.

While at the conference I’m going to blog about some of the topics I talk about in my session. I’ll be spending some time in the exhibit hall at the TITUS booth as well, so if you’d like to connect please feel free to stop by.

Hope to see you there.
-Antonio

SharePoint Summit 2013 - Best Practices for Security in Microsoft SharePoint 2013

Thanks to everyone that attended my session yesterday afternoon in Toronto at the SharePoint Summit 2013.  I had a packed room for the last session of the day, so a big thank you to everyone for sticking around. You can find the presentation I gave here:

Best Practices for Security in Microsoft SharePoint 2013

There were some great questions at the end of the session, in particular around anonymous Access to SharePoint sites and one that I could not answer well on permissions related to SharePoint Apps (related to the new App Model in SharePoint 2013).

Permissions for SharePoint 2013 Apps

I did a bit of reading and research today into how permissions work for SharePoint Apps in the new App Model.  A few quick points to know are:

• An app for SharePoint requests the permissions that it needs during installation from the user who is installing it.
• A developer must request, through the app manifest file, the permissions that the particular app needs to be able to run.
• An app must be granted permissions by the user who is executing the app.
• Users can grant only the permissions that they have.
• The user who installs the app must grant all the permissions that an app requests or not grant any permission. The user can grant an app all or nothing in terms of the permissions requested.

In my readings I found some great MSDN articles related to Authentication, Authorization and Permissions related to SharePoint 2013 Apps here:

• Authorization and authentication for apps in SharePoint 2013
• App permissions in SharePoint 2013

Please do reach out if you have any questions at all.

Enjoy.
   -Antonio

Ottawa IT Camp - Introduction to Developing/Deploying Apps for Office and SharePoint 2013

A big thank you to everyone that attended my session at the Ottawa IT Camp on Saturday May 4th.  There were some great questions and I'm really glad everyone found the session helpful.  Thanks for the feedback.  As well, big thanks to the organizers for putting on a great day!

In addition to on the Ottawa IT Camp web site, you can also find the presentation deck that I showed here:  Introduction to Developing and Deploying Apps for Microsoft SharePoint Office 2013.

Please let me know you have any follow-up questions.

There was one remaining question about development environments for creating SharePoint 2013 Apps that I'm working on answering now, and I'll post the answer here as another blog entry.

Enjoy,
 -Antonio

How do I know which Claims were retrieved?

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.



The question is - when you're logged into SharePoint, how do you 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 of all, 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.

 

Hopefully this is helpful.

      -Antonio

SharePoint Governance: The Impacts of Moving to the Cloud

Thanks to everyone that attended this webcast on March 28th.  We had a great turn out.  Christian Buckley and I were very happy to speak to everyone on this important topic.  Look for more detailed information coming soon to this blog related to things you need to consider when looking at moving business workloads like SharePoint to the cloud.

You can find a link to the presentation deck here.

You can find a link to the on-demand version of the webcast here.

If you had any questions that were not answered during the call, please feel free to reach out to me.

  -Antonio

March 28th Webinar - SharePoint Governance: The Impacts of Moving to the Cloud

Webinar: Thursday, March 28, 2013 11:00 AM - 12:00 PM EDT

Register today for this webcast to learn the pros and cons of moving to the Cloud:  https://www2.gotomeeting.com/register/714036874.

Is your enterprise considering a move to the Cloud? Are you aware of the benefits and risks of moving SharePoint and key workloads to a Cloud environment?  

Join Microsoft SharePoint MVPs Christian Buckley, Director of Evangelism, Axceler and myself for a discussion on functional trade-offs of the platform, potential impacts and risks that need to be considered when moving SharePoint to the Cloud.  This webinar will cover topics such as:

•    SharePoint capabilities in Office365
•    Existing investments that organizations have made in customizing SharePoint
•    Data sovereignty
•    Regulatory compliance

Is SharePoint Online the right decision for you?

Understand the impacts to your business of moving to the cloud in order to determine if your enterprise is ready?

Hoping you can join us.  We're looking forward to the discussion and taking people's questions.
     - Antonio

Help Microsoft Focus on Customers and Partners!

As part of the Microsoft community, we often work with Anthony, Pierre and Mitch, the evangelists from the IT Pro team at Microsoft Canada.  They asked us to share this important message with you.

The team at Microsoft Canada is focused on ensuring that they help set you up for success by providing the information and tools you need in order to be get the most out of Microsoft based solutions, at home and at work.

Twice a year, Microsoft sends out the Global Relationship Study (GRS for short); it’s a survey that Microsoft uses to collect your feedback and help inform their planning.  If you receive emails from Microsoft, subscribe to their newsletters‚ or you’ve attended our any of their events you may receive the survey.

The important details:

• Timing – March 4^th to April 12^th 2013
• Sent From – “Microsoft Feedback”
• Email Alias – “feedback@e–mail.microsoft.com”
• Subject Line – “Help Microsoft Focus on Customers and Partners”

Many of you already read the Microsoft Canada IT Pro team’s blogs‚ connect with them on LinkedIn and have attended their events in the last year or so. So you may already know that you’re their top priority. So they want to hear from you.

Pierre, Anthony and Mitch use the GRS results to shape what they do, how they do it and if it’s resonating with you. Tell them what you need to be the “go-to” guy or ga).  Tell them what you need to grow your career.  They want you to be completely satisfied with Microsoft Canada.

 

This year, Pierre, Anthony and Mitch have delivered 30 IT Camps and counting across the country.  Giving you the opportunity to get hands on and learn how to get the most value for your organization.  They have a few more events planned this year, so keep an eye on their plancast feed for events near you.  Based on your feedback, topics they’re planning to cover will include:

• Windows 8
• Windows Server 2012
• System Center 2012
• Private Cloud
• BYOD – Management and Security

That’s not all.  They’ve heard you loud and clear so in addition to hands on events, they’re also delivering more technical content online via the IT Pro Connection Blog.  Windows 8 continues to be a big area of focus for them.  They covered a lot of great content at launch and they’ve complimented that with new content like:

·          Security Concepts

·          Enterprise Focused Content

·          Windows 8 and System Center 2012 Integration

In addition to this, there are some valuable online resources you can use like Microsoft Virtual Academy, Microsoft’s no-cost online training portal.  Or software evaluations (free trials) on TechNet that allow you to build your own labs to try out what you’ve learned.

Regardless of how you engage with the team at Microsoft Canada‚ you’d probably agree that they hear you. They’d also encourage you to continue to provide that great feedback. They thrive on it‚ they relish it‚ they wallow in it and most importantly of all‚ they action it. So please keep connecting with them and keep it coming! Pierre, Anthony and Mitch are listening. 

Resources, Tools and Training

·         Tim Horton’s Gift Card Contest – We’re giving away 350 Tim Horton’s gift cards, all you have to do to qualify is download a free qualifying software evaluation (trial).  Download all three for more chances to win, but hurry, the contest closes soon.*

·         Windows 8 Resource Guide - Download a printable, one-page guide to the top resources that will help you explore, plan for, deploy, manage, and support Windows 8 as part of your IT infrastructure.

·         Windows Server 2012 Evaluation – Get hands on with Windows Server 2012 and explore the scale and performance possibilities for your server virtualization.

·         Microsoft Support  - Get help with products‚ specific errors‚ virus detection and removal and more.

·         Microsoft Licensing  -Visit the Volume Licensing Portal today to ask questions about volume licensing‚ get a quote‚ activate a product or find the right program for your organization. 

*No purchase necessary. Contest open to residents of Canada, excluding Quebec.  Contest closes April 11, 2013 at 11:59:59 p.m. ET. Three-Hundred-and-Fifty (350) prizes are available to be won: (i) $10 CDN Tim Horton’s gift card.  Skill-testing question required. Odds of winning depend on the number of eligible entries. For full rules, including entry, eligibility requirements and complete prize description, review the full terms and Conditions.