Follow me on Twitter @AntonioMaio2

Thursday, December 5, 2013

Securing SharePoint 2013: Protect Against Malware and Compliance Issues

A Look at Trend Micro™ PortalProtect™ for SharePoint

This article is the fifth in a series where I introduce concepts and considerations for securing Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those with SharePoint up and running who are looking at built-in features and third-party solutions to secure their sensitive information. 

In this post, I look at a third party product that helps protect against malware and non-compliant content in SharePoint.  Specifically we’ll look at Trend Micro™ PortalProtect™ for SharePoint.

SharePoint Content Sources and the Risks They Pose
Microsoft SharePoint has greatly increased our ability to collaborate and share content, both within our organization and outside of the business.  As a result, we see content from many sources being stored in SharePoint and shared with wider and more diverse audiences, for example:

·        Content coming from within our organization, from internal information workers who are creating content
·        Content coming from the web, when internal employees download content and store it for future reference
·        Content coming from partners, when SharePoint is used as an extranet to facilitate inter-organization collaboration
·        Content coming from end customers, such as comments, blog feedback or news feed items when SharePoint is used as a public web site

SharePoint makes it extremely easy for individuals to create and collect information, which in turn drives people to spend more time searching, organizing and managing information.  As well, it makes it very easy to create new web portals (public facing web sites, extranets, team sites, etc.) in which people can easily share that information with a wide audience.  These great benefits also mean that we lose some control over where content is coming from.  As a result, this creates risks for the organization that must be managed, especially when the organization stores sensitive information in SharePoint.

In particular, when content comes from varied sources there are risks that this content can contain information that does not comply with regulations that are important to the business.  As well, there are risks that incoming content can contain malware – viruses, trojans or worms that can either steal sensitive information like credentials or intellectual property, or that can corrupt information.

Microsoft SharePoint 2013 out of the box does not provide features that are designed to protect against such risks.  As well, Microsoft has stopped shipping “Forefront for SharePoint” which had provided some measure of protection in past versions.  As a result, we must look to third party solutions to ensure that sensitive information in SharePoint both complies with regulatory standards and is free of malware.  Earlier this year I had the opportunity to participate in the beta testing program for such a solution - Trend Micro™ PortalProtect™ for SharePoint.  I spent some time testing the product and will provide some insight into its features and benefits in this article.

Trend Micro PortalProtect for SharePoint – Benefits
PortalProtect version 2.1 provides some great new benefits over previous versions including support for SharePoint 2013 (both standard and enterprise server, as well as Foundation) and 5 new data loss prevention policy templates for compliance with industry standard regulations. Other benefits include:
·       According to the Trend Micro web site PortalProtect delivers 206% better performance over Microsoft Forefront. These are some impressive numbers and there is a commissioned independent report which details the test results – it can be found here: Everyone should of course verify these results in your own SharePoint environment.
·        PortalProtect keeps malicious URLs out of SharePoint
·        PortalProtect content filtering protects web pages (blogs, wikis, discussions) as well as list items and documents
·        PortalProtect integrates security policies with Active Directory (AD), SharePoint Users/Groups, and SharePoint sites

Deploying Portal Protect
Deploying PortalProtect to my SharePoint farm was extremely easy.  It includes an easy to use setup wizard and installs as a full-trust farm solution.  As such you do need farm administrator access to install the solution.  In total, the installation took about 15 minutes and didn’t run into any issues in a simple farm configuration (1 WFE and a separate SQL Server database VM).

You will be asked for a license key during the install.  If you do not have a valid key at the time of deployment it will install in trial mode and allow a trial to be run for 1 month. 

How It Works
Its main function is to scan and block content and, it can be configured to take various actions when a file is blocked or if a virus is detected. As well, PortalProtect can send notifications of these events to administrators or other recipients when they occur.  PortalProtect protects content within SharePoint in a number of ways including:
·        Scanning files or web content to determine whether content violates pre-configured policies. When a policy violation is detected PortalProtect will apply an action to either quarantine or delete content depending on how the policy is configured.
·        PortalProtect can scan files for malware and viruses, according to pre-configured policies.  If a file is found to be infected with malware Portal Protect will apply an action to either clean, delete, quarantine or ignore content depending on how the policy is configured.
·        PortalProtect can scan URLs in Web content to detect malicious URLs, and if found it will take actions such as blocking access to a URL.
·        PortalProtect can block files based on their file extension, file name, or actual file type. When it detects a file type that violates a policy it will take an action such as quarantine or delete.

Note: SharePoint 2010 and 2013 does have a built in feature to block files based on file extension which can be configured in SharePoint Central Admin under Manage Web Applications.  Although useful in that it stops specific file types from being uploaded or downloaded from SharePoint, it is limited to checking file extensions only.

Scanning SharePoint Content for Regulatory Compliance
When it comes to ensuring that SharePoint content complies with industry regulations, this product is quite impressive!  It will scan documents, list items and web content on site pages for policy compliance.  It will scan existing content in SharePoint as well as when new content is added to or retrieved from SharePoint.  It allows administrators to create new policies, and it includes several important pre-configured policy templates for SharePoint administrators to choose from.  As well, it allows policies to be configured with a robust set of conditions, exceptions, policy actions and notification options.

Adding a new policy allows administrators to select the keywords or patterns (regular expressions) that a policy will scan for. These patterns can include social security numbers, credit card numbers, identity card numbers, phone numbers, etc.  You can configure the number of occurrences of a pattern in order to trigger a policy violation.  PortalProtect provides a synonym checking feature that enables you to extend the reach of your policies.  As well, administrators can configure policy exceptions.  Policy exceptions work with real-time policy scanning only and they allow specific Active Directory users/groups or SharePoint users/groups to be excluded from policy enforcement.

Note: Portal Protect only provides real-time policy exceptions for SharePoint 2013 Server, SharePoint 2010 Server and Foundation 2013 and 2010.  As well, exceptions do not support AD users and groups across a forest nor do they support global AD groups.

PortalProtect 2.1 includes 5 new pre-configured policy templates for the following compliance regulations:
·        GLBA (Gram-Leach-Bliley financial services modernization act of 1999)
·        HIPAA (Health Insurance Portability and Accountability Act)
·        PCI-DSS (The Payment Card Industry Data and Security Standard)
·        SB-1386 (California law regulating the privacy of personal information)
·        US PII (Personally identifiable information)

These policy templates provide an easy way for organizations to validate content for compliance with regulations that may be critical to their business.  That said, I would caution any business against relying 100% on any automated template-driven solution to ensure compliance.  Automated solutions can produce false-positive results, and regulations do evolve over time.  Compliance with such regulations often involves careful planning, legal counsel and multiple levels of protection.

Unfortunately administrators cannot add additional keywords or patterns to these pre-configured templates. Allowing SharePoint administrators to make these types of modifications to policy templates would be a great enhance in a future version of PortalProtect, especially since the nature of sensitive information is unique to each business.

Scanning SharePoint Content for Malware
This latest release of PortalProtect includes the most recent version of Trend Micro’s robust scanning engine.  At the root of any antivirus program sits 2 components: a scanning engine and a database of virus signatures. Together, these two components work to identify and clean infected files. Whenever PortalProtect detects a file type that it has been configured to scan it copies the file to a temporary location and opens the copy for virus scanning. If the file is clean, PortalProtect deletes the copy and releases the original for access through typical SharePoint methods. However, if a virus is detected PortalProtect applies a pre-configured action: clean, delete, quarantine, or ignore. Deleted and quarantined files are not delivered to the intended recipient. Files set to be cleaned are opened, and any viruses are removed. Not all viruses however can be cleaned. For example, some viruses corrupt the host file, making it unusable - trojans, worms, and mass mailers do not infect a host file and therefore cannot be cleaned. Whatever the configured action, all detections are written to a virus log and administrators can receive automatic notifications of such incidents.

PortalProtect includes a great feature called IntelliScan™ which helps it to minimize usage of system resources and scan files more efficiently.  This feature examines files to assess their true file type (relying not only on file extension) and ensures that it is only scanning files types that are actually susceptible to viruses.

PortalProtect will scan an extensive number of compressed file formats.  However it will not scan files that are encrypted or password protected.  For these file types administrators can specify which action should be taken: block, quarantine, pass, delete, or rename.

