Planning Zones for Web Applications In SharePoint 2013

There are different logical paths, and zones represent them for gaining access to the same sites within a given web application. Each of these web applications may have up to 5 zones. As you create a web application, one of the zones will be named default by Central Administration (WCAM). You can create the additional zones by extending the web application. Then you can select any of the zone names that remain. They include:

  1. Intranet
  2. Extranet
  3. Internet
  4. Custom

 The plan you have in place for the different zones depends on:

  1. Classic Mode This isn’t recommended, and you can only implement 1 type of authentication in each zone. It is important to know that this option only supports Windows authentication methods.
  2. Claims Based Authentication This is recommended and you can implement several providers on one zone. You do have the option of using many zones if you like.

When you use claims based authentication for more than one method per zone, it is recommended that you do so on the default zone. This will result in the same URL for all users. When you decide to implement many authentication methods on the same zone, you will encounter the following restrictions:

  1. Only 1 instance of forms based authentication can be placed in a zone.
  2. For multiple SAML token based authentication, providers are configured for the farm. All of them appear as options when you create a web application or a new zone. You can configure all of them on the same zone. 

It is possible for users from various directory stores to use the same URL in order to access a partner website.

NTLM is required for the crawl component to be able to successfully access content. There must be at least 1 zone that is configured to use NTLM authentication. If it isn’t configured in the default zone, the crawl component will be able to use another zone that is configured to do so.

In order to successfully implement more than 1 zone for web applications you need to:

  1. Use the default zone to implement your secure authentication settings. A request won’t be able to be associated with a specific zone unless the settings and security of the default zone are applied. This is the zone that was created when you made the web application. The most secure authentication settings are created for end user access, so they will be able to access the default zone. 
  2. Use the minimum number of zones that are required in order to provide users access. Each of the zones is associated with a new IIS site and domain. They allow the web application to be accessed. Don’t add new access points until they are required.
  3. Make sure at least 1 of the zones is configured to use NTLM authentication for the crawl component. Don’t create dedicated zones for the index component unless you must.

The default zone can be used for remote employees as each zone offers a different URL. You can assign employees to different zones based on if they work in-house for you or externally. With server to server authentication, the servers are able to authenticate based on requests for resources from one to the other for the users. Servers that are able to run SharePoint 2013 or other software that supports Microsoft protocols offer a new set of functions that can be accessed through cross server resource sharing.

In order to provide the right resources from one server to the next, there is a server to server authentication. The server that runs SharePoint 2013 has to be able to:

  1. Verify the requested server is trusted. This requires you to configure the server so that it runs SharePoint 2013 to trust the server sending requests. This is a one way trust relationship.
  2. Verify that the type of access the sever is requesting is authorized. You must configure the sever that runs SharePoint 2013 for the right set of permissions for the requested resources.

The server to server authentication protocol in SharePoint 2013 is separated from the user authentication. It isn’t used as a sign in authentication protocol by SharePoint users. The server-to-server authentication protocol uses the Open Authorization 2.0 Protocol (OAuth). It doesn’t add to the set of user sign on protocols such as WS Federation. There aren’t any new user authentication protocols found in SharePoint 2013. The server to server authentication doesn’t appear in the list of identity providers.

Share

Strategize for Forms Based Authentication In SharePoint 2013

You can use forms based authentication when you wish to authenticate users against an identity management system that isn’t based on Windows. You can also use it for an external system as long as you register the membership provider and role manager in the Web.config file. SharePoint 2013 uses the standard ASP.NET role manager interface in order to collect group information about the current user.

The ASP.NET role is considered to be a domain group by the authorization process in SharePoint 2013. Role mangers are registered in the Web.config file the same way that you would register membership providers for authentication. To manage membership roles from the Central Administration (WCAM) website, you need to register the membership provider and the role manager in Web.config file for the Central Administration website. You also need to register that membership provider and the role manager in the Web.config file for the web application that hosts content.

Share

Server to Server Authentication In SharePoint 2013

The process of server-to-server authentication involves the validation of the request a server gets for resources. It is based on a trust relationship that is between the STS of the server that runs SharePoint 2013 and the STS of another sever that supports the OAuth server to server protocol. This is a trust relationship so a requesting sever can access the resources that are secured on the SharePoint sever. This is done on behalf of a specific user account. It is also subject to the permissions of a given sever and a given user.

For example, this occurs when a server running Exchange Server 2013 is able to request resources of a server that is running SharePoint 2013 for a specific user account. This is in contrast with app authentication which involves the app not having access to the user account credential information. The user can be signed into the server, making the resource request but it isn’t a requirement. It depends on the specific service and the request being made.

When a server is running SharePoint 2013, there is an attempt to access a resource on a server. The incoming access request has to be authenticated in order for the server to accept the incoming access request and data. With server-to-server authentication, there is verification that the server running SharePoint 2013 and the user that is accessing it in the representation are both trusted.

The token that is used for any server-to-server authentication is a server-to-server token rather than a logon token. This server-to-sever token has information about the server that requests access. It also has information about the user account that the server is acting on the behalf of. With on premises servers, this is an example of how that basic process will occur:

  1. A user opens a SharePoint web page that requires information from another server.
  2. SharePoint 2013 generates a server-to-server token.
  3. SharePoint 2013 sends the server-to-server token to the new sever.
  4. The other server has to validate the server-to-server token from SharePoint.
  5. The other server has to send a message to SharePoint 2013. This message indicates that the server-to-server token was valid.
  6. The service on the server running SharePoint 2013 accesses the data on the server.
  7. The service on the server running SharePoint 2013 renders the page for the user.

If both servers are running Office 365, this is an example of how that process will occur:

  1. The user opens a SharePoint web page that requires information from another server.
  2. SharePoint Online requests and obtains a server to server token from ACS.
  3. SharePoint Online sends the server to server token to the server for Office 365.
  4. The server for Office 365 verifies that the identity of the user is correct based on the ACS server to server token.
  5. The server for Office 365 sends a message to SharePoint Online to state that the token sent through server-to-server has been validated.
  6. SharePoint Online accesses the data from the server for Office 365.
  7. SharePoint Online renders the page for the user to access.
Share