AD FS: Answers to Your Comments and Questions

I’d like to start by apologizing to everyone for not responding more promptly to your comments on the Beginners Guide series. I won’t make any excuses, I’ve been just a little busy and it fell through the cracks.

That brings us to the point of todays article, my responses to your questions and comments. I thought it would be easier if I just answered them here in a single article for a couple of reasons. There were one or two questions that might spark some further discussion (which is always good in my opinion).

Before I jump into the questions I’ll take the time to thank everyone that made comments and asked questions for taking the time to do so. It’s rewarding to see people getting something useful from my efforts.

So, now the questions, comments and my responses.

Jacob commented: “I still don’t understand the benefits ADFS provides w.r.t. SSO, since every time the IE browser is re-initialized I get both an ADFS login window and then another windows login prompt. Where my hope was the user wouldn’t have to re-authenticate anytime after logging on once and the certificate was valid. I don’t see the benefits of ADFS yet.”

Me: Jacob what I would look at first off the top of my head would be the token timing. If that timing is off a little bit it’s possible that you will see frequent requests to authenticate. It’s actually common to see a situation when first configuring AD FS where the browser gets hung in an authentication request loop because the token times are off.

Aside from that there are other considerations I haven’t written about because they are probably more business decision focused than the technical stuff I normally tend to write. There are going to be situations where the implementation of AD FS is more of a requirement than a “This would be nice to have” kind of thing. Several examples of that:

  • If you’re going to publish your SharePoint web application externally using a reverse proxy you only have 4 choices of reverse proxy to use. Microsoft only supports Threat Management Gateway 2010 (TMG which has been discontinued), F5 Big-IP, Citrix Netscaler, and………………….?

    Windows Server 2012 R2 Web Application Proxy or WA-P which requires an AD FS instance internally on your network to work correctly (more on that sometime soon).

  • If you are going to do any kind of hybrid deployment you may find that implementing AD FS is easier, or more cost effective choice than trying to go another direction.

Soheil commented: “It would be nice if you could describe OAuth in plain language as well.”

Me: That’s a good and a fair point and it’s on that constantly adjusting list of planned projects. To be honest the more I dig into AD FS, Claims-based authentication, WA-P (which I haven’t even gotten to here yet), etc… the more I find there is to learn, read, research, record. So at this point it’s really hard to say if or when I’ll be able to get to it.

I’m going to post this article and then three more I’m planning on having done before SharePointalooza on September 18 – 20. I’ll be presenting an AD FS session there Saturday morning at 8:30. More on that coming soon. After that I have a couple of tests I have to take so I won’t be writing much in October and November in all likelihood.

After that a lot of what I’ll be writing will be dependent on what I’m actually doing at the time. I’m lucky enough to have a job that allows me the opportunity to do a lot of different things.

Anil247 asked: Why SharePoint needs to generate STS Token and is there any validation done against SAML token and STS token?

How is the user roll mapping done in this mechanism?

Me: I’ll probably come back at some point and talk about how roles can be used to manage access to specific content within SharePoint. The actual mapping of a role is done the same way you set any other claim type mapping, syntax is slightly different I would imagine.

The primary responsibility of the Security Token Service (STS) is to manage, issue and validate security tokens, if the STS is not functioning correctly then users will likely experience issues logging in.

Sahil Verma asked: I have two SP web applications which I need to put in Single Sign In mode using Claim Based Authentication with ADFS Issuer.

Issue is that these web applications are in production, up and running. Main Intranet web application has 100’s of site collections and complex permission management. Will an implementation like this effects the permissions over the site since the existing permissions are there with Users from default provider? Do I need to define the permissions again everywhere?

Me: Sahil I’d say that there’s a very real chance that inserting AD FS/Claims could impact your setup. First thing I would do before I would even consider making that leap is make sure I have some way to document all the configuration settings and permissions (down to the item level) in the farm AND present them to me, or my team in a manner that is fairly simple to understand.

Once you know you have a solidly documented configuration of the farm (and you really should have that anyway right?) I think you would need to plan out your authentication schema and do everything you can from changing it too drastically (i.e. going from logging in using sAMAccountName to using email address). My thought would be that

I’d also strongly recommend trying it in a test farm first, better to break the test farm trying something than the production farm right?

Richard commented: I am lost on the statements above. I don’t see how an identifier claim type is set in a Sharepoint Trusted Identity Provider, thus what I would specify differently if/when recreating it. I do see how email is used in the ADFS claim rules (# 4 specifically), but don’t understand what changing that would accomplish.

Me: Thanks Richard, I think what I meant there, and that apparently got missed when I proofed it, was the input claim type. Nice catch, thanks for pointing out and I’m glad you got some value from the series.

Krishna asked: In the step “Configure the S7Gear Relying Party Trust”, you have edited the Claim rules to add new rule. This will force the user to redirect to the S7LAB ADFS server for the authentication.

How could I continue to make sure that Internal users who are connecting via internet can use ADFS authentication or they would they just need to connect using Windows authentication and they would get the authentication popup since they are not connecting from internal network?

Me: Krishna, the way it would work in my mind is that internal users accessing the corporate SharePoint portal over the internet would have to access the portal after it’s been published through the firewall, preferably with a reverse proxy (see my comments to Jacob on which ones are supported by Microsoft) to add that additional layer of protection.

Internal users would be accessing over the local network and could be logged in using the currently logged in user settings of IE without being prompted for authentication at all.

Jaymz asked: One question, you said “For this lab I am passing through all claims although that might not be advisable in a production configuration”. Can you elaborate on why its not such a good idea and what you would do instead if you are constructing a production environment?

Me: it’s probably more personal paranoia than anything else Jaymz. I think it’s just a matter of time before we have a major SharePoint hack (I don’t really consider what Snowden did a hack as much as a rouge administrator run amok). I also think it would be dependent upon your environment, if you work in an industry or vertical that deals with sensitive or confidential information or is subject to some form of compliance (HIPPA, FERPA, SOX, etc…) there may be reason to limit, or monitor, what is being passed back and forth.

Of course I could just have an overactive imagination J

Coming Up

My next planned AD FS article will be around some of the troubleshooting tools I have found useful as I have been working through this process. I think most folks will find most of them useful for more than just troubleshooting authentication issues.

Again, to all of you that have read and commented my apologies for not replying sooner. Thanks for reading and enjoying!

Leave a Comment

Filed under Uncategorized

Oh, the Places I’m Going…

Nope, not going anywhere in THAT sense! That being said on Sept. 17, in the shameless pursuit of fame, fortune, stardom and perhaps even a free beer I will be loading up the truck and along with some of the Summit 7/Mindsharp team making my way to Branson, MO. to participate in what I consider the best SharePoint related conference at any price, SharePointalooza.

Mark Rackley and his team have assembled some 8 tracks, 32 speakers, 50+ sessions and workshops spread across two days of SharePointmania that anyone can benefit from. The speakers that you’ll have access to are coming from around the world and include some of the best and sharpest business and technology minds in the space.

All the SPEAKERS at this event are people that have faced, or are facing, the same challenges you do on a daily basis and are willing to share that knowledge with you for next to nothing!

Not to mention we’re talking about a weekend in Branson, MO in September here!

Let’s do the math, Branson 3 nights at $100 per night so $300.

Have to get there, if you’re close enough to drive gas is under $2 a gallon most places now or you can fly, either way figure $350. Don’t forget it could be tax deductible if the training you are attending is related to your job.

And of course the $50 registration fee, which if you watch the following video you can get 50% off of with the special, super secret code hidden in the video.

Figure less than $700 to get there, have a place to sleep (a critical thing in my experience) AND pick the brains of 30 of the best and brightest working with SharePoint compared to the $3,000 or so for that big conference last May. I’m pretty sure that not only will the conference content be at least comparable, if not far better, but the entertainment will rock as well!

Moving right along….

Now buried down there in that who’s who list of speakers that Mark has assembled for this “little” event is not so little old me J.

Saturday morning the 19th at 8:30 am (I must have made Mark mad J) I’ll be doing a session on Active Directory Federation Services (AD FS) and how it integrates into the SharePoint stack to provide authentication services for SharePoint. The goal of the session is to give attendees a solid understanding of what goes into the design and implementation of AD FS to support your SharePoint implementation so that when they leave they will have a better idea of what questions they should really be asking if the subject comes up in their office.

Aside from my session there are also sessions and workshops on Office 365, SharePoint development, Business Intelligence, Search, Administration, Social, Branding, Workflows and on and on.


As if that wasn’t enough there is live entertainment and plenty of opportunity to meet some of the speakers and sponsors in a social setting.

If you made plans but haven’t registered get off your rear end and REGISTER. If you’re still thinking about it decide and go ahead and make your Travel and Hotel Arrangements. If you haven’t thought about it then keep on not thinking about it and just DO IT!

If you’re going to be there please stop by the Summit 7 booth and introduce yourself to the members of the team that will be there.

Looking forward to a great event!

Leave a Comment

Filed under Uncategorized

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), and reverse proxies, those are effectively troubleshooting AD FS and authentication/authorization related issues (coming soon) and the main point of this article…….


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 everyones 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.



Leave a Comment

Filed under Uncategorized

Beginners Guide to AD FS 3.0, Claims-based Authentication and SharePoint 2013: Part IV – Troubleshooting

As you can well imagine I have seen more than a few error messages over the last few weeks as I have made this little journey of discovery. Now that we’ve gotten AD FS in place and working in our environment I thought you might find it helpful if I shared some of the issues I have seen to this point. Along the way I’ll also drop in a few tips here and there that helped me figure out a lot of the problems I was having. Based on researching the issues some of them seemed to be relatively common so you may have seen them before. Continue reading

Leave a Comment

Filed under AD FS, Authentication, SharePoint 2013

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part III: Configuring SharePoint 2013 for AD FS

This article is also available at Beginners Guide to Claims – Part III on the Summit 7 Systems website.

Well, we’ve installed and configured AD FS 3.0 and we have created the first relying party trust for our SharePoint 2013 farm. All that remains now is to complete the configuration of our new Trusted Identity Token Provider and configure SharePoint to use it which we will be doing in this article. Continue reading

Leave a Comment

Filed under AD FS, Authentication, SharePoint 2013

This Old Blog

Since I resurrected the site I have seen a number of instances where people are looking for some of my older blog posts around CSS and PII. I have found the posts (not sure how that happened but I did) and will be updating the links in the articles and reposting them over the next few days. Please note that I will be posting them in such a way that they appear to be posted before my latest AD FS articles.

If I happen to miss anything or a link doesn’t work please let me know and I’ll do my best to fix the problem as quickly as possible.

Thanks for reading…

Leave a Comment

Filed under Site News

Beginners Guide to Claims-based Authentication, AD FS 3.0 and SharePoint 2013: Part V – Authentication Across Multiple Forests

I’m not sure if this is really a beginners article but what the heck, we’re on a roll here and having fun and I’m writing so I get to say what it is and isn’t (at least to a certain extent anyway).

If you’ve been following along and have read through the first 4 articles in this series you know we have installed and configured AD FS 3.0 in our S7Gear domain and that at this point users in the S7Gear domain can log into SharePoint using SAML claims, definitely not a complicated configuration.

To refresh your memory the claims authentication process is 7 steps as shown below.

  1. The end user hits the SharePoint site generating an HTTP (GET) request.
  2. SharePoint redirects the user to the Identity Provider to get a security token.
  3. The end user is prompted for credentials by the Identity Provider.
  4. The Identity Provider validates the provided credentials with the authentication provider (in this case AD DS) and if successful provides the client a security token.
  5. The Identity Provider sends the end user a SAML security token.
  6. The end user submits a new request to SharePoint with the SAML token.
  7. The SharePoint STS generates the SharePoint security token, the FedAuth cookie and the requested SharePoint site.

This scenario works great for my internal (S7Gear) domain users but what if I have an organization I want to partner with on a project? How easy would it be to allow those users to log into my SharePoint farm using their own (current organizations) credentials?

It actually turned out to be a lot easier than I thought now that I actually have a clue about how to set up AD FS to authenticate my SharePoint users. The goal in this article will be to take our existing SharePoint farm in the S7Gear domain and make it accessible to users in the S7Lab domain. To do this I have had to make some networking changes on my VMWare setup which I will explain briefly.

I use VMWare Workstation 10 for the labs I build on my laptop (generally labs for my blog posts). For this series of blog posts I started with the S7Gear domain shown below (this is a very simplistic view I suppose but you get the idea).

For the purposes of this article we’ll add a second domain named on the network (isn’t a real test if they’re on the same network now is it?). In order for the two networks to “talk” to each other I had to add a second NIC to each server in both forests. Once the second NIC was added I configured them with static IP addresses, one NIC on each network (192.168.239.x and 192.168.126.x). To work around having to set up DNS in each domain I’ve made HOST file entries for and on the ADFS server in the S7Lab domain (9 VMs is kind of pushing it so I used the AD FS server in to access the S7Gear SharePoint site).

For this lab to work I have created and configured an AD FS server in the S7Lab domain to facilitate communications between forests. More on that in a bit…

When I finished the network configuration it looks more like the following. As you can see each server has two network connections and I have verified that I can ping servers and addresses across the connections.

NOTE: I could have set up a RRAS (Routing and Remote Access) server but there have been some changes in that with 2012 R2 and I didn’t feel like digging into it just yet.

Now that we’ve gotten this all out of the way we can get to the fun stuff which as I mentioned before was really far easier than I thought it was.

The authentication concept working across multiple forests or domains is essentially the same with one or two additional steps. Our S7 Lab user is going to access the S7Gear SharePoint site from his, or her, desktop in the S7Lab domain and select which trusted identity provider they want to authenticate with. They will be prompted for credentials and if they have access to the SharePoint site being requested they will authorized and allowed access.

Before our users in the S7Lab domain can do that we have to establish a line of communications between the two forests. We’ll do that by taking the following steps on the AD FS server in the S7Gear domain (where my SharePoint farm resides):

  • We will add the * self-signed certificate to the trusted root store on the AD FS server in the S7Gear domain. If you fail to do this you will not be able to update, or validate, the claim provider’s federation metadata URL.
  • We will add a claim provider trust (similar to a relying party trust).
  • We will import information about our relying claim provider.
  • We will create a rule for each claim being presented by the claim provider to allow them to pass to SharePoint.
  • We will add pass through claims rules to our existing SharePoint relying party trust.

Once we have completed those actions on the S7Gear AD FS server we will take the following actions on the S7Lab AD FS server.

  • We will add a relying party trust.
  • We will import information about the claims provider.
  • We will add rules to send LDAP attributes as claims.

Before any of that can happen we need to verify that AD FS is configured and accessible in both forests. I’m going to step through it once because some of the steps here are also very good for troubleshooting problems when you have them later.

To verify that the AD FS service is operational we’ll open the federationmetadata.xml on the S7Lab AD FS server which in this case is the “Identity Provider”. The default location of the file on the server is

NOTE: You will notice that I didn’t use the server name in the AD FS service URL, I’m not a big fan of server names in URLs so I created a DNS “A” record pointing at the IP address of the AD FS server.

Copying and pasting that URL into the address bar of a browser on the S7Lab AD FS server should take you to the federation metadata XML page with no errors. If you get an untrusted certificate warning error you need to make sure that you have added the token-signing and decrypting certificate(s) to the trusted root certificate store of the server. Certificate errors may cause authentication attempts to fail.

Repeat this process on the on the S7Gear AD FS server using as the root of that URL. Once this is complete we will start the configuration process.

Import the SSL certificate into the Trusted Root Certificate store

I’m not going to walk through all the steps to put the SSL certificate in the trusted root certificate store. If you need guidance on how to do this you can see the instructions HERE.

Create the Claim Provider Trust

We will start the configuration on the S7Gear AD FS server, opening the AD FS Management console and in the left hand window expanding the Trust Relationships heading and selecting “Claims Provider Trust”.


Right click and select “Add Claims Provider Trust” to start the Add Claims Provider Trust wizard. We’ll click through the welcome panel to the Select Data Source panel and on that panel we will select the “Import data about the claims provider published online or on a local network”. In the text field we will past the URL of the federation metadata XML file on the S7Lab AD FS server as show below. This how the Claim Provider Trust will import data about the S7Lab AD FS configuration.


Click “Next” to continue and if everything is able to communicate with each other the wizard should advance to the next panel showing you the root URL of your federation metadata XML file as shown in the following screenshot. I’m going to change that display name to S7 Lab AD FS Login and then click “Next” to continue.


At this point we should get the Ready to Add Trust panel, I would suggest that you take a look through the settings in each of the tabs on this panel until you are familiar with the process. It’s good to know what it looks like by default when you’re desperately searching for the solution to a problem you’re having.


We’ll click “next” and “finish” to complete the wizard and open the “Edit Claims Rules” dialog box. Here we are going to add our rules to pass our incoming claims to the S7Gear domain AD FS instance.

Now we are going to create our pass through claims rules. If you think back to when we created the claims rules for our relying party trust back in Part IV, we used the “Send LDAP Attributes as Claims” claim rule template. This time we are going to use the “Pass through or filter and incoming claim”, this rule will tell the AD FS service to pass incoming claims that match the rule to SharePoint.

Remember, we must create a rule for EACH incoming claim we expect to accept. For this lab we will create rules to pass the UPN and Common Name claims.

On the “Choose Claim Rule” panel we will give our rule a name and then define the incoming claim type.

I want to stop for a second and point a couple of things out here before we go on, notice that we have several options regarding how we want to handle, or filter those incoming claims. We can pass through all claims, pass through only claims with a specific value, pass through claims that match a specific email suffix and pass through claims that start with a specific value. For this lab I am passing through all claims although that might not be advisable in a production configuration.

Now that our two claims rules have been created we will close the dialog box and continue.

Configure the S7Gear Relying Party Trust

Now that we have rules in place defining how the S7Gear AD FS server will handle incoming claims we will make some minor configuration changes to our existing relying party trusts for our SharePoint farm. Not only do we have to tell AD FS that there is an organization we trust and that they are going to be sending us some claims but we have to tell SharePoint how to handle them as well.

We’re going to do that by adding an additional rules for each incoming claim to our relying party trust on the S7Gear AD FS server. We’ll select the relying party trust in the AD FS Management console and then click the “Edit Claims Rules” link to add our new rules. On the “Issuance Transform Rules” tab click the “Add Rule” button to open the Add Transform Claim Rule wizard.

We are going to use the Pass Through or Filter an Incoming Claim rule template and create a rule to match each rule created for our Claims Provider Trust.

Now, just like with the Claims Provider Trust rules we will create a rule to pass through the UPN claim and common name claims.

Once those are done the Edit Claim Rules for “Portal” (my SharePoint Relying Party Trust) will look like the following:

Configuring the S7Lab AD FS Server

Now we’ll move on to the last part of the process and configure the AD FS instance on S7Lab to tell S7Gear what claims we are sending. We will do that by creating a relying party trust in AD FS on S7Lab but we are going to do it slightly differently than we have previously.

We’ll start the process by opening the AD FS Management Console and expanding the Relying Party Trusts node. Right click on Relying Party Trusts and select the Add relying party trust wizard, clicking through the Welcome panel to arrive at the “Select Data Source” panel (look familiar?).

This time we are going to enter the URL of the S7Gear federation metadata address,

We’ll click “Next” and then give our new Relying Party Trust a name before skipping the Configure Multi-factor Authentication panel and taking the default setting on the Choose Issuance Authorization Rules panel. At this point we can click finish to complete adding the trust.


At this point all of our configuration steps are complete, we should be able to open Internet Explorer on the S7Lab AD FS server and access the S7Gear SharePoint Farm. Let’s see how it works. We’ll enter the URL in our browser address bar and get the default sign in page.

I’ll click the drop down menu and select the SAML for SharePoint trusted identity provider.


Now that I have selected the trusted identity provider I am prompted for authentication, make sure you look at the URL displayed in the login prompt.

I’ll enter my administrator account credentials as shown in the following screenshot and hit enter to continue.

If you watch the address bar closely after you click the Ok button you’ll see it hit the S7Lab AD FS service first.


If that connection is successful and tokens are created and passed you should see the S7Gear AD FS service come up in the address bar first.


Next we’ll see AD FS being queried for the Portal realm.

If SharePoint authorizes my user the next thing I should see is the S7 Gear Portal home page.

If you look in the upper right hand corner you’ll see that you are logged in as


And that is all there is to it, I now have users in two forests that can log into the S7Gear SharePoint farm and do their thing.

This post concludes this series of Beginners type articles. I will be posting more AD FS related content over the next few weeks as I dig deeper into the stack.

I hope everyone has found these articles informative and helpful. As always please leave your comments in the comments section and THANKS for reading…


Leave a Comment

Filed under AD FS, Authentication, SharePoint 2013

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In my last post we took a high level view of the various authentication processes and how they work. In this post we’ll take the next step in our discussion of claims-based authentication and talk about Active Directory Federation Services or AD FS, version 3.0.

Previously we talked about the concept of an Identity Provider as a component of claims, AD FS is the Windows Identity Provider and provides the Security Token Service (STS) that creates and issues SAML tokens to authenticated users. Continue reading

Leave a Comment

Filed under AD FS, Authentication, SharePoint 2013

Claims-based Authentication, ADFS 3.0, and SharePoint 2013 – Beginners Guide

I should know what claims authentication is and how it works inside and out, up ways and down, backwards and forwards. I should…………………but I’m ashamed to admit that until about 18 months ago I could talk my way through it, I knew “kind of” how it all worked and I could make it all work together but I didn’t really understand the under the hood of how it all works together as much as I probably should have.

With that in mind, along with some project related pressure, I set out to truly understand how claims-based authentication really works under the hood and why it’s a key to SharePoint.

Why a written recap of the journey? Well for one I don’t want to forget and I think it’s always a good idea to have your experiences and lessons learned backed up somewhere. The second, and probably more important reason, is to hopefully help someone that is struggling with the concept of claims-based authentication, especially in relation to SharePoint and might be fighting through some of the same issues I am. Continue reading

Leave a Comment

Filed under AD FS, Authentication, SharePoint 2013

SharePoint and Personally Identifiable Information (PII) – Part II

Several months ago I wrote an article on SharePoint, Data Security and Personally Identifiable Information that talked about PII and Data Security and why it is important that you be aware of these things as a SharePoint Administrator. In this article I have taken a bit deeper dive specifically into the realm of PII since it is my belief that this area will become more and more of issue as aspects of SharePoint 2010 are implemented. This will be especially true in the area of compliance and I think it will become more evident as the efforts to put better laws in place to protect our personal privacy are put in place at a federal level. Continue reading

Leave a Comment

Filed under PII, Privacy, Security