The Trend Micro scanning engine can be configured to perform the following types of scans:
·        Real-time Scan – This feature will scan files when they are checked in, checked out, saved or opened/downloaded. All incoming or outgoing files are scanned for viruses or other malicious code.
·        Manual Scan (Scan Now) – This feature provides an immediate way to scan existing content in SharePoint.  It can be used to scan all or a portion of the content within a site immediately, depending on the configuration.
·        Scheduled Scan – Scans can also be scheduled to occur at pre-configured times or frequencies.  A scheduled scan can be used to automate routine security tasks, to improve antivirus management efficiency, and to give you more control over your antivirus policy.
PortalProtect can process multiple requests simultaneously and requests can be prioritized.  However, it is recommended that manual scans and scheduled scans are not performed during peak SharePoint usage periods. 

It is also recommended that organizations use a combination of these scanning types to better ensure the security and compliance of content within Microsoft SharePoint environments. A manual scan can help protect existing content already stored in SharePoint.  Real-time scanning protects against new threats as new content comes into SharePoint.  Finally, scheduled scans can ensure that security and compliance are automated, helping to continually maintain a strong security posture.

Putting It All Together
Overall, this product does exactly what it says it does and it does it well – it helps to protect information in SharePoint by scanning content for compliance issues and it protects SharePoint content from malware.   

The deployment of the product is very easy.  As well, configuration and management of policies was straightforward through the Web Management Console provided.  PortalProtect now supports Microsoft SharePoint 2013 and provides new compliance templates for important regulatory standards, which are both great advancements. For many organizations Microsoft SharePoint represents the central repository for storing critical business information, and having a solution which protects those assets from compliance violations and malware is critical to protecting the business.  Trend Micro has provided a robust security solution with PortalProtect which is very much worth considering.


Disclaimer:  In the spirit of full disclosure its important to note that the author of this post was not paid for this article, nor was the article solicited by the third party solution provider.  This is an independent product review based solely on my testing experience with the product deployed to my personal SharePoint lab environments.  All SharePoint environments are configured and deployed differently and your experiences in using this product may vary.

Wednesday, November 27, 2013

Securing SharePoint 2013: Understanding Authorization and Permissions - Part 2

This post is the fourth in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

Understanding Security Scopes and their Limits
Understanding SharePoint permissions and using them effectively means you need to understand the concept of "security scopes" and their limits.  When unique permissions are assigned to a container or item, SharePoint creates what is called a security scope. This is an important concept to understand because there are limits to how many security scopes can be created, and there are limits to the size of the security scope before SharePoint performance starts to be adversely affected.
Each site collection initially contains one (1) security scope, related to the initial permissions at the site collection level. Each time permission inheritance is broken a new security scope is created. So, in Figure 1 above, the “Demo” site collection has four security scopes: one at the site collection level, another at the site level, another on a library, and a fourth on a document. All other sites, libraries, documents and items in the diagram inherit their permissions and therefore no security scope is created for those levels. The size of the security scope refers to the number of principals in the security scope. Remember, a principle is a user, group or claim. To view another example, refer to Figure 2 below to see how security scopes are created as permission inheritance is broken.

In previous versions of SharePoint, there were various limits documented around how many security scopes a library or list should contain before performance would be adversely affected. These numbers tended to vary depending on the article and there was a lot misunderstanding around them. In SharePoint 2013, each list or library can contain up to 50,000 security scopes before performance begins to be impacted (this change actually came about in SharePoint 2010, Service Pack 1 and the latest cumulative updates, but it has only been documented in SharePoint 2013). This is a significant improvement over previous versions and when you think about it, it’s a very large number to work with. This means that a single library can have up to 50,000 documents or items which each have their own unique permissions. In addition to this, a library can also contain other documents which inherit permissions from the library level (or site or site collection).
In order to actually create unique permissions on up to 50,000 documents or items in a library/list, a SharePoint farm administrator must adjust a setting called the “List View Threshold”. Modification of this setting requires these steps:

1.      Log into the SharePoint Central Administration console

2.      Click “Application Management” on the left hand side, then click “Manage Web Applications”

3.      Select the web application you wish to modify

4.      In the ribbon click “General Settings” to activate the menu

5.      In the menu select “Resource Throttling”

6.      Find the “List View Threshold” setting and modify it to the appropriate value (the default is 5000)

If you do plan to modify this setting to support more unique permissions, ensure that your environment is sized appropriately to handle the additional query load. As well, ensure that you test your environment under realistic conditions with this setting in place to ensure that users will not be affected by potential performance issues.
These limits of course depend on the architecture of your SharePoint 2013 farm and the hardware/configuration used. For more information on SharePoint 2013 boundaries and limits please refer to the following Microsoft article:

Limited Access Permissions
When permission inheritance is broken and unique permissions assigned to a particular item, let’s say a document, SharePoint will automatically create what is called a ‘Limited Access” permission on its parent and all the way up the hierarchy up to the root site collection. The Limited Access permission will contain the same principles (users, groups and claims) as the unique permission assigned, however using the pre-defined Limited Access permission level. The purpose of this Limited Access permission is to give the user just enough permissions to navigate to the item on which they were just granted permissions (even if they did not have access to the folder, library or site previously). This occurs automatically, as part of the process of assigning unique permissions.
The challenge with Limited Access permissions is that they never get removed or cleaned up in any automated way. Even if you cause a particular document or item to re-inherit permissions from its parent library, the limited access permissions will remain in place. Therefore, it is important to monitor how many Limited Access permissions are created because this does contribute to the limits discussed in the previous section.
The following diagram illustrates how security scopes and Limited Access permissions are created:
SharePoint security scopes are created when permission inheritance is broken
Figure 2. SharePoint security scopes are created when permission inheritance is broken.

There has been quite a bit of literature written in recent years about security scopes and their limits, not all of it accurate.  I highly recommend that you review the latest document from Microsoft (link above) on the limits in SharePoint 2013 because that will be the most up to date documentation.

Friday, November 22, 2013

Securing SharePoint 2013: Understanding Authorization and Permissions - Part 1

This post is the third in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

Authorization is an important concept to consider when securing sensitive information in Microsoft SharePoint. Looking at this concept broadly, it’s helpful to understand the differences between authentication and authorization. As mentioned, authentication is the process of determining if a user is who they say they are. Authorization is the process of determining what resources a user can access and what actions can they perform with those resources. Just because a user has access to a system doesn’t necessarily mean they should have complete access to everything within that system.

Within Microsoft SharePoint, authorization is enforced through permissions. With SharePoint 2013 there are some important new changes that are important to understand.

Understanding Permissions
The underlying permissions system within SharePoint 2013 is, in most respects, the same system it has always been. Permissions can be used to secure access to any item or document within SharePoint, as well as any container (folder, list, library, site, site collection).

A permission has 3 components:

§  An information object to which it is assigned (item, document, or container)
§  A principal (user, SharePoint group, AD group, or a claim)
§  A permission level (read, full control, contribute, design or a custom permission level)

Permissions are assigned to items, documents or containers by selecting a user or group and then selecting a permission level. For example, items or containers could have the following permissions assigned to them:

§  User John Smith has Read access to a document

§  AD Group Finance has Full Control access to a library

§  SharePoint Group Project_Team has Contribute access to a Folder

§  User Engineering_Contractor has Contribute access to a site

As an advanced feature, SharePoint 2010 and 2013 allow a permission to contain a “claim” instead of a user or group. As described earlier, a claim is a trusted user attribute that is retrieved when that user logs in. Attributes could include data like the user’s email address, their group memberships, their security clearance, etc.

A permission containing a claim would look like the following:

§  Users with the claim Security_Clearance=Secret have Read access to a document

In this example, when a user logs into SharePoint, if an attribute is retrieved about that user which contains the value Security_Clearance=Secret then the user will be granted Read access to the document. SharePoint needs to be configured for Claims Based Authentication for this to occur.
Hierarchical Permission Model
SharePoint 2013 continues to have a hierarchical permission model, which means permissions are organized according to a hierarchy. Permissions are initially assigned by SharePoint at the site collection level. As a result, all sites, libraries, lists, folders and content below that site collection will automatically receive those permissions. The lower level containers or items “inherit” their permissions from the level above if no specific permissions are assigned to that object.

At any level within SharePoint, a user can break permission inheritance and assign specific permissions to that level. For example, a site collection called “Demo” contains a SharePoint group called “Demo Members” which has been assigned with the Read permission. So, any member of the “Demo Members” group will have read permissions to the site collection and anything below it. The “Demo” site collection contains 3 sites, one which breaks permission inheritance so that members of the AD group “Finance_Team” has Edit permissions. As a result, all content below this site (all libraries, folders, content, etc.) will inherit the “Finance_Team” permission from their parent site, unless something below the site also break inheritance.

The following diagram illustrates this point:

Hierarchical Permission Model - SharePoint containers and items with broken permission inheritance

Figure 1. SharePoint containers and items with broken permission inheritance.


Thursday, November 14, 2013

Securing SharePoint 2013: Plan for Authentication

This post is the second in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running and are looking at built-in features and third-party solutions to secure their sensitive information.

Microsoft SharePoint 2013 comes with a variety of authentication options to fit your organization’s requirements. At its most basic level, authentication is the process of determining that a user is who they say they are. This usually occurs at login, and typically with a simple username/password match. So, when a user presents a username and password, SharePoint will then verify that the username/password combination matches what it has in its database. If it does then the user is authenticated.

Considering authentication a little more broadly, authentication can also be seen as the process of validating a user’s identity against an identity provider. Identity providers include Active Directory - Directory Services (AD DS), LDAP directories, or Active Directory Federation Services (AD FS). The use of identity providers becomes important when we look at new methods of authentication like Claims Based Authentication, which is discussed further below.

Within Microsoft SharePoint, the authentication method is configured uniquely for each web application. It’s important to note that authentication is configured when a web application is created through the Central Administration console. However, it cannot be modified through this console after a web application has been configured. To modify the authentication configuration of an existing web application, a SharePoint farm administrator will need to use the appropriate PowerShell commands.

Very similar authentication options are available in Microsoft SharePoint 2013 compared to those that were available in SharePoint 2010. However there are 2 big differences:

1.      When creating a new web application in SharePoint 2013 the default authentication method is now Claims Based Authentication.

2.      The configuration options for Windows Authentication has been removed from the Central Administration console. It can only be done through Windows PowerShell.

The authentication options available in Microsoft SharePoint 2013 are: 

§  Claims-Based Authentication (SAML Token Based)
Microsoft introduced Claims Based Authentication as an option in SharePoint 2010, in part to better support third-party authentication providers and multi-vendor environments that support internet, federated partners, or cloud computing models. Traditional authentication mechanisms did not support these environments well. With claims based authentication, once authenticated a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of attributes about the user—or claims—and each claim represents a specific piece of data about the user such as their name, group membership, role, title, security clearance, or even age. Applications like SharePoint which support claims based authentication receive a security token from a user, as opposed to credentials, which they use to determine user access to resources. This can be accomplished without having to make separate queries to directory services such as Active Directory.

Some of the more traditional Windows domain authentication protocols, such as NTLM and Kerberos, may also be used along with claims-based authentication. When using these protocols in conjunction with claims based authentication, SharePoint 2013 will make an authentication request using the classic protocol and the response (a Windows NT Token) will then be translated to a new SAML token by the SharePoint Security Token Service (STS).

As mentioned, claims based authentication is now the default authentication method within SharePoint 2013 when new web applications are created. This, combined with the fact that classic Windows Authentication has been removed from the Central Administration console and is only configurable through PowerShell, is a significant move by Microsoft. It indicates that Microsoft believes strongly in the power and robustness of claims based authentication and that it is highly recommending claims based authentication moving forward.

§  Forms-Based Authentication
Forms-based authentication validates users that enter their credentials (usually) on a web login form. It is typically used in extranet deployments of SharePoint, where external users need to log in to access SharePoint resources but those users do not have accounts in Active Directory.

Forms-based authentication is enabled through claims-based authentication and the use of a custom ASP.NET membership and role provider. Forms-based authentication can be used against credentials that are stored in various accounts sources including: a database (such as SQL Server), an LDAP directory, or even Active Directory.

