Understanding The Different Hybrid Deployment Options

A hybrid environment making use of SharePoint Server 2013 and SharePoint Online makes it possible for solutions that integrate functionality in between services and functions in both environments such as Search, Business Connectivity Services (BCS), and Duet Enterprise Online. A hybrid environment offers 3 layers of trust and service integration: Domain federation, Server-to-server (S2S) trust and identity management, and Service integration. Domain federation enables SSO and AD directory synchronization, which offers federated authentication and account synchronization from on-premises AD to Windows Azure Active Directory (Azure AD). Azure AD offers authentication services for Office 365 user accounts and federated accounts from a linked on-premises AD DS domain, and also serves as a trusted token issuer in hybrid environments. The Azure AD tenancy connected with your Office 365 tenant is not itself an independent tenant, but is rather a distinct identifier for your Office 365 tenant within the international Office 365 Azure AD tenant. You can not perform management operations on the Windows Azure AD tenant. Server-to-server (S2S) trust and identity management makes it possible for reputable communications between SharePoint Server 2013 and SharePoint Online, and allows OAuth authentication for federated users. Service integration allows integration in between sustained SharePoint Server 2013 and SharePoint Online services such as Search, Business Connectivity Services (BCS), and Duet Enterprise Online. Integration at this level depends on brand-new attributes and integration support included in SharePoint Server 2013.

A hybrid environment can be set up One-way outbound, One-way incoming, and Two-way (bidirectional). One-way outgoing authorization topology makes it possible for the on-premises SharePoint Server 2013 farm to connect to SharePoint Online. One-way inbound authentication topology makes it possible for SharePoint Online to connect to SharePoint Server 2013 through a reverse proxy gadget. Two-way or bidirectional authorization topology enables hybrid connections between both environments. If extranet authentication services are configured, this topology likewise permits extranet individuals to log in from another location with an on-premises Active Directory account and utilize all available hybrid functionality.


SharePoint And ADFS: SecurityTokenException – The issuer of the token is not a trusted issuer

This is a pretty common ADFS error, and there are all sorts of reasons that it could happen.

The stack trace will be this:


Microsoft.SharePoint.IdentityModel.SPTrustedIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.SharePoint.IdentityModel.SPPassiveIssuerNameRegistry.GetIssuerName(SecurityToken securityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)

   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)

   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)

   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)

   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)

   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


At the end of the day though, don’t sit around and fiddle with the SharePoint trusted authorities and yada yada yada, it boils down to a certificate problem. Basically the one that was specified as the signing certificate, when exported during the ADFS setup, is either malformed (the certificate chain is incomplete) or plainwrong wrong when the trusted issuer was being built up in SharePoint ala powershell. So to get around the error follow two pretty basic steps.

  1. Verify the appropriate certificate chain is present on the SharePoint server in both the trusted root authorities as well as in the SharePoint folder within the Certificate MMC snap-in. Never ever, ever delete the self issued ones that SharePoint provisioned within that folder. You will cause a Micheal Bay-spolosion. To verify the chain, just popup open the certificate details within some interface (like, the MMC :) ) doesn’t really matter what and verify that the chain is trusted and existent.
  2. Next, verify that you actually used the right certificate when specifying the certificate path when building the System.Security.Cryptography.X509Certificates.X509Certificate2 object to pass into your SPTrustedIdentityTokenIssuer. This is pretty easy to mess up when troubleshooting if you are swapping certs all over the place.

Both of these are in place, then that error will go away. Not that another won’t popup :)


Free Software – SharePoint Kerberos Buddy – Detect And Repair Kerberos Issues

The next best thing to a SharePoint security consultant! Kind of.

Kerberos authentication with SharePoint, and some of the middle-tier issues it presents (particularly when examining orthodox double-hope scenarios) can become both arduous, and frankly redundant to fix. A lot of the time it is typical that a SharePoint consultant is presented with a remediation project where the Kerberos environment is malformed, and the specific issue can be attributed to a wide variety of components, on different machines with different roles etc. As such, it makes sense to provide some level of automation for the detection of such misconfiguration since the actions taken for detection are pretty rhythmic. Since Kerberos is a pretty black-and-white technology (either works or it doesn’t!), pushing recommendations for a fix based on a large set of data capture from all subscribed tiers is pretty feasible. Obviously not going to be 100% since environments are also particular, but it can be pretty close and still give relevant, useful advice.

In itself the data capture presents a fundamental issue, since the machines that are involved in a SharePoint/Kerberos mixed-tier environment can potentially be exclusive (meaning, not on the same box so flowing authentication through), delegation problems can arise on four (this can be a lot more, but from a bare-bones BI environment perspective with full break-out of roles) main tiers: the client, the SharePoint WFE, the SSRS machine (obviously when not in integrated mode), and the SSAS machine. The latter two of these becoming vital when implementing a business intelligence solution where PowerPivot and PerformancePoint are relevant issues to consider and certain services like SSAS are off-loaded. Considering account break-out to isolate services to particular identities, the delegation scheme becomes even more complex. So there are a lot of things to consider, and a lot of things that can go wrong. Therefore all tiers have to be considered and data provided from each:

After examining what I feel is a reasonable breadth of Kerberos issues over the past few years there are a lot of common things that can be automatically checked, and solution advice automatically written that help to solve those issues. Some of these are as small as tolerated machine time differences and others as complex as port checks for clustered or balanced SSAS instances in SharePoint/BI environment. For example, consider 20 of the things that the tool will automatically check:

  1. Client Internet Explorer Settings
  2. Client Delegations
  3. Machine Time Differentiation Between Tiers
  4. Proper Domain Trusts
  5. OLE DB Provider (SSRS, SSAS) Types And Versions
  6. Required Data Warehouse Instance 
  7. Provider Versioning Checks
  8. Malformed Provider Strings
  9. HTTP Host Name Checks
  10. IP Address Conflicts
  11. Duplicate SPN’s
  12. Malformed SPN’s (Both Those That Are Causing Errors As Well As Unnecessary Ones)
  13. SharePoint Application Pool Account Delegation
  14. Authentication Provider Types
  15. Configuration Files (SSRS, SSAS, SharePoint)
  16. Connection String Verification
  17. Named Instance Pre-Req’s
  18. SQL Browser Settings
  19. Cluster/Port Resolution
  20. Kerberos.dll Bug-Fix Existence

So, it’s pretty robust as that is just a subset of the checks, there are others that I am forgetting. I am sure I will be adding onto it at a later time as well.

When you first open the tool, you will be presented with the primary analysis screen that will offer very little enabled controls. However notice the fine icon use that is sorta relevant to the word Kerberos, but I think it’s actually just three dogs looking different directions. A majority of the interface buttons will be not enabled since no analysis files are present yet, firstly the tool must be run on all relevant tiers within the environment.

SharePoint Kerberos Main Form

Holistic analysis cannot occur unless properly formatted *.sharepointkerberos files (nothing fancy about the file type just the name I choose when going between a BinaryFormatter) have been generated on all tiers, as you will see shortly when present these files will enable the Analyze option in the primary analysis form. 

Firstly, you will select which role that the machine you are running the SharePoint Kerberos Buddy on (it is possible to run remotely, but it introduces a bunch of possible problems that are not handled currently within the tool) is targeting, either the Client, SharePoint WFE, stand-alone SSRS, or SSAS role. This is accomplished by selecting the Configure Profiling button at the top of the application which will display a new setup screen to adjust role targetting. Once this button is selected, you will be presented with the Kerberos Delegated Environment Role Selection screen:

For the Client option, no further information is required however do not run the tool on the SharePoint WFE *as the client test*. Meaning, collect the data for the client analysis results on a domain authenticated (the tool will tell you if it detects it is running under a local account) client machine that is used to access SharePoint during normal business operations. Kerberos testing for the delegated machine will heavily skew the results if collected on the SharePoint machine. Once the IE Client option is selected, simply selecte the Initialize button. This will close the current configuration form and enable the Client Results button on the main form.

Selecting the Client Results button will display the collated, formatted result in a seperate form:

For the SharePoint tier, a URL must be provided. Best case scenario your most commonly accessed URL is also the default path in your SharePoint AAM settings, and this is the one you should use in this instance. The application doesn’t really dig it when the AAM settings are all over the map. Since your SPN registration will follow certain service protocols based on the bindings you configured for SharePoint, this has to coordinate to the appropriate URL. Select the Configure Profiling option and enter the URL in the SharePoint URL box:

Click the  Intialize  button and then the SharePoint Results button will become enabled. Then you can view the holistic results in the common informational display form:

For a Stand-Alone SSRS instance, the selection will be provided for you and the SSAS settings for how Kerberos functions require a well-formed data source connection string. Once the role is selected and the prerequisite information is populated, simply click the Initialize button.

At this point, I would imagine that someone is wondering what the hell is the Initialize button is actually doing. All it is doing is generating files that you will have to bring over into one, cohesive Analysis directory:

These files also sponsor the pooling of information from the ad-hoc result button clicks. For example final warehouse analysis provides the following information that gathers the required information from the aforementioned:

Once the data capture is initialized, a series of prompts will be visible while the SharePoint Kerberos Buddy is collecting information from both custom routines in itself as well as using a bunch of applications that are distributed natively with the OS and associated server platforms. This information is written to standard output for information purposes, however importantly is dumped into the Analysis directory located in the program installation folder.

These files are the information required for final analysis to occur, and why the Analyze button in the applications primary interface is not available until all requisite files are present.

The file types that are created are pretty standard, the important ones are built as custom file type *.sharepointkerberos. Complete analysis might not be required depending on whether the exact error is caught beforehand by examining the ad-hoc output from the tool, which may or may not point to your direct error, usually it won’t.

After the tool is run, the MSFT reference articles will be pooled and a list of the potential errors (both information, warnings and operation blocking errors) will be written out. These errors will have both a suggested resolution as well as the link to the MSDN/TechNet support site which verifies that this is indeed a practical action to take. I really wanted to make the hyperlinks clickable, but I forgot the whole time I was using a TextBox control instead of a RichTextBox, that will probably be the first thing I change around.

If you want to read more about why you are experiencing the error or the brief resolution path I am suggesting through the tool isn’t enough, just follow the MSDN link! The tool is available on the following CodePlex site: