Chapter 2. Authentication and security

Security within a SharePoint environment is a broad-spectrum topic, requiring a clear understanding of how users will authenticate and be authorized to access content. This chapter begins with a discussion of authentication types, and then examines how authorization is carried out at the farm, application, site collection, and site levels. Additionally, we discuss security-related functionality present at the services and service application levels of the SharePoint farm.

SharePoint Server 2016 requires authentication for three types of interactions:

User authentication A user is trying to access SharePoint resources.

App authentication An installed app is trying to access SharePoint resources.

Site-to-site (S2S) authentication Two-way resource access between servers in the enterprise.

When new web applications are created via SharePoint 2016 Central Administration, the authentication options available are all claims-aware. These web applications can (by default) use one of the three available authentication types: Windows authentication, Forms-based authentication, or Secure Application Markup Language (SAML) token-based authentication.

NTLM A Windows integrated authentication type (one of two) requiring no additional configuration of authentication infrastructure

Negotiate (Kerberos) A Windows integrated authentication type (the second of two) that requires additional configuration of Service Principal Names (SPNs) in AD DS

Basic authentication An authentication type that sends the user credentials in plain text and requires additional configuration of the web application in Internet Information Services (IIS)

Digest authentication An authentication type that sends the user credentials in an MD5 message digest and requires additional configuration of the web application in IIS

NTLM’s benefits are mostly focused on ease of use, when compared with Negotiate (Kerberos):

NTLM authentication can still function when the computer making the request is outside the network or is a stand-alone computer.

NTLM is much easier to set up and configure than its Kerberos counterpart.

There is, however, a price to be paid for NTLM’s simplicity:

NTLM is an older authentication type, using a challenge/response mechanism for authentication that is less secure than Kerberos.

NTLM has a negative effect on performance, making repeated round trips between IIS and causing an increased load on domain controllers.

NTLM does not support delegation; if a user has authenticated into a SharePoint environment and then needs to access another system through SharePoint, the request will fail.

Kerberos authentication provides several benefits:

Kerberos is the most secure of the Windows integrated protocols, and is an open protocol supported by multiple non-Microsoft vendors and platforms.

Kerberos is quite efficient, minimizing the need for a client to repeatedly authenticate to a domain controller; this efficiency reduces both server and network traffic, often reducing page latency.

Kerberos supports delegation. A user authenticated into a SharePoint environment can “double hop,” directly accessing other Kerberos-configured systems through SharePoint.

Kerberos might not always be the best option:

The proper configuration of Kerberos authentication for SharePoint requires interaction and close coordination with the Active Directory and SQL support teams.

The security mechanisms employed by Kerberos include the ability for clients and servers to mutually authenticate one another, and clients and servers can use Advanced Encryption Standard (AES) encryption.

Enabling a SharePoint site to allow anonymous authentication can be done via PowerShell or Central Administration, and can be enabled at the time the web app and zone are being created (Figure 2-2), or afterward by editing the completed web app.

SharePoint 2016 now handles encryption by default by using the newer TLS 1.2 cryptographic protocol for secured connections.

Connection encryption in SharePoint 2016 is now supported in the following situations:

When setting up SSL bindings for a SharePoint web application

When connecting to other systems (such as crawling websites)

When establishing an encrypted connection to a Simple Mail Transfer Protocol (SMTP) server

The optimal mechanism for configuring SSL with a SharePoint web application is to specify that SSL is to be used while the web application is being created (Figure 2-3), and then add and bind the certificate to IIS. This ensures that, as your farm grows, the configuration database configures any newly added front-end servers with the same SSL-enabled web application configurations.

The provisioning and configuration of web applications is covered later in this chapter.

Establishing an S2S connection via OAuth requires the involvement of three parties: an authorization server and the two realms that need to connect to each other. In the case of Microsoft servers such as SharePoint, Exchange, and others, they can assume the role of the authorization server and one of the two realms to connect; the authorization server verifies the trusts between the two realms by issuing security tokens via the Security Token Service.

When a SharePoint 2016 user needs to access functionality present in another server farm, an S2S token requests access to the resource, acting on the part of the user.

When the OAuth connection is established between realms, the implementer has a decision to make regarding encryption, specifically to encrypt or not to encrypt. By default, these connections are established via HTTPS, but the administrator has the option of overriding this behavior and allowing unencrypted HTTP connections in PowerShell.

Although STARTTLS itself is capable of supporting both TLS and SSL protocols, SharePoint 2016 does not allow the use of SSL 2.0 or 3.0 when negotiating connection encryption with an SMTP server; the only protocols supported are TLS versions 1.0, 1.1, and 1.2.

For SharePoint to securely connect to an SMTP server, the server must have STARTTLS enabled and have a valid server certificate installed, with a name that matches that provided to SharePoint during the configuration for outbound SMTP.

Configuring secure outgoing email in SharePoint can be set up on the Outgoing E-Mail Settings page under Central Administration, System Settings (Figure 2-4). Alternately, secure outgoing email can be set up via the Set-SPWebApplication PowerShell cmdlet and the -SMTPServer switch. You can optionally use the -DisableSMTPEncryption switch if the SMTP server doesn’t allow connection encryption.

This sort of arrangement is not without its share of headaches:

The organization’s IT staff are now responsible for maintaining both internal and external user accounts, often within two different authentication structures (Forms-based authentication, Active Directory).

Users from the external party must now keep track of one more set of credentials and authenticate more than once.

Special arrangements must be made to expose the authentication mechanism to the Internet, posing a security risk and requiring extra maintenance effort.

Discussions about claims-based authentication often quickly extend into user requirements for identity federation. Applications that were once exclusively held within a particular enterprise now can be extended to the cloud and into other partner enterprises.

This federation provides two major benefits for IT admins:

Extra authentication mechanisms such as Forms-based authentication or separate Active Directory structures are no longer required to provide resources or applications to external business partners.

Users traveling or working outside the enterprise network are able to work with no special arrangements, acting in the cloud much as they would on premises.

Users taking advantage of identity federation are required to maintain only one set of credentials, authenticating within their own environment to an Identity Provider Security Token Service (IP-STS), such as Active Directory Federation Services (AD FS) or Azure Access Control Service (ACS). Once users have authenticated, they receive an SAML token, which can then be used to access applications in their organization, in partner organizations, and in the cloud.

In addition to acting as an identity provider (IdP), both ACS and AD FS can instead act as federation providers (FPs). By using this functionality, you can configure either to trust any number of IdPs such as Microsoft account (Windows Live ID), Facebook, Google, Twitter, and Active Directory itself, allowing external users to authenticate using these IdPs. Additionally, you should note that the use of more than one IdP is supported.

If, on the other hand, you have not yet deployed AD FS but do have an Azure subscription, you can instead choose to deploy the Application Proxy functionality present in Azure AD. This proxy works by installing a new Windows service (called a Connector) inside your on-premises network, then registering the Connector with your Microsoft Azure AD tenant subscription.

A trust relationship to a farm that has web applications

A trust relationship to a farm that has no web applications

Configuration for each type happens from the perspective of the farm that will be receiving the S2S requests (aptly named the “receiving” farm). Although the S2S functionality is the same, configuration of the trusts differs greatly between the two types.

The configuration of S2S on a receiving farm (having web applications) requires that the New-SPTrustedSecurityTokenIssuer cmdlet be used to configure the trust, specifying the JavaScript Object Notation (JSON) metadata endpoint of the sending farm.

Click here to view code image

New-SPTrustedSecurityTokenIssuer –MetadataEndpoint "https://<HostName>/_layouts/15/
metadata/json/1" –Name "<FriendlyName>"

Configuring S2S on a receiving farm (with no web applications) obviously excludes the ability to use a JSON metadata endpoint; this configuration is a bit more involved, requiring the admin to accomplish several tasks:

1. Export the SharePoint Security Token Service certificate (.cer) without the private key from the receiving farm, then store it in an accessible location (usually a secured file share).

2. Retrieve the NameIdentifier field of the receiving farm.

3. On the trusting SharePoint farm, add the SharePoint STS of the receiving SharePoint farm as a trusted security token issued by using the following PowerShell cmdlet.

Click here to view code image

New-SPTrustedSecurityTokenIssuer -name <hostname> -Certificate "<CERLocation>"
-RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@<NameID>"
-Description "<FriendlyName>" -IsTrustBroker:$false

There are three major steps involved in completing this configuration:

Configure the SharePoint server to trust the Microsoft Exchange server by using a JSON endpoint located on the Exchange server.

Configure permissions on the SharePoint server for S2S.

Configure the Exchange server to trust the SharePoint server by using the Configure-EnterprisePartnerApplication.ps1 PowerShell script.

There are only two steps involved in completing this configuration:

Configure the SharePoint server to trust the Skype for Business server by using a JSON endpoint located on the Exchange server.

Configure the Skype for Business server to trust the SharePoint server as a new partner application.

These configuration efforts take place in Windows PowerShell and require the use of SSL for communication between server environments.

ACS enables applications such as SharePoint 2016 to integrate with both enterprise directories (such as Active Directory) and IdPs in the cloud such as Windows Live ID, Google, Yahoo!, and Facebook.

Extending this concept, a growing organization could soon find itself needing to connect to multiple partner organizations. Requiring the IT organizations from each of these organizations to agree on how they will federate could become cumbersome.

ACS provides a way for organizations to connect their SharePoint farm (and other farms, including Exchange and Skype) to a cloud-based Active Directory tenant. From here, relationships can be established with other partner organizations, or IdPs such as Facebook, Live, Google, and others can be used to authenticate into an organization’s SharePoint infrastructure.

Another benefit of using ACS is the ability to extend an organization’s SharePoint installation into the cloud for any of the following reasons:

Setting up development and test environments

Providing disaster recovery SharePoint environments in Azure

Providing Internet-facing sites using SharePoint functionality not available in Office 365 and SharePoint Online

Creating app farms to support either on-premises or Office 365 SharePoint environments

DirSync A tool that copies the local Active Directory, propagating to an Azure AD instance

FIM + Azure AD Connector Synchronized identity information from Forefront Identity Manager 2010 R2 to Azure AD

Azure AD Sync Replaced both DirSync and FIM + Azure AD Connector

Hybrid implementations varied between these different tool offerings based on the authentication goals and when the project was carried out. Some organizations chose to just implement DirSync, and others chose to fully carry out a single sign-on (SSO) implementation by using one of the other options.

As with any other deployment wizard, it is possible to run the tool and accept the express settings; however, the true value of this tool can be found in the custom settings, which allow you to accomplish tasks such as these:

Deploy multiforest topologies.

Deploy a pilot environment, that uses just a few users in a group.

Configuration without deployment (also known as Staging mode).

Sign on by using federation.

Enabling Azure AD premium features, such as the ability to write back passwords and devices from the cloud.

Synchronizing custom Active Directory attributes from your on-premises implementation to your Azure AD tenancy.

Within Azure AD Connect, there are two configurations available: Password Sync and AD FS for SSO.

From a security standpoint, on-premises passwords are never transferred to Azure AD. The on-premises password hash is itself hashed before being transferred to the cloud, protecting passwords against “pass-the-hash” attacks; the lack of access to a local hash prevents unauthorized access to on-premises resources.

With the inclusion of AD FS in this solution, advanced SSO options become available, such as these:

The ability to deploy desktop SSO from domain-joined machines on the corporate network, including the use of multifactor authentication

Soft account lockout or Active Directory password and work hours policy enforcement

Provisioning conditional access for resources, both on premises and in the cloud

The optimal assignment of the permission structure goes something like this:

1. Individual permissions are assigned to a permission level.

2. One or more permission levels are assigned to a SharePoint group.

3. Users are assigned to the SharePoint group, receiving access based on the individual permissions.

List permissions (12) Apply only to lists and libraries

Site permissions (18) Apply to a particular site

Personal permissions (3) Apply to specialized objects such as personal views and personal Web Parts

These permission levels are nothing more than an aggregation of the individual permissions available within the site collection. To view the permission levels on a site and the individual permissions assigned to each level, select the Permissions Levels icon from Site Permissions. When the Permission Levels screen appears, you see the individual permission levels available and their descriptions (see Figure 2-5).

Selecting an individual permission level will allow you to see the list of permissions that make up that permission level. The creation and alteration of permissions levels is covered in the section “Manage site and site collection security” later in this chapter.

Visitors Assigned the Read permissions for the site (view pages and list items, download documents)

Members Assigned the Contribute permissions for the site (view, add, update, and delete list items and documents)

Owners Assigned the Full Control permission level for the site (full control)

The People Picker control can be tailored to the authentication mechanism used for each zone of a web application. As each zone is created, different authentication types (and People Picker properties) can be applied.

For instance, if you have users who were being authenticated over a Forms-based authentication interface, you might choose to exclude Active Directory accounts from appearing in the People Picker. Users authenticating via a different Active Directory authenticated zone would see these accounts in their People Picker.

If you were to execute the STSADM -help setproperty command, you would find a total of nine property names that can be used to administer the People Picker web control. These property names are listed beneath the SharePoint virtual server properties section, and all begin with the “peoplepicker” prefix. These property name and property value pairs map directly to PowerShell properties and values for a web application zone (Table 2-1).

Retrieving property values in PowerShell is only slightly more involved than it was in STSADM. For instance, to retrieve the current property value for the Active Directory Search Timeout, you would run PowerShell code looking something like this:

Click here to view code image

$webApp=Get-SPWebApplication http://www.contoso.com
$webApp.PeoplePickerSettings.ActiveDirectorySearchTimeout

Changing property values in PowerShell is a very similar process. Setting the Active Directory Search Timeout property value to 45 seconds instead of the default of 30 seconds might look like this:

Click here to view code image

$webApp.PeoplePickerSettings.ActiveDirectorySearchTimeout="00:00:45"
$webApp.Update()

Users in remote offices often change roles without the site owner’s knowledge. Allowing users to request access for themselves or others allows the site owner to administer, not select, which users require access to a SharePoint site. Personnel in the remote office can now “share” content in SharePoint 2016, recommending that a person be able to access information by using one of the site’s permission groups (Visitor, Member, and so on). Users can also request access on their own.

When the request is made, the site owner is notified of the request and can then choose whether to approve or reject the permission request from Site Settings, Access Requests.

Once Sharing has been enabled, users can then share either the entire site or particular lists and libraries from the site.

Permissions in this series of objects are assigned to promote ease of maintenance:

The NewsArticles and FieldGroup sites inherit permissions from the parent site (Intranet).

The DailyUpdates and ShopNotes libraries also inherit this permissions structure.

The EmployeeSurveys list inherits its permissions from the ManagementTeam site.

Several items, however, require unique permissions and are to be separated from the overall permissions structure:

The ManagementTeam site and its lists and libraries

The Clients list under FieldGroup

Administration of this environment will be fairly straightforward because most levels inherit from their parent objects. No fine-grained permissions are required, easing administrative overhead.

At first, this would not seem to be much of a problem. A new sensitive document (bonus structure or client document) could be individually secured, right? Absolutely; but the problem occurs when the document isn’t secured properly or permissions for that series of documents change.

More in-depth details for implementing permission levels and inheritance are provided in the section “Manage site and site collection security” later in this chapter.

Anonymous site access is configured through the Site Permissions interface. Just click the Anonymous Access icon to begin the process (Figure 2-9).

Control of which items can be accessed anonymously is shown on the next page. By default, nothing can be accessed; you can choose instead to provide access to only lists and libraries or to the entire website (Figure 2-10).

Altering this setting (in this example, allowing access to lists and libraries) results in the newly assigned anonymous access being listed on the Manage Permissions page (Figure 2-11).

If a library is to be given anonymous access (but the site it is on does not allow anonymous access), then it will need to have its permissions inheritance broken from its parent site. With this change made (and anonymous access granted from a web application and site perspective), the library can be shared from its Permissions page (Figure 2-12).

Enabling anonymous access at the list or library level allows you to select the permission levels you wish to grant (Figure 2-13).

Altering this setting (in the example, assigning View access to this library) results in the newly assigned anonymous access being listed on the Manage Permissions page (Figure 2-14).

There are three web application policies that can be configured on a per-web application basis: user policy, anonymous policy, and permission policy (see Figure 2-15). These policies are configured in the Application Management (Manage Web Applications) section of Central Administration.

If you need a different policy level than what’s available OOB, you can click the Add Permission Policy Level link and create one that meets the needs of your organization.

Within the user policy, you can choose to alter the access of one or more users at the web application level (see Figure 2-17). The users specified can be assigned permissions that you specify within the permission policy for the web application.