§  Classic Windows Authentication
Classic Windows authentication makes use of the classic Windows authentication protocols that are supported by Windows domains to validate user credentials, such as NTLM, Kerberos, Digest Authentication and Basic Authentication. This is sometimes referred to as Integrated Windows Authentication.

Configuring Classic Windows Authentication for a SharePoint 2013 web application requires the use of PowerShell as the configuration interface has been removed from the Central Administration console.

In addition, it’s important to be aware that several caveats exist when continuing to use Classic Windows Authentication with SharePoint 2013 web applications. For example: if migrating a system using Office Web Apps with a SharePoint 2010 web application with classic mode authentication, the SharePoint web application must be migrated to the 2013 claims-based authentication method for it to continue working with Office Web Apps. Viewing and editing with Microsoft Office Web Apps will not work on SharePoint 2013 web applications that use classic mode authentication.

§  Anonymous Authentication
SharePoint 2013 also supports Anonymous Authentication for users who do not need to authenticate any credentials in order to access site resources. Anonymous Authentication is often used for public facing SharePoint sites.

Anonymous Authentication is disabled by default.  It must be enabled on each web application separately by performing the following steps:

1.      In the Central Administration Console select Application Management on the left side and then select Manage Web Applications

2.      Select the web application you are interested in, then select Authentication Providers in the ribbon, select the zone and then check Enable Anonymous Access

3.      Click Anonymous Policy in the ribbon bar

4.      Select a network zone and an Anonymous User policy

Once these steps are complete, site owners or site collection administrators for specific sites still need to enable anonymous access for individual site collections or sites.  Until this is done, no site collections, sites or libraries will be available for Anonymous Access.  This is accomplished through the following steps:

1.      A site collection administrator accesses the site targeted for Anonymous Access

2.      Select Site Settings and then select Site Permissions

3.      In the ribbon select Anonymous Access

4.      Finally select if an anonymous user can view the entire site or simply lists or libraries

For additional detailed information on the authentication options available in Microsoft SharePoint 2013, please visit the following Microsoft TechNet article:


Thursday, November 7, 2013

A First Experience with Microsoft Office 365 and SharePoint Online

Early this year I had my first experience with Microsoft Office 365, in particular with SharePoint Online, and I have to say the experience was excellent.  To set the stage, due to the nature of most of our customers at the time (primarily military and government) I typically worked with on-premises SharePoint deployments, but I was researching the capabilities offered by SharePoint Online for a specific project I was assigned and I needed to get up and running quickly.

The setup process was simple, fast and without any hassles.  It took about 45 minutes to get a new Office 365 tenant setup and using SharePoint Online.  SharePoint Online is part of Microsoft Office 365 and your first step to getting setup is to purchase an Office 365 subscription, which can be done here:
As it was my first experience, I signed up for a free trial which is also possible at this site.  When purchasing a subscription there are several plans to choose from, starting as low as $5.00 per user per month (for the Small Business subscription) and ranging up to $20.00 per user per month (for a full blown Enterprise E3 subscription).  There are several levels available between those depending on your needs and your business.

Once you’ve registered for a trial or purchased a subscription, you’ll be taken to an Administrative Center portal page.  This page allows you to manage all administrative functions for your shiny new Office 365 tenant.  It contains a number of tasks you need to perform to get setup – these include:

·        Adding Domains

Adding a domain is one of your first steps.  If you already own a registered domain name you may use it.  The Administrative Portal guides you through the process of verifying ownership and setting up the appropriate DNS records to point to your Office 365 tenant.

·        Adding User Identities

Next you’ll need to add users to your Office 365 deployment.  You can add users one at a time, specifying various attributes for each user.  Alternatively you can add users in bulk by uploading an appropriately formatted CSV file.  As well, depending on your subscription you can Active Directory Synchronization to allow existing users to use their existing AD credentials to access SharePoint Online (only available with an Enterprise level subscription plan).  As well, you can enable Single Sign On through Active Directory Federation Services (ADFS) to allow users to access SharePoint Online using their existing credentials and not requiring them to enter their credentials again. In order to enable Active Directory Synchronization and Single Sign On there are a number of steps to complete, and you should follow the Microsoft guidance provided on these very helpful articles:  Prepare for Single Sign On and Using Active Directory with Microsoft Office 365 
·        Configuring a SharePoint Team Site and Web Site, or Adding Additional Sites

Once SharePoint Online is setup it will contain 2 sites by default: a team site and a web site.  A team site is an internal SharePoint site, where teams and groups of users can exchange documents, connect with one another, store and retrieve content and generally collaborate.  A web site is a SharePoint site which represents a public facing web site for your business, where external partners and customers can retrieve information about your organization.  SharePoint Online provides both sites by default, and allows you to create additional SharePoint sites as needed from the available templates.  These default sites as well as new sites can be configured as needed, with additional libraries, lists, views, apps, web parts, etc.  At this point you can configure the default sites, or add additional sites for various purposes.
·        Creating Groups and Configuring Permissions

Once end users are created it will be necessary to configure those users with the appropriate permissions to access the content they need to perform their daily tasks.  The simplest and most manageable strategy to accomplish this is through the use of groups.  As opposed to assigning permissions to users directly, it is recommended that administrators create security groups, they add end users to those groups and then assign permissions to the groups. When first starting out with SharePoint Online this is an effective strategy to allow administrators to more easily track of which users have access to specific sites or content.  Security groups can often represent teams or roles within the organization that have certain types of access to content – for example, finance team members can be part of a “Finance” group that has the Full Control permission level assigned to the organization’s financial documents. 

SharePoint Online uses the same permission model as on-premises deployments.  So, administrators can expect to work with permission levels which are assigned to security groups or users and to content, and which are made up of predetermined permissions like View, Open, Edit, etc.  As well, they can expect to work with permissions that are inherited from libraries, lists and sites, or with unique permissions that are assigned to specific information objects like documents.

·        Configuring External Access (if required)

If required by the business, an administrator can configure SharePoint Online to allow external users to access the organization’s SharePoint Online sites.  This can be configured through the Administration Center portal by accessing Settings and selecting Manage External Users.  Once configured here than individual site collection administrators or site owners are able to configure external users to access to their site collection’s sites (it is still disabled by default and must be configured for each site collection).  They must provide the email address of each external user that is to be granted access, and they are able to send email invitations to these users to access content which has been shared to them.   This is an extremely useful option if you have business partners outside of your domain that you wish to have access to specific content within some specific site collections.

·        Adding Content to SharePoint Online

At this point you’ll likely want to start moving content into SharePoint Online.  Once you’ve figured out which content needs to move into SharePoint, you have several options available for uploading content:  uploading a single document at a time, uploading multiple documents at one time, accessing SharePoint through the Windows Explorer view to add multiple files and folders at one time, or dragging and dropping multiple files onto a SharePoint 2013 library in the web browser.  Typically, you need to think about moving other forms of content as well, such as announcements, contacts, lists, business data, databases, appointments and even business workflow.

There are of course many other options available during the setup process which are not discussed here, including configuring Microsoft Exchange for business email, Microsoft Lync for unified communications such as online chat and Skype, as well as enabling mobile access.  As well, it’s important to understand that before proceeding to get your entire organization up and running with Microsoft Office 365 and SharePoint Online, many of these steps require careful planning to ensure that they fulfill the business needs of the organization - for example:

·        Understanding which features are included with each subscription and selecting the plan is right for your business

·        Determining which users need access to SharePoint Online, which user attributes are important to configure for those users and determining if single sign on is a real requirement for the business

·        Determining which types of team sites are needed, and by which user communities

·        Determining if all corporate content needs to move to SharePoint Online, or if some content that has not been accessed for a long periods of time can be archived instead

·        Etc…

The main point I wanted to get across in this article is that Microsoft has made the process of getting up and running with Office 365 and SharePoint Online extremely easy.  As I started off mentioning, I was able to easily get a demonstration SharePoint Online instance up and running, with some users, some required customizations and some sites and content in about 45 minutes following many of the configuration steps mentioned above.  This was possible even without having much knowledge about Microsoft Office 365 and SharePoint Online to start off with. 

I highly recommend you go through the process yourself and learn all that Microsoft Office 365 has to offer – you can begin here: