SharePoint Kerberos Buddy Update – Release Created On CodePlex

Whoops. Sorry folks! I had just uploaded the .MSI and related setup files to the CodePlex site source control. I forgot to created a release with them which made it a pain to download. I should probably zip up the files so it’s one download but the MSI and setup.exe are now sorta easily available.


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:


The Basics of Claims – Part 4 – SharePoint Authentication Logic is Simplified with Claims

There is logic found inside of any application out there which supports the various features that it offers. However, applications aren’t always able to successfully rely upon the Windows authentication to help it with the process. You may have web based application that store the names and passwords of users. They may need to be reset when lockouts occur or there is a breach in the system. With enterprise facing applications, there is a domain controller in place that Windows will use to authenticate.

There are plenty of challenges that can occur though in spite of the presence of integrated authentication though. Kerberos tickets are able to give you a list of groups and user accounts. What are you going to do though if you have a need to send an email to them through your application? As you can see, that would become complex in nature to achieve even when you are only working within the framework of a single domain.

While Kerberos does have limitations, you can get around them when you program the Active Directory. This is a complex process though so be ready. Your goal should be to have a very efficient LDAP (Lightweight Directory Access Protocol). This way the queries made aren’t going to slow down your directory server.

You will find that with claims based identity you are able eliminate the authentication logic when you are talking about individual applications. What will happen is that there is an application that verifies the user through the claims process. Therefore, claims is a way for your to get rid of authentication logic in terms of your application.

Don’t let the concept of claims based identity intimidate you because it is used all the time and it is everywhere in society. Let’s take the authentication protocol that is in place at the airport as an example. You aren’t able to just go to a gate to board a plane with your photo ID in hand. You have to go through a process that requires you to check in at the right ticket counter location prior to proceeding to the boarding gate. You will be asked for various information at that time including your name and photo ID.

For those passengers with a flight that takes them out of the country, a passport will be required. All of this pertains to adults traveling but not to minors with them. The only thing you will need to provide for children is their names and so that becomes their authentication. The person behind the ticket counter will also make sure there isn’t any problems with the payment that was processed to pay for the flights. Once all that is done boarding passes are issued and then you can head to the gate for your plane.

All of the information you need to get onto the plane is offered on that boarding pass. The agent at the gate will look at your name and they can even see if you are a frequent flyer member. They will also see your flight number and your seating location. There can be additional information too depending on the specific airline you happen to be flying with. Everything on a given boarding pass allows the process to be a smooth one for customers as well as staff.

If you take a closer look at any airport boarding pass, you will also notice that there is a bar code on it. Some of them have a magnetic strip in lieu of it. There is plenty of information encrypted into those areas too. For example the boarding serial number that shows it to be legitimate as there are ways to make fake boarding passes out there.

All of the information on a given boarding pass is a set of claims that the airline has for identifying you. It verifies that you are authorized to be getting onto a given airplane and assigned a particular seat on it. The agents that are at the gate are going to view your boarding pass, they don’t have to ask you for all the same information that you already gave when you first checked in.

Another scenario though is that you may be able to get the validation you need from another source. For example many airlines now make it convenient to get your boarding pass online and then you can bypass the ticket counter when you arrive at the airport. Which method you used to create your boarding pass won’t alter the end result that it allows you to get on your flight as specified. This is because the claims linked to it have been authenticated.

When it comes to software, the claims involved are referred to as the security tokens. Each one is to be signed by a particular issuer that has created it. In a claims based application, the users are authenticated when they are able to present a signed security token that has been validated by a trusted issuer.

When you are talking about an application developer, they have an advantage with this type of system. You see the application won’t need to have a specific type of credential involved from the user. Of course the person in charge of security for your company is going to create policies and rules that will be evaluated by the user. What your application receives is very similar to the boarding pass information I just shared with you.

What all this means is that regardless of the authentication protocol that is used the application is going to get a set of signed claims. These claims will have the pertinent information on them about the user. This information is in a format that is simplistic in nature and the application will be able to use it immediately.