Summit 7 Team Blogs

Beginners Guide to Claims-based Authentication, AD FS and SharePoint 2013: Part VI – What I wish I had known then that I know now or Hindsight is 20/20…

If you've been following along with the other articles in the series you know that the focus has been on getting Windows Server 2012 R2 AD FS, SharePoint 2013 and claims-based authentication to play together nicely. With a few exceptions that I documented along the way it really wasn't rocket science and everything worked with a little bit of effort and research.
Then the real world interrupted and I now have a much better appreciation for two aspects of identity management, authentication/authorization, AD FS, and WA-P (we haven't gotten to that but we will), reverse proxies, effective troubleshooting (coming soon) and the main point of this article…


Speaking of planning...

Before we begin, want to read the full series from the beginning?

Part 1: The Beginning
Part 2: Installing and Configuring AD FS 3.0
Part 3: Configuring SharePoint 2013 for AD FS
Part 4: Troubleshooting
Part 5: Authentication Across Multiple Forests


Over the last several weeks it has become painfully obvious to me that one major point I hadn't thought about or given any real consideration to, was just how critical detailed planning is to the success of this type of implementation. While I am not going to give you a checklist of things you need to do as a part of the planning and design process (at least not yet anyway) I am going to provide you with some things to think about based on a recent project I was involved in.

Before you start planning, before you start designing, before you start implementing, before you do ANYTHING AT ALL do yourself, and your team, a huge favor and ask yourself the following question.

"Is there truly a need to implement, or integrate, any kind of identity federation or web single sign-on (SSO) architecture within the enterprise?"

If the answer to the above question is no, and it could very well be, then you can go back to your happy world of until the next time the subject comes up. If the answer is yes then you have some homework to do before you start your requirements gathering much less any kind of planning, design or implementation.

Also, notice that my question above was directed at the enterprise and not directly at SharePoint. The implementation of an identity or web SSO architecture could very likely impact a wide variety of applications hosted or managed by organization besides SharePoint. In a large enterprise there is a good chance that SharePoint would be sharing an identity management solution with other applications the organizations has.

Because of that it's important that Enterprise IT and your Governance Board be intimately involved in the research and planning stages of the project from the very beginning. There are more than a few security and configuration decisions that will be made that should align with any established corporate policies (If you don't have any established corporate policies then this might be a good time to think about taking care of that don't you think?)

When you take your case to Enterprise IT and Governance be prepared to ASK and ANSWER a lot of questions. The most critical part of the interaction between you, Enterprise IT and your Governance Board is the ability to communicate clearly and concisely exactly what it is you need from them as well as respond in the same way to what they need from you.

In plain English you all have to be speaking the same language. I know that sounds stupid but I assure you that it isn't as far-fetched as you might think. I'll give you an example….

When you're working with the administrator of a 3rd party IdP they might ask you what "Assertion Attributes" is your application expecting? If you don't have a lot of experience with identity or SAML 2.0 in general you might not know that they are referring to a "Claims Type".

One key takeaway is that if you don't understand something, or something isn't crystal clear at some level, stop and ask for clarification. This is the type of design and implementation that can have far reaching implications if you screw up somewhere along the line.

Now, back to what Enterprise IT and Governance are going to ask you. The very first question you can expect is "What's your business justification for your request to allow access to <insert application name here> from outside the corporate network or via the internet without using a VPN connection?"

The simple answer for most organizations, is "I need to allow an employee of a partner/vendor/contractor/etc.. access to all, or a portion, of our SharePoint environment".

That said there are other reasons to implement an identity management or web SSO system, or components of those systems where appropriate but I digress.

Once you've addressed question #1 above you can expect a LOT of follow up questions.

  • What is the source of this requirement?
  • Who are we planning on giving access to our SharePoint farm?
  • What do we have to do in order to keep our SharePoint farm secure and still meet the requirement?
  • Where are we going to do this, on-premises or in the cloud?
  • How are we going to do this and keep from having to manage a bunch of accounts for people that don't work here?
  • What is the security impact of opening up authentication to your SharePoint farm to external partners?
  • What will the criteria to get access to your SharePoint farm be?
  • How will end users authenticate? Username\password, smart card, email address\password?
  • Will we be leveraging a non-Microsoft product as an IdP? Siteminder, OpenID, Ping Federate, etc…
  • If we are federating identities with another organization what claims are they passing to us? Do those claims meet our requirements for authentication?
  • Are there any Active Directory account attributes we need to pass into the SharePoint 2013 User Profile Service?
  • Do you know, or have, the unique identifier that is, or can be, bound to each external user account?
  • Will you need multiple zones in SharePoint to accommodate internal and external users as well as some SharePoint functionality that requires the DEFAULT zone be configured to use Windows Authentication? Search immediately comes to mind for example…
  • What URLs do you plan to use if you decide to implement multiple zones?
  • What is the expected end user experience?


Be prepared to answer these questions and very likely a lot more like them. If you can review any existing company policies that might impact what you're trying to do it is a good idea to review those ahead of time so you know how they may impact your planning and design.

Those questions from the list above that you don't get from Enterprise IT or Governance you should probably be asking yourself. There is a very good chance that they'll come up again as your project progresses.

Equally as important in being well prepared with your answers to those questions is the need to have as many of the questions that YOU are likely going to need answers to ready to present to Enterprise IT and your governance board.

Some of the questions you might ask of Enterprise IT and your Governance Board.

  • Do we currently have any kind of web SSO or identity management architecture in place
    • Don't dismiss this point, in very large enterprises it's not outside the realm of possibility for a group to not know what services are available from Enterprise IT or allowed by governance or corporate policy?
  • Do we have reverse proxy capabilities?
    • VERY IMPORTANT NOTE: in Hybrid deployments of SharePoint and Office 365 Microsoft only supports 4 reverse proxy devices and one of those (Threat Management Gateway 2019) has been discontinued.
      • Windows Server 2012 R2 w Web Application Proxy (WA-P)
      • Forefront Threat Management Gateway (TMG) 2010 (discontinued but existing implementations will be supported until 4/014/2020)
      • F5 BIG-IP
      • Citrix NetScaler
    • The decision to publish SharePoint through the firewall and externally to the world brings with it the requirement to do so securely. Following best practices this would be done by "publishing" SharePoint through a reverse proxy that acts as a buffer between the application and the internet (that's a really high level definition of what a reverse proxy is but you get the gist for now).
  • If we have a reverse proxy is it in an edge or isolated network?
  • If we have an edge or isolated network does that network have an Active Directory domain associated with it?
  • What policies are in place around external user access to internal resources?
  • What policies are in place around using cloud based resources as a part of an identity management solution?
  • What are the corporate or governance policies around account management?
    • Disabled after x number of days inactive?
    • Password complexity?
    • Username format?
    • Password expiration?


You'll probably have the answers to a number of those questions, and some others that will inevitably pop up, but you won't know them all. This is where it is critical that you work closely with your Enterprise IT and governance teams. The only way you are going to get the answers to these questions, and the many, many more you'll come up with of your own is to open your mouth and ask them.

As a part of your learning process and homework I would highly recommend reading the following article(s) by Dave Gregory at Microsoft. It provides an excellent overview of some of the questions you should ask as part of the requirements interview process. The series as well as this particular article are really, really well done in my opinion.

ADFS Deep Dive: Planning and Design Considerations

That's quite a bit to digest but we aren't done yet. The decision to allow external access to your SharePoint farm also has a direct impact on the configuration of your farm that will have to be addressed. The following is a very brief list of areas that you will have to address if you decide to leverage AD FS and a claims based authentication solution for authentication/authorization within your organization.

  • Web Applications: As you'll see because of SharePoint search service requirement you'll need to carefully consider web app zone and URL planning during the design phase.
  • Search: The SharePoint search service requires that the default zone of the web application be configured to use Integrated Windows Authentication (IWA).
    • The default zone of the web application could have multiple authentication providers associated with it but that raises some end user experience issues that would have to be addressed.
  • End User Experience: When end users attempt to access the SharePoint farm they will be expected to select the correct authentication provider and then enter their credentials.
  • People-picker: The people picker will resolve any value entered into the text box when adding users to SharePoint.
  • User Profile Service: You may need to map additional properties to your user profile service to support the implementation of an IdP. This is especially true when using SAML claims, you must map the SP-ClaimID to the appropriate identity attribute being passed by the IdP.


I think that with those points I'll end this article. Next time I'll be back with an article answering all the questions that have been asked through the first 5 articles. I apologize for not answering them earlier, they just slipped through the cracks.

Once we answer everyone's questions we'll close this series but continue to dive deeper into identity management, SharePoint, AD FS, WA-P Web Application Proxy remember?), troubleshooting (this will be a couple of articles probably, I've learned a lot here recently) and many, many other topics.

As always, thanks for reading and please don't hesitate to ask any questions you may have.

About Jay Simcox

Jay Simcox is a respected IT Professional, and educator with 10 years of Information Technology experience. Jay is a Senior Consultant with Summit 7 Systems where his background in network and systems administration, SharePoint architecture and Administration and end user support and training are utilized by government agencies seeking to make better use of the tools they are provided.