As indicated by the warning shown in Figure 2-17, changing the policy for a web application immediately kicks off a SharePoint search crawl, which could result in diminished performance for your users. Consider waiting until off-peak hours to alter a web application policy.

In the previous section, you saw that enabling anonymous access allowed site owners to enable access to add, edit, and delete list items, which would be against policy. By using the anonymous policy, you can choose on a zone-by-zone basis whether anonymous users can be prevented from writing changes across a web application (Deny Write) or whether they have any access at all (Deny All). These options are shown in Figure 2-18.

Regardless of the content’s original context, the fact that it can be presented in SharePoint has its pros and cons. On the one hand, information that was once stored in distinct, siloed systems is now readily available for use; on the other, information that might have been improperly secured in these disparate systems can be inadvertently exposed.

For instance, if the SharePoint system being designed will be used to store medical information, knowledge management processes must be followed to comply with legal mandates. Failure to follow these mandates or to comply with auditing requirements could result in monetary and licensing penalties.

Even if your business does not have to comply with a heavy regulatory burden, you probably don’t have to go that far within your business to find reasons for considering security isolation. If you have employees, trade secrets, legal, or other boundaries, you might want to consider these design factors:

Farm architecture Do you require more than one SharePoint farm to fully segregate the presentation of your data? Are there legal requirements for separating the data stores that support your SharePoint farm?

Web application layout Legal, auditing, and human resources departments might require the creation of separate application pools for the appropriate segmentation of data.

Creating more than one search application Your business could be penalized for exposing information via search that is improperly secured. Recall from Chapter 1 that data loss prevention (DLP) searches are quite effective in reviewing your farm for content that is sensitive.

Due to the nature of the data being stored in this environment, disaster recovery to a remote location might be required, making this environment immediately available in the case of a business continuity event. These events range in scope from an extended network outage event (in which the data services provider experiences a large-scale outage) to a flat-earth event (in which the site no longer exists or is irreparably damaged for the foreseeable future).

From an Information Rights Management point of view (covered later in this chapter), this environment should be configured to restrict rebroadcast (email) and hard copy (printouts) for most users, requiring that auditing be fully enabled to track access to the data.

Users accessing this environment would likely be required to provide multiple layers of authentication, and this environment would be heavily secured from both physical and virtual (networking) points of view.

A common example of this isolation is the separation of search information. Users who are privy to sensitive information, such as salaries and personal identification information, still require the use of Search. In fact, Search might be the key mechanism with which they can get work accomplished.

Creating a different search application for these folks enables them to use a particular search index in a web application without the exposure risk associated with sharing a search application with other users in the farm.

This type of isolation is particularly useful in environments in which the application pool retains credentials from and access to sensitive line of business (LOB) systems on premises and in the cloud.

With zones now defined, the authentication mechanism for each zone in the web application can be chosen. Additionally, web application policies can be specified that will allow for administrative control over user access in each zone.

Data isolation is particularly applicable to environments in which service level agreements and recovery time objectives differ based on the type of data being accessed from within a single SharePoint farm.

SharePoint has become a bigger security target as a result of this exposure and popularity. With detailed documentation readily available describing all of SharePoint’s components and how they interact with one another, it falls to the administrator to secure Internet-facing SharePoint sites from external attacks.

Fortunately, there is a feature developed specifically for this task, called the Limited-Access User Permission Lockdown Mode, available in both SharePoint 2016 and in SharePoint Online. By using this feature, you can allow your authenticated users to log on to a SharePoint site while still securing application pages in your environment.

SharePoint presents an interesting challenge to the designers of antivirus software because documents uploaded to a SharePoint instance are not directly stored on a file system; instead, they are stored within SQL tables as a Binary Large Object (BLOB).

The direct manipulation of SharePoint databases from SQL is not supported; this prevents the direct scanning of SharePoint content databases. Instead, Microsoft provides a SharePoint Virus Scan (VS) API, which enables third-party software to interact with SharePoint content databases.

Standard antivirus software typically scans documents in two ways:

As a document is being copied to the system, it is checked for evidence of any malicious code.

The file system is scanned on a periodic basis to ensure that all existing documents remain free of malicious code.

SharePoint allows for similar functionality via third-party antivirus solutions:

As a document is being uploaded to or downloaded from SharePoint, it can be checked for evidence of any malicious code.

Existing files contained within SharePoint content databases can be scanned on a periodic basis to ensure that all existing documents remain free of malicious code.

On the Antivirus page within Central Administration, Security, you can control three major settings:

Antivirus Settings Control when documents are scanned (on upload or download), whether users can download infected documents, and whether or not the antivirus solution should attempt to clean infected documents.

Antivirus Time Out Control how long (in seconds) the virus scanner should run before timing out.

Antivirus Threads Control the number of execution threads on the server that the virus scanner can use.

The Allow Users To Download Infected Documents check box is selected by default, and enables users to download infected documents; this setting is most often enabled to troubleshoot virus-infected documents already in SharePoint BLOBs within a content database. It is recommended that when you enable an antivirus solution (for upload, download, or both), you clear this check box until required.

The Attempt To Clean Infected Documents check box enables the third-party antivirus solution to clean infected documents automatically. Bear in mind that, if this sufficiently changes a file within a content database (particularly one that has been customized from its template), the file might need to be replaced from a backup with an uninfected copy, should the cleaning be ineffective.

When configuring the Antivirus Time Out Duration setting, you can specify the amount of time that can be spent before the virus scanner times out (the default setting is 300 seconds). Decreasing this setting can result in a performance increase in a slower SharePoint environment, as scanning documents can be resource intensive.

The Antivirus Threads section is somewhat related to the Antivirus Time Out Duration section, in that the number of threads (5 by default) indicates the number of processing resources that are spent on antivirus processing. As with the time out duration, decreasing this setting can also result in a performance increase in a slower SharePoint environment.

This situation has changed dramatically. SSL certificates are being used for many different configurations, including:

Internal and external client connectivity

Connections between environments (Exchange, SharePoint, Skype for Business) via OAuth

Connections between SharePoint and Office Online Server/Office Web Apps

Connections to Microsoft Azure Workflow Manager

In the case of external client connectivity, you will most likely purchase a certificate from a well-known SSL certificate provider; but in the other cases, you need to know the essentials for exporting, copying, and importing SSL certificates correctly.

In the following example, you will interact with the certificates used by two SharePoint farms as the relationship between them is established. This example shows you how to export and import both root and security token service (STS) certificates in an interfarm setting.

This relationship is established in a secure fashion via the use of three distinct certificates:

A root certificate, which is exported from the consuming farm.

An STS certificate, which is exported from the consuming farm.

Another root certificate, which is exported from the publishing farm.

Click here to view code image

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content "C:ConsumingFarmRoot.cer" -Encoding byte

Running the Get-SPCertificateAuthority cmdlet by itself will return the certificate details, including an expiration date that is set far in the future (Figure 2-20).

Click here to view code image

$stsCert = (GetSPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$stsCert.Export("Cert") | Set-Content "C:ConsumingFarmSTS.cer" -Encoding byte

Click here to view code image

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content "C:PublishingFarmRoot.cer" -Encoding byte

Copy the ConsumingFarmRoot.cer and ConsumingFarmSTS.cer files from the consuming farm to the publishing farm.

Copy the PublishingFarmRoot.cer file from the publishing farm to the consuming farm.

Click here to view code image

$trustCert = Get-PfxCertificate "C:PublishingFarmRoot.cer"
New-SPTrustedRootAuthority "PublishingFarmRA" -Certificate $trustCert

Confirm the creation of the trusted root authority by using the Get-SPTrustedRootAuthority command.

Click here to view code image

$trustCert = Get-PfxCertificate "C:ConsumingFarmRoot.cer"
New-SPTrustedRootAuthority "ConsumingFarmRA" -Certificate $trustCert

Confirm the creation of the trusted root authority by using the Get-SPTrustedRootAuthority command.

Click here to view code image

$stsCert = Get-PfxCertificate "c:ConsumingFarmSTS.cer"
New-SPTrustedServiceTokenIssuer "ConsumingFarmSTS" -Certificate $stsCert

Kerberos is the strongest integrated Windows authentication protocol, capable of enterprise-grade encryption and mutual authentication between clients and servers.

Kerberos allows for the delegation of credentials, enabling clients to authenticate into an environment and then allow that environment to connect to other servers or services on their behalf.

Kerberos heavily reduces the amount of network authentication traffic to AD DS domain controllers.

In SharePoint 2016, we have the ability to use Kerberos in two ways:

Basic Kerberos delegation Can cross domain boundaries within the same forest, but cannot cross a forest boundary

Kerberos constrained delegation Cannot cross domain or forest boundaries, except when using Windows Server 2012 or greater domain controllers (DCs)

Service applications often require Kerberos delegation to allow SharePoint users to access external, non-SharePoint resources. These service applications quickly divide into two groups, depending on the Kerberos delegation required.

Service applications that are less restrictive, supporting either basic or constrained Kerberos delegation, include the following:

Business Data Connectivity Services

Access Services

SQL Server Reporting Services

Other service applications require the translation of claims-based credentials to Windows credentials, and use Kerberos constrained delegation only. These include:

PerformancePoint Services

InfoPath Form Services

Visio Services

The RMS client is installed by default along with all the other SharePoint Server 2016 components, making the configuration and integration with RMS that much easier.

When implementing IRM, you have three choices for specifying the location of Windows RMS, found on the Configure Information Rights Management menu beneath the Security section of Central Administration:

Do Not Use IRM On This Server The default selection, this prevents the use of IRM on this server.

Use The Default RMS Server Specified In Active Directory Enable the use of RMS within this SharePoint implementation.

Use A Particular RMS Server This allows you to select a particular RMS server for use with SharePoint Server 2016.

There is an additional selection check box on this page, allowing tenants of this SharePoint farm (in a multitenancy configuration) to configure their own IRM settings (Figure 2-21).

Selecting the Check This Box In Multi-tenant Configurations To Allow Tenants To Configure Tenant Level IRM Settings check box allows Windows PowerShell cmdlets to be used for enabling, disabling, and configuring IRM for each individual tenant, also allowing for the selection of a desired RMS server.

Alternately, Windows PowerShell administration for on-premises RMS deployments is carried out via a total of four cmdlets:

Get-SPIRMSettings Returns the IRM settings

Get-SPSiteSubscriptionIRMConfig Returns the IRM settings for a specified tenant within the farm

Set-SPIRMSettings Sets the IRM settings

Set-SPSiteSubscriptionIRMConfig Sets the IRM settings for a specified tenant within the farm

Setting up delegated administration means two things:

Less experienced admins become familiar with individual components and can have their responsibilities expanded as their skills mature.

More experienced admins do not have to be continuously on call to perform rudimentary maintenance tasks.

Up to this point, it is likely that a small group of individuals have had access to the server farm account and they have been using it to accomplish administrative tasks. Although this might not have caused an issue (yet), allowing several people to have access to this credential set is just not a good idea and does not comply with any sort of auditing requirements. Simply put, if everyone logs in with the same account, then it’s impossible to determine who makes which changes in the farm.

The SharePoint farm account:

Has full access to each of the databases in the SharePoint infrastructure (and the permission to create and delete more).

Serves as the application pool identity for the Central Administration website.

Is the process account for the Windows SharePoint Services Timer Service.

To begin the process of delegating administration, you must first decide whether the user being delegated needs to be a Farm or a Shared Services Administrator.

The Farm Administrators group

The Windows Administrators group

Members of the Farm Administrators group have Full Control permissions to all servers in the farm and can be responsible for their general upkeep. Users in this group administer all the items they see in Central Administration: delegating service application permissions; administering managed accounts; and creating, deleting, and editing application pools, databases, and site collections. Backups and restores are possible, even to the extent of backing up content databases without having to interact directly with SQL Server through SQL Server Management Studio (SSMS).

Members of the Windows Administrators group on the local server can act as farm administrators, because the BUILTINAdministrators group is added to the SharePoint Farm Administrators group (by default). These administrators can log on locally to the server, and have console-level access to install binaries to the farm, create new websites, and administer services. As is the case with the Farm Administrators, they have no default access to site content.

For instance, although a Search service application administrator can freely make changes to the functionality present in the service application, he or she cannot make changes to the topology of Search, assigning or removing Search roles to a server in the farm.

SharePoint 2016 continues the concept of managed accounts first introduced in SharePoint 2010. A managed account is an Active Directory account (usually used as a service account) with a password that is maintained within the bounds of SharePoint itself. If configured to do so, this account is capable of automatically changing its password in accordance with your organization’s security governance strategy.

A SharePoint managed service account enables you to change the account credentials from within Central Administration. These passwords can be changed either manually (by an administrator) or automatically (by SharePoint) on a timed interval.

If your infrastructure team enables a password change policy for your enterprise, SharePoint managed accounts can be configured to observe these changes, thus keeping your farm in compliance with the enterprise password policy.

Should the service account be able to change its own password?

Is there already a password policy in place, and how far in advance should my farm change the password?

Should the Farm Administrators receive advance notice of this change, and when should they be notified?

With the answers to these questions, you are now able to register a new managed account from Central Administration, Security, Register Managed Account. Initially, you will specify credentials (an initial user name and password) for the service account, and then configure the Automatic Password Change settings (Figure 2-22).

The interface for this functionality is a bit cluttered; the Weekly and Monthly options are not for email notifications, but for how often the password should change and what the window of opportunity is for changing the password, in accordance with your governance policies.

There are several scenarios that might define a reason for a file type to be disallowed. For instance, if your organization has a media server that streams MP4 video files, you might want to prevent these files from being uploaded into SharePoint document libraries. Certain file types might also be disallowed just because they can contain malicious code (as an example, .exe files are disallowed by default).

Files are blocked by just examining the file extension to determine the type; if you were to change an extension from a forbidden to an acceptable type (from .mp3 to .txt, for instance), the file would be allowed to upload into SharePoint.

The configuration of blocked file types is done on a per-web app basis to accommodate design choices you make for representing data within your SharePoint farm. To add or remove a new blocked file type (Figure 2-23), go to the Security menu of Central Administration and then select Define Blocked File Types from within the General Security section.

On this page, you can do the following:

Select an extension and delete its entry to unblock it.

Add a new file extension in and it will be blocked. It is not required to add a new entry in alphabetical order, as it will be reordered automatically.

The SharePoint Web Part infrastructure is a direct extension of the ASP.NET Web Part infrastructure; therefore, security guidelines that apply to ASP.NET are applicable to SharePoint development as well, because SharePoint is built on top of ASP.NET.

Security for Web Part Pages is controlled from within Central Administration, Security, General Security. These settings directly control what abilities are given to users within that web application to configure, connect, and modify Web Parts (Figure 2-24).

Within the context of administration, SharePoint Web Part security can be configured in three ways:

Connections between Web Parts can be allowed or disallowed.

Access to the Online Web Part Gallery can be allowed or disallowed.

Web Parts that host JavaScript can be allowed or disallowed.

This service application is used to provide user profiles, profile synchronization with enterprise directory services, audiences, the My Site host and individual My Sites, and social notes and tagging.

Profile database Stores information about users, such as a profile picture, the organization the users belong to, and so on.

Social database Stores social tags and notes associated with individual users’ profile IDs.

Synchronization database Stores configuration and staging data for use when profile data is being synchronized with directory services such as Active Directory.

Naming the UPA and specifying its Application Pool and Credentials.

The Server, Name, Authentication Type, and Failover Server (mirroring only) for the Profile, Synchronization, and Social Tagging databases.

The My Site Host URL and Managed Path.

The Site Naming format, and whether or not to resolve naming conflict automatically.

The Default Proxy Group.

Yammer Integration (choosing whether to use Yammer or on-premises SharePoint social functionality for social collaboration).

New-SPProfileServiceApplication Enables you to specify the service application pool name and databases that you want to use for the new service application.

New-SPProfileServiceApplicationProxy Enables you to create a service application proxy or connection for use with the service application; this proxy is usually associated with the default proxy group.

Create Personal Site (required for personal storage, newsfeed, and followed content)

Follow People and Edit Profile

Use Tags and Notes

If you want to alter these permissions, you can do so by managing the UPA application itself from Services Applications in Central Administration (Figure 2-25).

Configuration of these settings can be done either automatically or manually. Automatic configuration is done via the Hybrid Picker in SharePoint Online, and requires that the person running the picker be:

A member of the Farm Administrators group

A Service Application Administrator (Full Control) for the UPA

Either an Office 365 Global Administrator or a SharePoint Online Administrator

Logged in to both Office 365 and SharePoint Server from a server in the SharePoint farm

Manual configuration of these features only requires that you be able to determine the URL of your My Sites URL in Office 365, determine if any audiencing is required, and select the appropriate hybrid features. To determine the appropriate My Sites URL, look for the site collection in your Office 365 configuration that looks like <domain>-mysharepoint.com.

Active Directory Import, although not as complex or as powerful as MIM synchronization, does cause the import to be significantly faster, but at a cost:

It imports with a single Active Directory forest only; multiforest configurations are not supported.

It does not import user photos automatically.

It supports nothing but Active Directory Lightweight Directory Access Protocol (LDAP).

The lack of bidirectional functionality precludes this option from being useful for adding metadata about users from SharePoint profiles to Active Directory (such as phone numbers, addresses, and so on).

From this page, a new connection can be established with Active Directory, requiring the following information:

Connection Name The friendly name for your Active Directory connection.

Type Active Directory Import (the only option for this configuration).

Connection Settings Requires several different types of information, including:

The Fully Qualified Domain Name (FQDN).

Authentication Provider Type, either Windows Authentication, Forms Authentication, or Trusted Claims Provider Authentication.

Authentication Provider Instance, used for Forms or Trusted Claims Provider Authentication only.

The Account name and Password of the account that will retrieve the profile information.

The TCP Port (defaults to 389, for LDAP).

Options including whether or not to use an SSL-secured connection, Filter out disabled users, and another option for Filtering in the LDAP syntax.

Containers Selecting Populate Containers allows the user to specify which container in Active Directory is to be synchronized in this connection.

Two options exist for integrating MIM with SharePoint 2016: Convert from FIM or New MIM deployment:

To convert the Sync service XML files, use the following process:

Export the server configuration from Miisclient.exe (your FIM management console in the SharePoint 2013 farm) and save this to a location that will be available to the MIM server.

Convert the exported file by using the ConvertTo-SharePointEcma2 PowerShell cmdlet on the MIM server.

Open the Synchronization Service Manager by using the Start-SynchronizationServiceManager cmdlet on your MIM server.

Connection information (usually just the password) will be required for each management agent used in the configuration of your MIM installation.

In this profile, you can see the following:

Property fields (Name, Work Phone, Department, and so on)

Active Directory mappings (indicated by the cylinder and link icon)

Show To field (Everyone, for the fields shown)

This last field, Show To, chooses one of two social levels that can be allowed to view a field (Only Me, Everyone). The selection of a social level enables or disables the field to be shown to people in your organization, and also controls the feed events for that field (a setting of Only Me shuts it off, a setting of Everyone turns it on).

Profile properties are also able to be configured independently or for use with Active Directory. If there is a custom property in the Active Directory schema for your organization that makes sense to have in a user profile, then it’s fairly straightforward to include this as a custom property in SharePoint.

Profile properties are broken into sections:

Basic Information (name, work phone, title)

Contact Information (work email, mobile phone, home phone)

Details (past projects, skills, interests)

Delegation (empty by default)

Newsfeed Settings (email notifications, people I follow)

Language and Region (time zone, define your work week, and so on)

Custom Properties (enables you to add new properties)

To alter a profile property, just select Edit from its drop-down menu. Most often, the items you will interact with are the mapping to Active Directory and the Policy Setting, which determines whether a user can change the setting and what the default privacy setting is.

When a SharePoint infrastructure extends beyond the scope of an initial farm, the question of user identity rehydration comes into play. S2S infrastructures allow two SharePoint farms to connect, whether on premises or in the cloud. With this in mind, we must consider how claims integration works in such an arrangement.

Let’s take two SharePoint farms as an example. A user is authenticated into the first farm but requires access to the other. The second SharePoint farm server has to accomplish two tasks to provide the resource:

It has to be able to resolve the request to a specific SharePoint user.

It has to determine the set of role claims that are associated with the user (rehydrate the user’s identity).

SharePoint Server 2016 takes claims from the incoming security token and resolves this to a specific SharePoint user by using the UPA. To rehydrate the user’s identity, one of the following four key user attributes must be current in user profiles:

The Windows Security Identifier (SID).

The Active Directory Domain Services (AD DS) user principal name (UPN).

The Simple Mail Transfer Protocol (SMTP) address.

The Session Initiation Protocol (SIP) address.

Scrolling to the bottom of the page and clicking Create will commit your changes. Your new permission level is now ready for use (see Figure 2-42).

Do Not Permit Contributors To Insert Iframes From External Domains Into Pages On This Site (default)

Permit Contributors To Insert Iframes From Any External Domain Into Pages On This Site

Permit Contributors To Insert Iframes From The Following List Of External Domains Into Pages On This Site (selected for this example)

The last option enables you to determine the domains from which you allow iframes to be chosen. A sample listing of iframes is already chosen for you, including those from YouTube, Vimeo, and Microsoft. You can also add other domains of your choosing.

Configuring efforts at this level of the farm implementation form your first effort at maintaining effective security and governance mechanisms.

There are two distinct types of managed paths:

Wildcard managed paths Enable one site collection to be the “implied” parent of several site collections by using a wildcard path value (for example, http://URL/path/Site1, http://URL/path/Site2).

Explicit managed paths Enable one and only one site collection to be nested directly beneath another within a navigational structure (for example, http://URL/Site1).

Managed path creation varies based on whether you will be using path-based site collections (PBSC) or host-header site collections (HHSC). Managed paths created for HHSC are defined at the farm level rather than at the web application level, and cannot be created or administered from Central Administration. They are also shared among all HHSCs in the farm; for example, adding /americas as a managed path on http://intranet.wingtiptoys.com/americas would also add it to http://backoffice.wingtiptoys.com/americas.

1. From the Application Management page, Manage Web Applications, select the web application for which you want to create a managed path. When the ribbon activates, click the Managed Paths icon.

2. The Defined Managed Paths page appears, showing all existing paths. In the Add A New Path section, specify the name of a new managed path (see Figure 2-44).

3. Finally, select whether the new link is to be a wildcard inclusion (selected in this example) or an explicit inclusion and then click Add Path.

1. From the Application Management page, Manage Web Applications, select the web application for which you want to create a managed path. When the ribbon activates, click the Managed Paths icon.

2. The Defined Managed Paths page appears, showing all existing paths. Select an existing managed path and click Delete Selected Paths (see Figure 2-45).

3. The Define Managed Paths page now shows the existing managed paths, with the americas managed path removed. Click OK to close the window.

Creating the “americas” managed path in a PBSC web application only requires a couple of lines in PowerShell:

1. Start by assigning a variable for your web application by using the Get-SPWebApplication cmdlet:

Click here to view code image

$webApp = Get-SPWebApplication -identity http://intranet.wingtiptoys.com

2. Use the New-SPManagedPath cmdlet with the web application variable to build the managed path (note that if the -explicit switch is not specified, this cmdlet will build a wildcard inclusion):

Click here to view code image

New-SPManagedPath "americas" -WebApplication $webApp

Remembering that managed paths for an HHSC web application are defined at the farm level, we find that creating the “americas” managed path would be even easier, requiring only one line of PowerShell (no reference to a web application is required):

3. Use the New-SPManagedPath cmdlet without the web application variable, but with the -hostheader switch (note that if the -explicit switch is not specified, this cmdlet will build a wildcard inclusion).

Click here to view code image

New-SPManagedPath "americas" -HostHeader

To remove the “americas” managed path in a PBSC web application also requires a couple of lines in PowerShell:

1. Again, start by assigning a variable for your web application by using the Get-SPWebApplication cmdlet:

Click here to view code image

$webApp = Get-SPWebApplication -identity http://intranet.wingtiptoys.com

2. Use the Remove-SPManagedPath cmdlet with the web application variable to delete the managed path:

Click here to view code image

Remove-SPManagedPath -identity "americas" -WebApplication $webApp

Removal of the “americas” managed path on an HHSC web application requires only one line of PowerShell (no reference to a web application is required):

1. Use the Remove-SPManagedPath cmdlet without the web application variable, but with the -hostheader switch.

Click here to view code image

Remove-SPManagedPath "americas" -HostHeader

Three major activities are involved in the configuration of alternate access mappings in SharePoint 2016:

Editing public URLs

Adding internal URLs

Mapping to external resources

Administrative control of SharePoint Designer is controlled on a per-web application basis and enables four distinct configuration options:

Allowing or preventing SharePoint Designer to be used in a given web application.

Allowing or preventing Site Collection Administrators to detach or customize pages from the site template, which can result in performance loss.

Allowing or preventing Site Collection Administrators to customize individual master and layout pages, a key requirement for customizing most SharePoint installations.

Allowing or preventing Site Collection Administrators to inspect and modify the URL structure of their website.

Configuration changes for these four options are carried out by selecting Application Management, Manage Web Applications in Central Administration and then selecting the General Settings, SharePoint Designer menu item for an individual web application.

Connection encryption in SharePoint 2016 does not use SSL 3.0, instead preferring TLS 1.2.

Identity federation can use AD FS or Azure ACS.

SharePoint 2016 uses the OAuth 2.0 protocol to establish server-to-server connections; this can happen over HTTPS (default) or HTTP.

Azure AD Connect has replaced DirSync, FIM+Azure AD Connector, and Azure AD Sync to implement hybrid cloud deployments.

SMTP outgoing email has to be configured for access requests to work properly.

Web application policies include user policy, anonymous policy, and permission policy.

S2S trust relationships require a root certificate from the consuming farm, an STS certificate from the consuming farm, and a root certificate from the publishing farm.

Managed accounts can be configured to automatically follow a defined password policy, but are not the same as Active Directory managed accounts.

A User Profile service application has three databases: profile, social, and synchronization. It can be configured to do an Active Directory import only or be configured to integrate with MIM.

Hybrid OneDrive for Business settings can be configured manually or via the use of the Hybrid Picker.

One of the following four attributes must be used for the user’s identity to rehydrate in a claims integration with UPA: the Windows Security Identifier (SID), the AD DS user principal name (UPN), the SMTP address, or the SIP address.

App permissions levels include Read-Only, Write, Manage, and Full Control; app permission request scopes include SPSite, SPWeb, SPList, and Tenancy.

Managed paths for path-based site collections can be created via Central Administration or PowerShell, whereas managed paths for host-header site collections can only be created via PowerShell.

You are looking to extend your SharePoint farm installation to external users, and are evaluating the different authentication mechanisms for both partners and users who would authenticate by using Google and Windows Live.

Answer the following questions for your manager:

1. What sort of mechanisms could you use if you do not prefer any sort of cloud connection?

2. How might your organization federate with partner organizations?

3. What sort of changes might you need to make to allow trusted party authentication?

2. Your organization could use Azure AD to authenticate users, either by synchronizing accounts or by using SSO (AD FS). Partner organizations could establish federation through an AD FS trust or preferably could connect to the Azure AD with a trust.

3. Trusted party authentication would assume the use of Azure AD connected to a trusted authentication provider such as Google or Windows Live. You would likely need to add one or more fields to your Active Directory schema for claims authentication.