Security Controls - External Sharing of Sites in Office 365

In our SharePoint deployments in the past, we've often had the need to share content with external users, which are people that are not part of our company or organization.  Setting this up in an on premise environment often required a significant deployment of a SharePoint extranet, with some complex network configuration.

Office 365 makes sharing with external users very easy and gives administrators some great controls over it to ensure that its both secure and enables collaboration between internal and external users.

External Users
External users might be partners, customers, auditors, or generally those that cannot login to our corporate network.  From a technical standpoint we often think of them as people that do NOT have an account in our corporate Active Directory.  In Office 365, you can also think of an external user as one which does not have a license to your SharePoint Online sites or Office 365 subscription.

• From a governance and security standpoint, we typically do not want to give external users an AD account or Office 365 license, so this makes sense.

If a SharePoint Online site is shared with an external user, that user inherits the rights of the SharePoint Online customer that's inviting them to access the site.  So, if you have an E3 Enterprise Plan with Office 365, any external users that you share a site with will also have the rights that are granted with an E3 Enterprise license.  That said, there are some capabilities that are NOT available to external users, which are:

• Cannot be a site collection administrator or access any of the site collection administrator capabilities.
• Cannot create their own personal One Drive for Business library.
• Cannot search against everything, cannot search across site collections and cannot access the Search Center.
• Cannot create their own personal sites, or a My Sites site.
• Cannot access or view the company newsfeed.
• Cannot change their user profile (things like their picture or contact information).
• Cannot access site mailboxes
• Cannot access PowerBI capabilities: PowerView, PowerPivot
• Cannot use eDiscovery
• Cannot open downloaded documents which are IRM protected (Information Rights Management).
• Cannot use Excel Services features
• Cannot access SharePoint Online data connection libraries
• Cannot use Visio Services features

There are of course many other capabilities that external users can access, including viewing, editing and collaborating on content.  As described below, you can control the permission levels assigned to external users so that they can only view content, or so they can view and edit content.

We typically talk about 2 types of external users:

• Authenticated User - this user is required to login with a user name and password
• Anonymous User - this user is NOT required to login

Administering and Controlling External Sharing

Global Admin Controls
External sharing can be turned on and off globally, and individually for each site collection.  You turn it on or off globally by logging into your Office 365 tenant as a tenant administrator and doing the following:

• Click the App Launcher and select Admin
• In the menu at the left click the External Sharing option
• Within External Sharing menu, click the Sharing Overview option
• There are several options available on this page, including options for Sites, Calendars, Skype for Business and Integrated Apps.  We're focus on Sites for this article.

• Under sites, you'll see a global ON and OFF switch for External Sharing - ensure that it is ON.

• Click on the Go to detailed settings for sites link or in the left menu click on Sites

• From this page, through the controls at the top, you can control the External Sharing settings for all site collections in the tenant.  The Let external people access your sites check box reflects the same state as the global ON and OFF switch mentioned above.
• Selecting either the No anonymous guest links. Only allow sharing with authenticated users or Allow sharing with anonymous guest links for your sites and documents radio button will select whether only authenticated user access is permitted for external users, or if both authenticated users and anonymous users are permitted.

Security Note: This control allows me to turn ON and OFF anonymous access to all site collections (and leave authenticated access ON) all at once if needed.  In a situation where you detect that sensitive content may have been shared in appropriately through an anonymous link, this control can be extremely useful as it disables all previously shared anonymous access.  If I turn this off in the global Admin Center then it will be disabled (and I cannot turn it back on) in the SharePoint Admin Center:

Note: Each site collection remembers its previous setting, so if you have some site collections with only authenticated access and others with both authenticated and anonymous access, changing this radio button will change all site collections back and forth between their current settings or only allowing authenticated access.  

• From this page you can select individual site collections, click the pencil icon to edit their settings and determine if external user access is permitted and if only authenticated users or if both authenticated and anonymous users are permitted.  Again, this can be done individually for each site collection here.

• In the global Administration Center, you may also control the external users which have access to each site collection by selecting the site collection and clicking the Manage external users for this site link on the right, which will allow you to simply select and delete users:

SharePoint Admin Controls
From within the SharePoint Admin Center you may also manage sharing by selecting a site collection from your list::

...and then clicking the Sharing button in the ribbon:

However, these controls provide the same capabilities as those listed above at the global administration level.  If I modify the settings here in the SharePoint Admin Center for a site collection, the same change is reflected in the global Admin Center.

One advantage of the SharePoint Admin Center's sharing controls is that it allows me to edit the settings for more than 1 site collection at a time - I can select more than one, click the Sharing button in the ribbon and modify the sharing settings for all the selected site collections at one time:

Other than this, I can control external sharing settings for each site collection either at the global level or at the site collection admin level.  There are 2 advantages to controlling these settings at the global level:

• View and delete the external users that sites are currently shared with
• Turn sharing ON and OFF, or anonymous access ON and OFF for all site collections at once

See below for the administrative role needed to control external sharing.


Defaults for New Site Collections and Administrative Roles
The default External User settings for SharePoint Online is to have External Sharing turned ON at the global level.

However, external user sharing is turned OFF for new site collections - it must be explicitly turned ON for each site collection.  This is a good security feature, helping to ensure that you do NOT accidentally share sites externally.

In order to control External Sharing options, you must have either the Office 365 global administrator role or a SharePoint Administrator role.

• You cannot control whether a site is share-able externally simply as the site collection administrator or from within the site settings.  Once you configure a site collection to be share-able in the global Admin Center and/or SharePoint Admin Center, then you select which external users a site is shared with from within the site collection, as discussed below.

Security Note: From the Office 365 Administrative interface it appears that a global administrator role would have the ability to control the global and SharePoint administrative settings for external sharing, whereas the SharePoint administrator role would only be able to control the SharePoint Admin Center settings for external sharing.  However, in testing I have found that this is NOT the case.  It appears that even if a user that has ONLY the SharePoint Administrator role they can control these particular settings in both the global Admin Center and the SharePoint Admin Center.  So, although some settings can be disabled at the global admin level and enforced automatically on all site collections, like turning anonymous access OFF on all site collections at once, a SharePoint administrative role can simply navigate to the global Admin Center and turn them back ON (even though they are not a global administrator).

Even if my user account is the site collection administrator on only 1 site collection, if I have the SharePoint administrator role in the Office 365 tenant settings, I can change external sharing settings for all site collections, both in the global Admin Center and the SharePoint Admin Center.

Sharing a Site with Authenticated Users

If you require that external users login with a username and password when accessing an Office 365 site that's been shared with them, then you must share with an authenticated user.

An authenticated user in this case must be a user with either a Microsoft account or an account assigned to them from Office 365, or what is sometimes referred to in Microsoft articles as a school or work account.

• A Microsoft account is what used to be called a Windows Live ID, and can actually be any account used to access Outlook.com, OneDrive, Windows Phone, or Xbox LIVE.  If you have an account to access any of these services, then you already have a Microsoft account.  For example, my Microsoft account is still my @hotmail.com account.  So, if I want to share a site with an external user that has a Microsoft account named bob@outlook.com then I can simply share the site with that email address.  The user will receive an email invitation and when they click the link within, they'll need to login using their existing bob@outlook.com username and password.  Office 365 will authenticate them against their Microsoft account.

• A school or work account in this context is a user account that has been created for users within the Office 365 tenant.  For example, when creating my Office 365 tenant I can optionally register and verify other domain names that I own.  Once that step is complete, I can create accounts within Office 365 which use that domain name.  So, if I register and validate the domain CONTOSO.COM in my Office 365 tenant, I can then create an account called bob@contoso.com.  In this case, if I need to share a site with an external user that does not already have a Microsoft account (and is not interested in getting one, even though they're free and really easy to register) I can simply create an account for them in my tenant.  I can then send that user an email invitation to access their new account with the username and password that I choose for them.  Finally, I can share a site with that user account and they'll be able to access the site even though they do not have an Office 365 license.  Please see below for some interesting controls (or lack of) about this scenario.

Sharing a Site

You may share a site with external users at the site collection level only.  So, if you share a top level site collection external users will gain access to all subsites, lists and libraries below that as well.  this is accomplished by clicking the Share button in the top right corner of the Office 365 page.

The following window will then appear where you can enter either the email address to their Microsoft account or the user name from the Office 365 tenant which represents the user's account.

Notice on the left side of the window you can also see who the site is currently shared with by clicking none other than Shared with.

If I access this same Share button from a subsite, I can share the site collection with an external user from there as well, but notice the message which appears at the top of the new window letting us know that sharing the subsite will also give the external user access to the site collection.

Once I enter the user name or email address and an email invitation message for the external user, they will receive an email with a link to the site. When they click that link, they will be taken to a page that allows them to choose how they wish to login, where they can choose either an organizational account or their Microsoft account:

Security Note: When you share a site collection with an external authenticated user and you select to give them the ability to view and edit content, that user is made a member the Members group within the site collection.  This means they have Contribute rights on the entire site collection.  It also means that they are now able to share the site collection with other authenticated users.  That can be a useful feature for them, and it can pose security risks.  

• Fortunately, if they try to share a site with another external user, they will be prevented from doing so and the following error will appear:

• If they try to share with other internal authenticated users, they are permitted to do this, but a request is first sent to the site owners group for approval, before those internal users are actually given access.

Its typically recommended that if you're going to share sites in this way that you create a separate site collection within your Office 365 tenant specifically for sharing with external users and you ensure that no sensitive content is placed within that site collection.

Sharing a Document

You may also share individual documents with external users, however I do find the experience for the user is not ideal.  When a user receives a sharing invitation to a document, clicking the link in the sharing email invitation received simply opens the document in the web browser.  The user does not get to navigate through SharePoint site to access the document.  Once again, to do this you must select the document and then click Share as shown in the following;

You can also share a document by clicking the ... on a document and selecting Share from the window that appears.  Once Share in either location is clicked, the following window will then appear:

Notice the extra options available in the dialog: 

• Require sign-in option
• Get a Link option

The Require sign in option does just that, requires a user to sign in when they access a document through a shared link.

See below for more information on the Get a link option.

Sharing a Site with Anonymous Users

Sites can only be shared with authenticated users.  They cannot be shared anonymously with external users.

Only documents can be shared anonymously with external users.  Once anonymous access is enabled for a site collection, as shown above, sharing a document anonymously is accomplished through the process shown above to share a document.

Once in the Share window, click the Get a link option and the following dialog will appear:

Clicking CREATE LINK either within the View Only section or the Edit section will then display links that you can email to users in order to enable them to access this document without having to login:

If you wish to only enable external users to view a document without logging in, then you may only email them the link under View Only.  If you wish to enable external users to view and edit a document without logging in, then email them the link under Edit.  A few other capabilities within this window are:

• In this window, you can also click the Mobile phone icon beside each link, which will give you a QR code that you can send to users enabling them to easily open this document on the mobile phone.
• Finally, you can also disable links to specific documents within this window through the disable link.

Security Note:  Its important to understand that by sharing documents anonymously through links like this, any external user that has the link can access the document.  So, if an external user inadvertently or maliciously forwards an email with such a link to another external user, that user will also be able to view or edit the document without having to login.  As a result, it is important to limit the external users with which documents are shared, and to ensure that these anonymous links to get reviewed on a regular basis and disabled once external users no longer have a need to access documents.  This should be part of your information governance policies.

Overall, sharing sites and information with external users is much simpler in Office 365 than its ever been, and Microsoft has provided some great security controls around this capability to ensure that sharing occurs in a secure and controlled way.

   -Antonio

Office 365 Alternatives to SharePoint Mail Enabled Libraries

I get this question a lot from clients: how can I use mail enabled libraries in Office 365?  As you know, mail enabled libraries are not supported in Office 365.  Microsoft’s reasoning behind it is the following:

Mail-enabled lists create contact objects in AD. Since SharePoint Online is a multi-tenant environment, this functionality would cause a large increase in traffic, which in turn would cause performance issues for all customers.  This functionality is currently disabled due to the performance concerns, as well as security, data requirement, legal compliance and scalability concerns.

Never say never, however due to the nature of mail enabled libraries, as described in this Microsoft message, I suspect that they are not scheduled to be supported in Office 365 for a very long time.  As such, I have been looking at alternatives and the following are 2 alternatives that I would recommend are worth considering.

Site Mailboxes
A site mailbox is a central email account that is accessed from a SharePoint site. A team may choose to use a site mailbox to gather relevant team email conversations or collaborate on composing an important email message. A team may also find it helpful to share important documents securely by using a site mailbox.  Once a site mailbox is set up for a site, a new email account is created that uses the name of the site. For example, if you have a team site that uses the URL http://contoso.sharepoint.com/HRSite. The email address for that site mailbox will be HRSite@contoso.sharepoint.com.  You can of course email or CC that address in order to have emailed stored within the Site Mailbox, as you could with mail enabled libraries. Everyone who has Contribute permissions to your site will be able to open the site mailbox and view those messages. Then, for example, a few months from now when another team member is trying to recall what information went into a particular decision, that team member can open the site mailbox, search through the mail captured in that account, and see the history of the issue.

When storing a team’s documents on a SharePoint site, you can leverage the Site Mailbox app to share those documents with those who have site access.  You can view a site mailbox in Outlook, and when doing so users will see a list of all the documents in that site’s document libraries. Site mailboxes will display the same list of documents to all users, so some users may see documents they do not have access to open.  If you’re using Exchange, your documents can also appear in an Outlook folder, which makes it easy to forward documents to others.

The following are a couple of good articles about site mailboxes:

• http://blogs.technet.com/b/lystavlen/archive/2012/08/18/new-feature-site-mailboxes-in-sharepoint-online.aspx
• https://support.office.com/en-ca/article/prepare-for-using-site-mailboxes-in-office-365-6381daa5-3d98-4629-972d-d19e1dc48c1b

All this said, there have been some issues found with site mailboxes (see here for more info) so Microsoft has introduced an alternative to site mailboxes in the last year called Office 365 Groups which I'll talk about further down.

From a licensing perspective, your Office 365 plan must include SharePoint Online and Exchange Online. Site mailboxes require that users have both SharePoint and Exchange licenses.  The site mailboxe feature is available across all Office 365 licenses.

If emails within a site mailbox must be secured, it’s important to note that Azure Rights Management (RMS) is not included but it can be purchased as a separate add-on in order to enable the supported IRM features within Site Mailboxes. Office 365 Message Encryption depends on Azure RMS.

Office 365 Groups
An Office 365 Group is a relatively new capability of Office 365 introduced over the last year.  It is a shared workspace for email, conversations, files, and calendar events where group members can quickly collaborate.  Microsoft has placed a lot of focus on making collaboration in Groups very quick and easy.

• Users can subscribe to a group to receive group email, conversations and events in your email inbox, either in Outlook or in Outlook Web Access.  Subscribing is not enabled by default.  It can be enabled when creating a group, or on an already existing group when adding a new member.  As well, each member of a group can subscribe or unsubscribe from a group depending on their needs.
• A group contains a shared calendar, allowing group members to manage events and schedules for group members.  This is an Outlook/Exchange calendar; it’s not a SharePoint calendar.  Groups has built in some really good integration between the Group calendar and your personal Outlook calendar, so that you can easily add events that are on the group calendar to your personal calendar.  
• A group includes a shared OneNote notebook.
• A group contains a OneDrive for Business page  which allows users to easily store and access documents in 1 central location that are relevant to group members.
• A group also integrates a Yammer conversation feed for the group members.

A group can be public or private. Public groups are open to everyone. If you just want to see what the group is doing, all the content and conversations of a public group are viewable.  If you wish to collaborate with a public group, you can join it and become a member. A private group is exclusive and open to its members only. The content and conversations are secure and not viewable by everyone. Teams choose a private group when concerned about security and privacy, such as confidential documents. Everyone can see the name of a private group, but information within the group is security-trimmed so it is not accessible from search, links, or in other ways if you are not a member of the group. Joining a private group requires approval from a group administrator.

Through the OneDrive for Business capabilities, you can share a file or folder with people outside your group and even outside your organization, like customers, partners, or clients. One goal of Office 365 Groups is to strike a balance between collaboration and making sure files are not shared inappropriately. Administrators can require that access requests are sent before granting permissions, which helps to control the sharing within an organization, and enable/disable external sharing.

The following videos provide a great introduction and deep dive to Office 365 Groups:

• https://support.office.com/en-US/Article/Video-Introducing-groups-in-Office-365-76cc8193-9554-4f85-8c76-bd151763b6e7. 
• https://channel9.msdn.com/events/Ignite/2015/BRK2114

You can also learn more about Office 365 groups here:

• https://blogs.office.com/2014/04/23/the-garage-series-for-office-365-new-user-experiences-with-groups-attachments-and-office-365-mail/ 

From a licensing perspective, at time of launch Office 365 Groups were rolled out to all customers that have an Exchange Online or Office 365 commercial subscription. Eligible Office 365 plans include the Office 365 Enterprise E1–E4 subscription plans (including the corresponding A2–A4 and G1–G4 plans for Academic and Government customers, respectively), Office 365 Business Essentials and Business Premium plans, Office 365 Small Business, Small Business Premium and Midsize Business plans and Office 365 Kiosk plan.

   -Antonio

After Azure ADConnect - Activating Office 365 Users Through PowerShell

Many enterprises are looking at hybrid scenarios as part of their journey to a cloud based infrastructure, and one of the base scenarios or requirements for a hybrid cloud deployment is the synchronization of corporate identities (user accounts) from an on premise Active Directory (AD) environment to Office 365.  I've written several articles on this topic, and I often talk about 2 critical steps in the process:

• Preparing on premise AD by cleaning up user account properties (before synchronization)
• Activating synchronized user accounts in Azure AD (after synchronization)

Both operations can be performed manually in your on premise AD administration console, and in the Azure AD administration console in Office 365.  However, when you're dealing with a moderate to large number of users its often in practical to use the administration console GUIs for either step.

Activating Office 365 Users Through PowerShell

In this post I'll talk about how you can use PowerShell to activate Office 365 users once they're synchronized to Azure AD.

When synchronizing users with Azure ADConnect, the server hosting ADConnect will automatically have Windows Azure Active Directory Module for Windows PowerShell installed as part of that deployment, which is the PowerShell module you'll be using.  You can run the following PowerShell commands on that server.  Alternatively you can download and install the following 2 components:

• Microsoft Online Services Sign-In Assistant (download here)
• Windows Azure Active Directory Module for Windows PowerShell (download here)

We'll begin by connecting to your Office 365 tenant.

Connecting to Office 365

• Launch Windows Azure Active Directory Module for Windows PowerShell.  Ensure you launch it as an Administrator.
• Connect to your Office 365 tenant by using Connect-MsolService.  This command does not take any parameters.
• A dialog will popup asking you for your service administrator username and password.  Enter them and click OK.  Once successfully connected, your PowerShell window will look like the following:

• To view the list of available PowerShell commands with this module type Get-Command -Module MSOnline.

Get a List of Office 365 Users

• To retrieve a list of Office 365 users you can use the command Get-MsolUser.  This will display a list of all users in your Office 365 tenant, including their User Principal Name, Display Name and whether or not they have a license.  Notice how both licensed and unlicensed users are shown in the following list:

• If you only wish to see a list of unlicensed users then you can call the same command with a parameter for unlicensed users only:  Get-MsolUser -UnlicensedUsersOnly.

• If you are working with a large number of users, consider using the -MaxResults parameter along with the -UnlicensedUsersOnly parameter.  For example, you can call: Get-Msoluser -UnlicensedUsersOnly -MaxResults 1000.  If -MaxResults is not specified, a default value of 500 is used.

Activating Office 365 Users

Before you can activate Office 365 users, we must first set the location of each user.  Microsoft requires this because the services it can offer to users is based on their location.

•  The 2 character country code is used to set a location for each user.  So for Canada you use "CA" and for the United States you  use "US".  Other applicable country codes can be found here: two letter ISO code list.  You can set the location for an Office 365 user by calling: Set-MsolUser -UserPrincipalName "<user's upn>" -UsageLocation "US". 

Here we specify the user by specifying their UPN by using the -UserPrincipalName parameter.

• Once you have set a location for each user, you'll now require the name of your license SKU.  You can find this information by calling Get-MsolAccountSku.  This will return a string that's typically named <domain name>:ENTERPRISEPACK as in the following example:

Notice, the number of active units (available licenses), warning units and consumed units (assigned licenses) are displayed.  The number of licenses available to you will be Active - Warning - Consumed.  So in my case I have 19 licenses available that I can assign.

• To assign a license to a specific user use the following PowerShell command: Set-MsolUserLicense -UserPrincipalName "<user's upn>" -AddLicenses "<your license SKU>".  After running this command and then running Get-MsolUser again we can see that our user Nori.Dwarf@maiolabs.com now has a license, as in the following example:

Combine PowerShell Commands to Activate Users in Bulk

We can combine the PowerShell commands shown in order to assign a location and license to users in bulk, as in the following examples:

• Get-MsolUser -UnlicensedUsersOnly | Set-MsolUser -UsageLocation "US"
• Get-MsolUser -UnlicensedUsersOnly | Set-MsolUserLicense -AddLicenses "<your license sku>"

Azure ADConnect provides a fantastic tool for synchronizing users from on premise Active Directory to Office 365 and keeping them synchronized.  However, activating users is still a critical step in enabling users to access Office 365 services, and when activating users in bulk using PowerShell will save considerable time over using the administration console GUI.

   -Antonio

DFW SharePoint User Group: Hybrid Identity Management in SharePoint and Office 365

Thank you to everyone that came out to the Dallas Fort Worth SharePoint User Group meeting last week on Tuesday August 18th.  We had a great crowd and I hope everyone enjoyed my presentation on Hybrid Identity Management in SharePoint and Office 365.

The presentation deck can be found here on slide share here:

Hybrid Identity Management with SharePoint and Office 365 - Antonio Maio from AntonioMaio2

As mentioned during the presentation, my slide deck does include an Appendix with screenshots of everything I went through.

Demo: User PowersShell to Active Office 365 Users

For those that attended, there was one glitch with my demo when trying to use PowerShell to apply a license to a newly synchronized user in my Office 365 tenant.  The issue with that I was trying to do was that I accidentally typed the PowerShell command Set-MsolUser rather than Set-MsolUserLicense.  This had been correct in the slide deck, and I just mistyped the command.  In any case, the full correct PowerShell command is:

Set-MsolUserLicense -UserPrincipalName " <user’s upn> " -AddLicenses “<your license SKU“

Customizing the User Sign In Page

There was also another correction made in the slide deck: in the table on slide 9 which describes various requirements along with which are supported with Synchronized Identity vs Federated Identity, it previously mentioned that customizing the sign in page was only available with the Federated Identity model.  Earlier this year however Microsoft released the capability to customize the sign in page in Office 365, so this will now work with both Synchronized Identity and Federated Identity models. This capability is only available with the Azure AD Basic or Premium editions, and not the free edition.  So you must pay for Azure AD in order to make this customization.  This fact was pointed out to me by Chris Goosen (Office 365 MVP who attended the meeting) - Thanks Chris!  He's even written a great blog post about how to go about customizing it here:  http://blog.enowsoftware.com/solutions-engine/bid/187358/Add-Custom-Branding-to-Your-Office-365-Sign-in-Page.


Please reach out to me if you have any other questions on this topic.

Enjoy!
   -Antonio

Initializing Azure VMs to Host SQL Server for SharePoint 2013

This is another post designed to help people with some basic steps involved in setting up Azure VMs for a SharePoint farm in a lab or test environment.  As mentioned in a recent post, I often use Azure VMs to test scenarios related to SharePoint 2013. When standing up a brand new SharePoint environment, I might setup a new VM specifically to host my SQL database.  When doing so, I'll often quickly create a VM using a SQL Server template in the Azure VM Gallery.

As part of this process, Azure will ask me to specify a network (which I already have configured in my Azure instance) and an administrative user account.  I cannot seem to specify a domain account here since the new server will not yet be domain joined.  The administrative user account I do specify is created as a local administrator in my new VM and given ownership over the SQL database which is deployed as part of the template.

Once created, my next step is to domain join this new VM to my domain.  You can see basic steps for how to accomplish that in a previous post here:  Domain Joining New Azure VMs.

At this point, you would think that I could just start installing my SharePoint 2013 Server on a separate VM (using service accounts), and as part of that installation process specify the administrative account I created for SQL as the SharePoint Database Access account (allowing my new SharePoint farm to connect to this newly setup SQL Server VM).  But, there are a few settings you need to configure first related to SQL before you can start setting up SharePoint 2013.

After my SQL Server VM was created, and even after I domain joined it, the only account that I specified which currently has ownership of the database was the local administrator account that was created as part of the VM creation process.  I cannot and should not use that account to setup SharePoint and connect to the database.  I can login to the SQL Server VM as a domain account, but it would not have any administrative capabilities over the database, nor could it connect to the database from a separate server (like the one you're installing SharePoint on).  There is no domain account yet that has that type of access to the database.

Configuring a Domain Account as SQL Sys Admin

Typically the first domain account that you provide access to SQL Server would not be used to install SharePoint. When configuring this domain account to access SQL Server, you often give it the sysadmin server role so that it can have ownership over all databases and be used to perform any operation in SQL Server, including configuring other accounts with appropriate permissions in SQL Server with which to install/configure SharePoint.  This is done by doing the following:

• Login to the SQL Server VM as the local administrator account that was specified when you created the VM.  
• Launch SQL Management Studio and connect as that local administrative account.  If you look in the top node of the Object Explorer in this screen shot, you can see that I am logged in as ALMAIOSQL-1\Antonio.Maio which is the local administrator account.

• In the Object Explorer, open the Security node, then right click on the Login node and select New Login...

• In the Login - New window, click the Search... button to specify the domain account that you wish to use as SQL administrative account.
• Specify the domain account, click Check Names, and click OK.

Pretty basic stuff so far!

• In the Login-New window click the Securables page (top right corner of the page), click Search..., select the The server <SQL Server Name> option, and click OK.
• Click the Server Roles page, check the sysadmin option.  Click OK.

This account may now be used to create and grant appropriate permissions to other accounts which will be used to install and configure SharePoint 2013 on another server.  Before you can do this, you'll need to logout of the VM, and login again as the domain account you just configured.

Allowing the Database Access Account to Connect to SQL Server

In order to install SharePoint 2013 and specify a Database Access Account, the following is a process that you'll need to go through to give a domain account access to the database.

• Login to the SQL Server VM as the domain account which you gave sysadmin access to the database. 
• Launch SQL Management Studio and connect as that domain account. 
•  In the Object Explorer, open the Security node, then right click on the Login node and select New Login...






• In the Login - New window, click the Search... button to specify the domain account that you wish to use as SharePoint's Database Access Account.
• Specify the domain account, click Check Names, and click OK.



• In the Permissions for <SQL Server Name> list check Grant option beside the Connect SQL permission and click OK.

This account may now be specified when running the SharePoint 2013 install process as the Database Access Account.

There are other service accounts that are also required when installing a SharePoint 2013 farm (setup account, farm account) which have their own requirements for permissions, privileges and being part of local administrator groups.  Its important to understand these requirements when creating a new SharePoint farm and there are some great resources available from Microsoft on the specific requirements of each account:  Account Permissions and Security Settings in SharePoint 2013.

Enjoy.

   -Antonio

Back to Networking Basics: Domain Joining New Azure VMs

I often use Microsoft Azure VMs to test various scenarios related to SharePoint 2013.  I work with a lot of on premise SharePoint clients and having an environment to quickly try something out is really helpful.  Azure let's me of course quickly spin up VMs using one of the templates from the gallery and get up and running quickly.  I have my own environment with several servers already setup in Azure, all within my own domain, and I often add a new server when I need to test something really new or experimental (not wanting to mess with my existing servers). 

When I create a new VM, Azure asks for me an administrative user account and password as part of that process, and makes that user a new local admin on the new server.

Once created, the first thing I typically want to do with that VM is domain join it to my domain.  Due to how Azure creates that VM with that local administrator account, there is a couple of extra steps that I need to manually perform (and sometimes forget) when domain joining that server.

These are just some networking basics, but I wanted to share those steps here so that you can quickly get through this process should you run into it.

When I connect to my new VM, and want to domain join it I typically use the following steps:

• Open Windows Explorer
• Right Click on This PC
• Select Properties
• Within the System page which appears, under the "Computer name, domain and workgroup settings" section, click Change Settings

• Click the Change Button
• Select the Domain radio button, enter my domain name and click OK

However, at this point, if you are in a new shiny Azure VM you'll often run into this error:

This error means that Windows Server does not know where to find your domain controller in order to contact AD and join the domain.  This happens even if you've created a 'network' within Azure and you selected that network when creating your new VM.  So let's look at how you tell it where your domain resides.

• Right click on your Network icon in the task bar
• Select Open Network and Sharing Center

• Click on Change adapter settings
• Find the Local Area Connection, right click on it and select Properties

• Within the Ethernet Properties dialog, select and select the Internet Protocol Version 4 (TCP/IPv4) option
• Click the Properties button
• In the Properties window, select the Use the following DNS server addresses radio button, and enter the IP address of your AD Domain Controller VM as the Preferred DNS Server, and the IP address of your Default Gateway as the Alternate DNS Server as shown in the following.  You can find both of these IP addresses by connecting to your AD Domain Controller VM and running ipconfig at the command prompt.

• Once entered, you can click the Advanced button shown, navigate to the DNS tab and you'll see these 2 IP addresses already added.

• Click OK, OK and OK to exit out of these dialogs.

Your VM will now know where to look to find your domain controller when adding this server to your domain.  Return to Windows Explorer, right click on This PC, click Properties, click Change Settings and try to add your new VM to your domain now.

Enjoy your new Azure VM!
   -Antonio

Step by Step: Changing the SharePoint 2013 Farm Account Password

When setting up a new SharePoint 2013 farm, as a best practice we typically create service accounts for very specific purposes. The idea here is that we deploy SharePoint 2013 using a least privileged model, where very specific service accounts are created for very specific purposes and those accounts are only granted the permissions required to fulfill that purpose. That way, if such a service account is compromised by a malicious user, that user does not gain access to the entire farm. One such account is the SharePoint 2013 farm account.

 

When creating these service accounts, for various reasons, we typically create a domain account in Active Directory and configure it such that the passwords do not expire. As well, we find that the passwords for these service accounts typically are not changed often. However, there are circumstances in which the password for the SharePoint 2013 farm account must be changed.

• One example of such a circumstance is if we suspect that the farm account has been compromised by a malicious user.
• Another example is when consultants, such as myself, are brought in to deploy new SharePoint 2013 environments. Once that deployment process is complete and the client is happy with the environment, rightfully so, the client typically wants to take complete control of the environment and restrict farm admin level access to only a small set of internal employees - essentially they want to prevent the consultants that deployed the environment from continuing to have farm administrative level access.

 

Changing the SharePoint 2013 farm account is a manual process.  Its not something that is done often, so people often aren't sure which steps are required to ensure that it has been changed in all required locations.  Always be sure to test this process in a TEST SharePoint 2013 environment and monitor that environment for a period of time before performing this process in a PRODUCTION environment.  Your SharePoint 2013 farm may be configured differently that other standard configurations and your process may require extra steps.


For a standard SharePoint 2013 farm, the following are the steps required for modifying the SharePoint 2013 farm account:

 

1. Navigate to SharePoint 2013 Central Administration interface, click Security in the left hand menu, and click ‘Configure Managed Accounts’.  Select the farm administrators account in the account list shown, click the Edit icon and change the password.

 

2. Manually change the User Profile Service password.  As required by SharePoint, this service uses the farm administrator account, however SharePoint 2013 does not treat this account as a managed account so it must be changed manually. 

• The farm administrator account must be made a local administrator on the server hosting the user profile service during the password change. 
• Once that step is complete, launch SharePoint Central Admin, navigate to System Settings and click ‘Manage Services on Server’.  This page is used to start and stop services on each machine in the farm.  Select the machine hosting the user profile service and find that service.  It should say started. 
• Stop the service.
• Start the service again – when starting the script you’ll be asked for the new password
• Ensure that you monitor the user profile service and ensure that the service starts correctly.
• Once started, you may remove the farm administrator account as a local administrator.  However, we often recommend leaving it as a local admin on the server for simplicity of making such changes in the future.

 

3. Check if any applications in the Secure Store service use the farm administrator account, and if they do change the password there.

• Launch SharePoint Central Admin, click Application Management in the left hand menu, click Manage Service Applications, click the Secure Store Application and click Manage Target Applications.
• Select a single Target Application from the list.
• In the Credentials group on the ribbon, click Set. This opens the Set Credentials for Secure Store Target Application dialog box.  If any target application uses the farm administrators account, change the password here. 
• Repeat this process for all secure store applications.
• Note: Be cautious when entering the password. If a password is entered incorrectly, no message will be displayed about the error. Instead, you'll be able to continue with configuration. However, errors can occur later, when you attempt to access data through the BCS.  If the password for the external data source is updated, you have to return to this page to manually update the password credentials.

 

4. Reboot all the servers in the SharePoint farm, except for SQL server.  SQL Server does not need to be restarted.

Please let me know if you have any questions or comments about this process.  There may be other services that have been configured with the farm administration account, so your process may vary somewhat, but typically the farm administrator account is reserved for specific purposes.  As a best practice, due to its high level of access, the farm administrator account should not be used widely other than for the purposes in which it was designed.

   -Antonio

Notes from Microsoft Ignite Driving User Adoption from a Technical Standpoint

Microsoft Ignite is proving to be an exciting conference with new technologies and announcements about how Microsoft is evolving their technology stack to help us collaborate in new and better ways. I'm at the conference attending sessions on security, data protection, migration and other topics and want to share my notes so that they may be a resource to others as well.

Presented: Friday May 8, 2015
Presenters:
- Laura Rogers, Rackspace
- Lori Gowin, Premiere Field Engineer, Microsoft

User Adoption Issues

- Working on files straight from sharepoint - Office Integration - lack of awareness - its hard to use files that are in SharePoint

• Save straight to SharePoint
• Open straight from SharePoint
• User answer: manually add locations
• Admin answer: promote locations that ae pertinent to users
• Admin: audiences, AD, group policy (hundreds of settings)

- Authentication

• I keep getting prompted to authenticate
• Why doesn't it know my domain
• User answer: know what IE settings to configure
• Admin answer: push IE settings via group policy, integrated windows authentication, default domain

- The App Store

• Why can't we have the App Store?
  
• What App do I need?
  
• Help users to understand what is there, not get overwhelmed
  

- Organizing the clutter

• How can we easily archive or move files somewhere else, or
• We need to just drop files in SharePoint and not have to think about where exactly, or
• How can we manage the lifecycle of data, or
• There is too much stuff to sort through

- Finding Files

• I can't find that attachment?
• Where is that document?

- Mobility

• Why is it so hard to configure my phone to work with this?
• I want to work with this when I am offline
• I only want to carry 1 device, for both personal and work
• I want to get stuff done when travelling
• It changes all the time
• New services added - Delve, Video Portals
• Look and feel - new tool bards, app launcher, changing master pages by version

Admin Fundamentals - Tools for Admins

Active Directory

• Synchronize with SharePoint
• Single version of the truth
  
• Keeping it updated helps tremendously
  
• Create audiences
• Global - can be used anywhere in your farm
  
• Defined dynamic groups of people based on attributes
  
• Target content and web parts to audiences
  
• Use for Directory
• Just use SharePoint search to search for people by name
  
• Display in web parts
  
• Have the manager property configured correctly so that you can use the organizational chart
  

- Group policy

• Use or computer policies
• Push registry changes - 100s of settings available
• IE Settings
• MS Office settings
• Hundreds of office program settings
• Even common SharePoint locations
• Ensure features and applications available for users
• Link in the presentation to download the Office 2013 group policy templates - these are only for professional; different versions of Office have different registry settings/group policies
• Important to ensure group policy is set consistently across all users - Every user needs the same version of the truth!

- SharePoint Central Admin and Office 365 Admin Center

• Create promoted sites/links
• Customize the search experience
• Manage your app store
• Manage your service applications
• Manage DLP

Solutions - What can you the Admin DO?

- Push links to commonly used libraries and sites - Group Policy - Search customization - Create send to locations - Extras install/configure - Push links to commonly used libraries and sites

• Add published links to office application
• Ease of saving/opening files
• Target to an audience
• Add personal site URL in Active Directory
• Attributes is called WWWhomepage by default…
• Create promoted sites
• Different types of sites and links to choose from
• Associate an image
• Target to an audience
• Create Custom Template Locations
• Use them for Office programs
• Templates targeted to me
• Use document library with template synchronizations - a document library with content types in it
• Each set of templates can have a target audience
• Do you set the document library using Group Policy?

- Group Policy

• Office applications - Share
• Create a library with its own workflows
• In SP 2013 libraries do not have basic workflows enabled or selected by default
• All office users can run these common workflows
• There file gets moved to that library
• They are notified and can start the workflow
• Name your SharePoint
• Save straight to your published links

DEMO: Promoted Links

- End user: login to Office 365, Sites, click on Mange the promoted sites below

• The manage link shows up only for admins
• When managing from here you don't get a link to set the target audience
• The tiles which show up at top are the promoted sites

- Administrator: In Office 365: login as administrator, go to Admin, then User Profiles, Promoted Sites

• Fill out settings: URL, title, description, image URL, owner, target audience
• Visibility controlled through audiences
• On premise, you have control over when audiences get compiled
• In SharePoint Online, you do not have control over when audiences are compiled - they are only compiled once a week

- Templates are also configured through a link to a page in User Profiles configuration page

• This controls the templates available within the office applications, as well as sites with open and save as
• Can also target by audience
• Doing this, can associate a template with a content type

More Solutions

• QUESTION: if you start a document from a template with a content type, and then save the document to a different library which does not have that content type, is the metadata lost?
• ANSWER: metadata will not be lost- it will still be saved witihn the document but not available within the library

- Send To Locations

• Create archive locations or file drop locations
• Use across site collections
• Defile action - Copy, move, move and leave link
• Allow or disallow manual submission by users
• Create content organizer rules
• Defined at each drop site
• QUESTION: will Send To locations work for OneDrive for Business
• Could not configure these differently for different end users

- Data Archiving and Clean up

• Create compliance policies
• Retention policies
• Deletion policies - can configure for an entire site collection; can you use it more specifically?
• Clutter
• Turn on or off using OWA
• Train Clutter
• Relies on the Office Graph
• Available for Exchange on prem (only Exchange 2013)
• End users can turn this on or off - can only turn on from OWA

- Push Internet Explorer Settings

• Add sites to IE local intranet policy or trusted sites
• Single sign on
• Custom Level
• Automatic logon with current username and password
• Group Policy
• Set per IE version
• Add trusted sites, home page default, security settings
• Windows Components\Internet Explorer\Internet Control Panel\Security Page\Site to Zone Assignment List
• When you push out sites through GPO there is a max length, so use wild cards where possible
• Will set in IE settings: Preferences\Internet Settings
• Configure OWA Authentication
  
  • Integrated Windows Authentication for internal/domain users
  • Configure a default domain for FBA Users

- Manage the App Store

• Apps provide solutions beyond the out of the box
• Deploy strategically
• Too many, confuses users
• Deploy by path, URL, Template
• Monitor and control them - especially if end users go out to the store themselves

DEMO: Manage the App Store

- Office 365 Admin > SharePoint Admin page > Apps

• Can configure access to the store
• Recommended minimum: allow end users to only request a purchase; don't allow end users to purchase themselves - that way Admins have a control over which apps are deployed, why, can help avoid duplicate apps - there are a lot of duplicates out there
• Can deploy to specific site collection or multiples - can deploy by managed paths

More Solutions

Configure Search

• Query rules
• Search analytics
• Number of queries
• Top queries
• Abandoned queries
• No result queries
• Query rule usage
• People Directory
• Popular request
• Keep ad accurate
• Setup sync from other HR systems

- New and Changing Services

• Delve
• Office graph settings
• User Option
• Video Portal
• Educate, prepare
• Look and feel
• Watch for announced changes
• Limit customization that could break

Resources

• Office 365 Roadmap
• Office blogs
• Yammer Office 365 Network

You can watch the entire presentation here: http://channel9.msdn.com/Events/Ignite/2015/BRK2129
Enjoy.
-Antonio

Notes from Microsoft Ignite Microsoft OneDrive for Business: Most Secure for your Data in the Cloud

Microsoft Ignite is proving to be an exciting conference with new technologies and announcements about how Microsoft is evolving their technology stack to help us collaborate in new and better ways. I'm at the conference attending sessions on security, data protection, migration and other topics and want to share my notes so that they may be a resource to others as well.

Presented: Thursday May 7, 2015
Presenters: Liam Cleary, Protiviti; Denis Minium, Microsoft


- Who poses the threat?

• Initially typically worry about the hackers, external people - people trying to steal our content
  
• Moving to the cloud our infrastructure is under control of someone else - you need to
  
• There s is a gap between your content in the cloud and the edge - this is a good thing that helps protect your content against hackers
  
• But what about the Microsoft operator
  

- Do you trust the Microsoft operator that works in the data center and could be looking at your email, pictures, etc.

Microsoft Cloud Security

• Physical - perimeter security, background checks, biometric auth
• Network - network ACLs, encryption in transit, auditing and monitoring (most important strategy)
• Access - 2-factor auth, just in time access, manager approval
• Application - SDL process, claims based auth, fine grained permissions
• Finely control who gets in and what they can access, including the Microsoft operator
• Data - bit locker, per file encryption, rights management
• Microsoft employee access
• Personnel - background checks, screening
• Account Management - automatic account deletion, unique accounts, zero access privileges
• Training, Policies and Awareness
• Just in time access - zero access privilege & role based access
• Reason - Requests require valid reasons
• Eligible - Access eligibility checklist
• Employment verified?
• Background check?
• Finger printed?
• Security training?
• Manager approval?
• Role - Role Check - identified as someone that has access to these resources
• Activity Logged
  
• Customer Approved - see Customer Lockbox Announcement

Assumed Breach Methodology

• Know thy adversary - annual data breach + threat reports; thorough knowledge of assets and business model
• Ask: is your content valuable to you?
• Continuous Validation
• Penetration testing by Office 365 red team
• Red team activity validates intrusion detection investments

"What is my adversary likely to do, and what evidence will that leave behind?"

• External intruders will attempt to break in...so our full time red team looks to exploit vulnerabilities before they can
• Also use all insider knowledge to test inner defenses
• Microsoft RED TEAM - Half team on inside and half on outside

Each file is uniquely encrypted

• Each file has separate key
• Larger files are split into chunks - each chunk gets its own key
• When files change, the deltas get their own key
• Monitored highly secure key store
• Encrypted chunks are randomly dispersed across different azure storage accounts
• Keys are then encrypted themselves and stored in content DB
• Content DB only contains a map of dispersed chunks and encrypted keys
• Keys in the key store are rotated - not permanent keys
• Most secure store is the key store - even if you get to the key store all you have is a key
• Bit locker used on all disks in the system

- We don't trust the end users
- We don't trust the administrators

- IRM in SharePoint Online

• Admin - simple to provision and configure using Microsoft Azure Rights Management - no on premises RMS server required
• Protection managed at individual library level protecting Office and Adobe PDF file formats
• End users
• Documents are protected at the time fo download from a library and rights given to appropriate user accounts per the library settings
• User can edit the document in supported office clients and protection is removed at time of upload

- Data Loss Protection Policies

• Can selectively choose how DLP poliices are applied - select between SharePoint Online or OneDrive for Business or both
• Customize and create rules - ex. rule called 'sensitive data' and in the rule can specify what is sensitive data
• Actions when policy triggered - Send notifications, display policy tip, override options, report and send email incidents
• Can customize message displayed to the user
• Use reports and auditing

- Retention policies

• New document deletion policies
• Can have multiple deletion policies based on type of content
• Site owners choose policy
• Enforce mandatory policies - helps to minimize the risk; avoids the question of should I do this or not
• Extends to OneDrive for Business
• Conditional Access - Can prevent sync'ing to non-domain devices
• Powershell:
• Get-SPOTenantSyncClientRestriction
• Set-SPOTenantSyncClientRestriction -domainGUIDS "GUID" -enable
• Match occurs by GUID - if machine GUID matches then sync allowed
• If try, get error back when trying to sync a folder that simply says 'Could not sync library'
• Can enforce policies on all site collections

- Mobile Device Management - Built into O365

• User centric approach
• Conditional access - this feature can prevent non-domain joined machines from sync'ing data
• Device management
• Selective wipe and reporting
• Application management
• Powered by Microsoft Intune

Announcements

• Customer Lockbox - client is in control of whether Microsoft has access to data or not
• On roadmap for Q1 2016
• Customer Held Keys - customer provides the key which is used to encrypt Microsoft's keys
• If customer leaves, then Microsoft has no access to any remaining data
• On roadmap for later in 2016
• More detialed audit logs - audit read activity, more in depth operator activity
• Customer Preview in Q3 2015
• Conditional access for Browser - prevent browser access unless accessing from a managed and compliant machine
• No timeline yet

You can watch the entire presentation here: https://channel9.msdn.com/Events/Ignite/2015/BRK3182

Enjoy.
-Antonio