ADFS Deep Dive: Planning and Design Considerations

 

In the previous blog post on comparing sign-in protocols, the goal was to give you a primer on the terminology so when we start talking about WS-FED or SAML, you have an idea of what we’re talking about. If you haven’t read it yet, it’s available here:

https://blogs.technet.com/b/askpfeplat/archive/2014/11/03/adfs-deep-dive-comparing-ws-fed-saml-and-oauth-protocols.aspx

In this blog, we’re going to act as though we are the Identity Architects interviewing the CTO of Fabrikam. I think doing it this way will provide a better context for the material.

The typical request comes in something like this , “We want our users to login to some application with their same username and password without being prompted again for credentials”.

While knowing this is important, it’s what they didn’t say is almost more important. What they don’t tell you is that while you are planning the ADFS deployment, each business unit in the company is secretly planning how they want to federate with some cloud SaaS provider and just when you think your work is done, they come crawling out of the woodwork and pile on more requests and requirements for the project. Knowing this, don’t build ADFS for the now, build it for the future, ensuring it can scale with the customers needs. I promise that you’ll thank me.

The one thing I’ve learned from all my ADFS deployment experience and similar to most other projects is that they’re 90% planning and 10% implementation. If you can ask the right questions up front and set expectations of the things you’ll need, these deployments are typically pretty smooth. So what questions should we be asking to ensure we design an appropriate identity strategy for Fabrikam and something that can grow with them and continue to fulfill their needs.

 

What questions should we be asking?

Questions to determine whether federation is a good fit?

1. Why are the goals we’re trying to accomplish?
2. Is the application/service claims-aware and does it support WS-Fed, SAML, or OAuth2?

Interview questions during any federation project?

1. What applications will users be using to gain access this application/service? Their browser, Outlook, Lync, custom software, etc?
2. What types of devices will be used to access this application/service?
3. Do you want to perform device registration (DRS) of these devices so you can also perform device authentication for applications and/or services?
4. Who are the users that need to access this application/service?
5. What’s the company’s policy on using internally-issued certificates or wildcard certificates?
6. Where will these users be physically located on the network when accessing this application/service?
7. How many users will need to access this application/service?
8. Are there any other SSO projects occurring within the company that we should be aware of?
9. Do you have any other production Active Directory forests? Will all forests be expected to leverage the same O365 tenant?
10. Do you have any other identity platforms already in the company that we will expect to integrate with like Ping, Siteminder, etc?
11. Will any users require multi-factor authentication (MFA)?
12. Will any of these applications require special authentication types?
13. Do you have any special industry standards you need to comply with?
14. Do you need high-availability of the ADFS service and backend SQL servers?
15. Do you have a DR site and plan to keep part of this ADFS infrastructure in this DR site?
16. Do you have a consistent UPN across the enterprise? If not, how many?
17. Do you have any non-routable UPN’s in the enterprise?
18. If you had to, would you be willing to change your UPN to support these projects?
19. Do you have any other data or attribute stores besides Active Directory that we may need to pull user attributes from?
20. Related to this project, do you have any applications that users will need access that aren’t claims-aware?

Here's a link where you can download these questions: https://onedrive.live.com/redir?resid=95EF7CF67771C364%2138461

 

ADFS Case Study

Let’s go through these questions, talk about why they are important, and then come up with a design based on the requirements we were given.

You are an Identity Architect and the CTO of Fabrikam brought you in to ask chat about their identity strategy:

You: Why are the goals we’re trying to accomplish?

CTO: We want our users to login into applications with their same username and password that is being stored in Active Directory without being prompted for credentials again.

You: Ok, that’s vague but is this application/service claims-aware?

CTO: No, we have lot of legacy mainframe applications and we were hoping that ADFS could somehow sync usernames and passwords to the back-end database of these applications.

Shoot them down immediately – No, ADFS can’t do this type of syncing and this is the wrong type of application for ADFS. I bring this up because a customer actually asked me whether ADFS could do this sort of thing. First off, this isn’t true Single Sign-On but is rather Same Sign-On. This would require Forefront Identity Manager (FIM) or some custom integration code to keep Active Directory and these application in sync. Many customers think ADFS is some magic bullet for authentication. At this point, you may even have to really explain to them what claims-aware means because sometimes they think they do but they really don’t. I wouldn’t go into much detail comparing sign-in protocols like my last blog but explain to them that the application has to support SAML 1.1 or SAML 2.0 to be used with ADFS.

Two weeks later, the CTO calls you into the office and says:

“Hey, we have two big initiatives coming up that we think will save us a ton of money. We want to start using O365 for email and Lync and also start using ServiceNow for our service desk ticketing system.” Do you think ADFS can help out?

He’s a smart guy so he already answered the first question from above. From past projects, you already know that O365 and ServiceNow are claims-aware. Now that ADFS fulfills these two requirements, you can move on to the more detailed questions, which will help you drive the overall design:

 

Interview with CTO

1.) You: What applications will users be using to gain access these applications/services? Their internet browser, Outlook, Lync, custom software, etc?

CTO: The helpdesk will access ServiceNow via their web browser. For O365, users could be using OWA, the Outlook or Lync thick-client on their PC’s. On their mobile devices, it could be Exchange Active Sync (EAS), or Office mobile apps.

What is this important: With the out of the box (OOB) configuration of ADFS, ServiceNow access via their browser won’t be a problem. Using Outlook thick-client, EAS, always require an ADFS WAP/proxy. Lync while outside the corporate network will also require an ADFS WAP/Proxy. This is because Outlook/EAS isn’t claims-aware and will just send your basic credentials to O365. O365 will then take those credentials and post them to your ADFS WAP/proxy to get a token on the user’s behalf. For a refresher on why, see:

https://blogs.technet.com/b/askpfeplat/archive/2014/08/25/adfs-deep-dive.aspx

Key Takeaway: Using Outlook or EAS  will require an ADFS WAP/Proxy. Lync while outside the corporate network will also require an ADFS WAP/Proxy.

 

2.) You: What types of devices will be used to access this application/service?

CTO: Mostly Windows PC’s but our Marketing department uses Mac’s. We also have a BYOD policy for mobile devices so we’ll have a combination of IOS, Android, and Windows phone devices.

What is this important: Mac’s, IOS, and Android devices aren’t typically domain-joined so we may have to ensure they receive forms-based authentication when inside the corporate network. This ADFS behavior is driven by the browser’s User Agent String so we’ll have to configure ADFS to respond to the various UA Strings accordingly.

https://technet.microsoft.com/en-us/library/dn727110.aspx

Key Takeaway: Heterogeneous environments have various browsers, which we will have to accommodate.

 

3.) You: Do you want to perform device registration (DRS) of these devices so you can also perform device authentication for these applications/services? You may have to explain what DRS is.

CTO: Yes

What is this important: While knowing whether they want to leverage DRS, it has much bigger ramifications to the ADFS service name and SSL certificates that we’ll need to get for this project. When a client performs DRS, they will have to type in their UPN. If their UPN matches their email address, they can also type in their email but the DRS client on Windows will try to resolve the WAP/Proxy based on the UPN the user typed in. For example, if a user types in sallie@fabrikam.com, the DRS client will try to resolve enterpriseregistration.fabrikam.com for device registration to complete.

https://technet.microsoft.com/en-us/library/dn614658.aspx

Key Takeaway: This is a really important question because if they want DRS and you don’t plan for this upfront, you have a lot of work of redoing the setup and configuration of ADFS.

 

4.) You: Who are the users that need to access these applications/services?

CTO: Only corporate users will need to access O365 and ServiceNow.

Why is this important? You’ve worked on ADFS projects long enough and you know better. Once all this ADFS magic is setup, eventually, they’ll want partners to access some new claims-based application.

Key Takeaway: Since we’ll have various non-domain joined clients and probably partner access scenarios down the road, you will should definitely recommend publically-trusted SSL certificates across the board.

 

5.) You: What’s the company’s policy on using internally-issued certificates and/or wildcard certificates?

CTO: We’re ok with using internally-issued certificates and try not to use wildcard certificates.

What is this important: While they could use internal certificates on their internal ADFS servers, you know that eventually contractors or external partners may try to use the internal ADFS servers so we’re still going to recommend a publicly trusted SSL certificate across all ADFS servers. Since the WAP/Proxy servers are in the DMZ and service edge requests, I typically recommend a separate set of SSL certificates for them. Same name but different certificate and thumbprint.

Key Takeaway: If any external partners or users will every use this ADFS infrastructure, you’ll definitely want the customer to use publically issued SSL certificates. Wildcard certificates are supported though. I try to encourage customers to use separate SSL certificates on their WAP/Proxy servers.

 

6.) You: Where will these user be located when accessing these applications/services?

CTO: Users will only be inside the corporate network.

You: Once again, you know better. Users are expecting email when outside the corporate firewall, so you ask for more detail by saying, “Do you want any policies about who is able to use these applications while outside the firewall?”

CTO: Yeah, we should plan to have access policies around who can access these applications outside our network.

You: Is the fabrikam.com DNS namespace published to the internet.

CTO: Yes

Why is this important?   Once again, this is leading us down the same path of requiring ADFS WAP/Proxy servers and we’ll need to configure some access policies to control who has access to these application when outside the corporate network. Additionally, if this infrastructure is going to be publically published, the DNS name we assign to the SSL certificate must be publically available. Fortunately, Fabrikam.com is published to the internet.

Key Takeaway: We will definitely need ADFS WAP/Proxy servers and the ADFS service name will need to be publically available via DNS.

 

7.) You: How many users will be accessing this application/service?

CTO: We only have about 25,000 active users and all of them will be using O365 in some capacity.

You: Follow-up with another question – Do you have any acquisitions or projects that might change these numbers?

CTO: Yeah, we have an acquisition happening in just a few months that would increase our head count to 55,000 active users of O365.

What is this important: We want to ensure our ADFS server farm can handle these 55,000 users. See our ADFS sizing calculator below in the build document. Azure AD Sync only requires SQL if more than 100k users so we should be able to go with the built-in SQL express.

Key Takeaway: Try to encourage the customer to build for the future because requests for federated identity and the cloud are only going to increase. They should pay for scale in advance.

 

8.) You: Are there any other SSO projects occurring within the company that we should be aware of?

CTO: Yeah, I think our European division might already have an O365 tenant stood up. I don’t know whether they’ve connected our corporate network to the tenant yet.

Why is this important: This means that the European division might have already registered the Fabrikam.com domain name in that other O365 tenant. This would prohibit this project  from registering the fabrikam.com domain in this O365 tenant. Make them aware that a domain can only be registered once in O365 and they should work to get everyone in the company on the same page.

Key Takeaway: Verify whether someone else inside the company already has an O365 tenant and how far along they are in the project. Confirm they haven’t already federated the company domain name with Azure. Also confirm the DNS name that you choose for the ADFS service name is actually available and not in use by another website in the company. I had a customer go and get SSL certificates for sts.domain.com to find out another website in the company already used the sts.domain.com DNS name.

 

9.) You: Do you have any other production Active Directory forests?

CTO: Yes, we have another forest Contoso.com but for the time being, we plan to keep them as a separate forest and will consider consolidation at some point down the road. For the time being, we will create a two-way forest trust between their AD forest and ours.

You: Will both forests be expected to leverage the same O365 tenant?

CTO: Yes, to facilitate collaboration, we want users from both forests to leverage the same O365 tenant.

Why is this important: One ADFS infrastructure in the Fabrikam.com forest can service O365 requests for both forests as long as there is a trust between the two forests. If there is no trust between the forests, SSO to one O365 tenant will not be possible.

Key Takeaway: Understand the ramifications of multi-forest with ADFS and requirements including trust types, directions, UPN uniqueness, -supportmultipledomain switch in O365 PowerShell, and Dirsync requirements. They’ll need either Forefront Identity Manager (FIM) or our new Azure AD Sync so you can sync both forests to one O365 tenant.

 

10.) You: do you have any other identity platforms already in the company that we will expect to integrate with like Ping, Siteminder, etc?

CTO: Yes, we use Siteminder for some small identity projects.

You: How many users are currently using SiteMinder

CTO: Currently 15,000 but I expect that number to double over the next 3 years.

Why is this important: Once again, for ADFS to integrate with another application or platform, they must support either WS-Fed or SAML. Siteminder can natively do SAML so integration shouldn’t be a problem. Also be aware of the expected grow and plug it into the ADFS calculator.

Key Takeaway: Always ask this question to be aware of all the integration points of ADFS and also how it impacts capacity planning.

 

11.) You: Will any users require multi-factor authentication (MFA) like PhoneFactor, RSA, etc?

CTO: With the desire to onboard an HR application this is also claims aware, we will definitely need multiple-factor authentication at some point.

Why is this important: ADFS 2012 R2 has native support for multiple factor authentication (MFA) plug-ins so that is the version we will recommend.

https://technet.microsoft.com/en-us/library/dn758113.aspx

Key Takeaway: This question will drive us towards what version of ADFS to use. In this case, ADFS 2012 R2.

 

12.) You: Will any of these federated applications require special authentication types – smartcard, certificate, etc?

CTO: Like I mentioned before, we’ll be onboarding a new HR application this is also claims aware, so we may need to hardcode certain authentication types for this.

You: Do any users login with smartcard only?

CTO: Yes

Why is this important: ADFS 2012 R2 also has native support for configuring specific authentication types for individual applications so we’ll have to add this to our plan.

Key Takeaway: Once again, this question will drive us towards what version of ADFS to use. In this case, ADFS 2012 R2.

 

13.) You: Do you have any special industry standards you need to comply with?

CTO: Yeah, we perform some work in the aerospace industry and will need to ensure that we stay compliant with the TSCP profile when accessing certain applications. This also applies when partners may be accessing our own applications.

Why is this important: Certain industries have standards for how they will perform business with each other. In regards to ADFS, this just means that we’ll need to include certain attribute definitions and values in the SAML tokens we issue for specific applications. Additionally, some industry stands specify certain authentication assurance levels so you’ll need them to apply assurance levels to their smartcards.

https://technet.microsoft.com/en-us/library/dd378897(WS.10).aspx

Key Takeaway: Be aware of any industry standards they have to comply with. It may not impact the actual build and deployment of ADFS but could impact how you create and configure some claims provider trusts (CPT) or relying party trusts (RP).

 

14.) You: Do you need high-availability of the ADFS service and backend SQL servers?

CTO: Yes, absolutely, email, Lync and ServiceNow will be mission critical to our business.

Why is this important: This reiterates the earlier point that we’ll need a robust ADFS and WAP farm and clustered SQL servers to provide a redundant infrastructure. This also drives the requirement that we’ll want some very intelligent load-balancers with HTTP probing capabilities, which then drives the question about whether LB devices will be SNI-compliant.

https://blogs.technet.com/b/applicationproxyblog/archive/2014/10/17/hardware-load-balancer-health-checks-and-web-application-proxy-ad-fs-2012-r2.aspx

Key Takeaway: You’ll need to find out whether they want redundancy at the server level, database level, or all of the above. Additionally, if they want to use hardware load balancers with intelligent HTTP probes, it is best if these devices are SNI compliant. There are workarounds in case the devices aren’t SNI compliant; see the blog above.

 

15.) You: Do you have a DR site and plan to keep part of this ADFS infrastructure in this DR site?

CTO: Yeah, we have a DR site where we plan to host a mirror of this infrastructure to ensure business continuity.

You: Will this DR infrastructure be active or just hot standby?

CTO: Hot standby.

What is this important: The ADFS and WAP farm now just got bigger as we’ll need even more servers in the DR site. We may even need to suggest an internet-based geo-load-balancing service like Akamai.

Key Takeaway: You need to determine how big an ADFS farm to build out and across how many locations they want. This also brings up the point of geo-load balancing services.

 

16.) You: Do you have a consistent UPN across the enterprise?

CTO: We do have various UPN’s in the enterprise because our provisioning process isn’t always working. Our other AD forest also has a completely different UPN for its users.

You: Follow-up with another question – Does your user’s UPN match their email address?

CTO: For 99% of our users, the UPN should match their email address, but like I mentioned, some users have a non-standard UPN.

What is this important: The easiest path forward is if the users’ UPN matches their email address. Then if ever prompted for credentials from ADFS or WAP, they can just type in their “email address”, even though ADFS is actually looking up their UPN. You’ll want to recommend a UPN clean-up before federating with O365. Also, so the ADFS infrastructure can find UPN’s in the other forest, you’ll definitely want to configure Name Suffix Routing to the forest trust configuration in AD Domains and Trusts. You may also want them to install the AlternateID hotfix on all their ADFS servers just in case someone’s email address doesn’t match their UPN.

https://blogs.technet.com/b/askpfeplat/archive/2014/04/21/introduction-to-active-directory-federation-services-ad-fs-alternateloginid-feature.aspx

Key Takeaway: UPN uniqueness and consistency across multiple forests is so, so important. If the customer doesn’t have a process to ensure uniqueness, they’ll be troubleshooting one-off issues for a long time to come. Clean them up first and then ensure they have a consistent provisioning process.

 

17.) You: Do you have any non-routable UPN’s in the enterprise?

CTO: What does that mean?

You: Do any users have a UPN like fabrikam.local or fabrikam.root, something not consistent with public DNS names?

CTO: No, I don’t think so.

What is this important: Reiterates the point that you’ll want to run a UPN cleanup before federating with O365 or implement AlternateID.

Key Takeaway: Non-routable UPN’s use to be a deal-breaker when migrating to O365. Now with alternateID, we have ways to get around this but this route comes with caveats. Set expectations about pros/cons if they have non-routable UPN’s.

 

18.) You: If you had to, would you be willing to change your UPN to support these projects?

CTO: Sure

What is this important: Good to know. We no longer need to worry about the Alternate ID functionality in ADFS 2012 R2.

Key Takeaway: Make them aware that UPN changes can cause issues with LOB applications but that unique, routable, consistent UPN’s should be the way forward.

 

19.) You: Do you have any other data or attribute stores besides Active Directory that we may need to pull user attributes from?

CTO: We do store other information about our users in various SQL databases across the enterprise.

What is this important: We’ll need to register some SQL attribute stores in ADFS. We’ll probably want the SQL DBA’s to create some stored procedures for us so we can get the information we want back quickly and safely.

Key Takeaway: Make sure to explain the differences between an attribute store and a custom attribute store (CAS). An attribute store is a database like AD, LDS, SQL for holding user information. A CAS is a custom .dll that can perform custom work including looking values up in an attribute store, calculating values on the fly, or looking up values in a .txt or .xml document. They’re only limited by their own creativity and a CAS gives them the ultimate flexibility.

 

20.) You: Related to this project, do you have any applications that users will need access that aren’t claims-aware?

CTO: Yeah know, now that mention it, we have some SharePoint 2010 sites with some PowerPivot V1 applications that need to be accessed via some external partners.

What is this important: In the back of your mind, you’re thinking, “I know PowerPivot V1 can only accept Windows credentials, how the heck am I going to make this happen with ADFS and external partners?” Then you remember that WAP in ADFS 2012 R2 can perform Kerberos Constrained Delegation (KCD). There is light at the end of the tunnel.

https://social.technet.microsoft.com/wiki/contents/articles/25990.configure-wap-to-do-kcd-with-the-backend-webapp.aspx

Key Takeaway: Microsoft typically recommends that the WAP/Proxy servers not be domain joined unless you need to perform Kerberos Constrained Delegation (KCD). It is actually possible for an external identity to perform Kerberos authenticate to an internal web application at Fabrikam without any Active Directory trust. This scenario will definitely require another blog. :)

 

Build Document

While all the previous questions with the CTO collected a lot of information, they can typically be distilled down into one acronym SPDCS: Servers, Ports, DNS, Certificates, and Software.

 

Servers

To determine the number of ADFS and WAP server we’re going to need, we’ll need to bust out our handy ADFS sizing calculator:

https://www.microsoft.com/en-us/download/details.aspx?id=2278

I’ve embedded mine so you can see my math. Also, ADFS 2012 R2 is 10%-30% more efficient, so I included a side-by-side of ADFS 2012 R2 with prior versions so you can compare. To be conservative, I put ADFS 2012 R2 at a 15% efficiency increase. The spreadsheet doesn’t include this efficiency so I just increased the numbers in the “Raw Data” tab by 15%.

Based on these numbers and N+1, we’ll need 3 ADFS servers to handle the load plus 3 more in the DR location for business continuity in case of a disaster:

• These ADFS and WAP servers can typically be either physical or virtual.
• ADFS is typically CPU-bound and place the majority of the load on the actual ADFS server. Therefore, I usually recommend 2 CPU’s and 4GB of RAM per ADFS server and 1 CPU and 4GB of RAM per WAP server.
• (3) ADFS servers in the main Datacenter.
• (3) ADFS servers in the DR Datacenter.
• (1) SQL cluster in the main Datacenter.
• (1) SQL cluster in the DR Datacenter.
• (2) Web Application Proxy (WAP) servers in the main Datacenter.
• (2) Web Application Proxy (WAP) servers in the DR Datacenter.
• (1) Azure AD Sync Server using the built-in SQL express.
• (4) or more load-balancing devices, two in each location that have SNI capabilities.

Total: 13 Servers, and 4 Hardware Load-Balancers

• Warning: Do not name any of the actual computer accounts in the ADFS farm sts.fabrikam.com, which will cause a duplicate SPN issue and break integrated Windows Authentication.
• Warning: We do not recommend that the DirSync server be placed on a domain controller.

 

Ports

• From the internet to the VIP of the public-facing load-balancers, you will need TCP 443 (SSL) open.
• From the ADFS WAP to the VIP of the back-end ADFS load-balancers, you will need TCP 443 (SSL) open.
• From all clients to the VIP of all internal ADFS load-balancers, you will need TCP 443 (SSL) open.
• From back-end ADFS servers to local SQL server servers, you will need TCP 1433 open.
• Between locations, you’ll need the necessary ports for SQL to replicate DB changes.
• If you’re using a SQL instance name, you also need UDP 1434 open from all ADFS servers to their respective SQL server.
• You’ll need TCP 443 outbound to the internet open from the Azure AD sync server to the internet.
• With ADFS 2012 R2, if they decide to use the self-signed certificates that ADFS can generate, the first server you install ADFS on will need LDAP TCP 389 access to the PDC emulator to create the certificate container in AD.
• If your ADFS servers require an internet proxy to complete the federation with Azure AD, you’ll have to run the following netsh command from the ADFS server you intend to complete the Azure AD federation with:

Netsh winhttp set proxy proxy-server="https=proxy.fabrikam.com" bypass-list="*.fabrikam.com"

• If your Dirsync server requires an internet proxy, you’ll have to add the following section to the Azure AD Sync configuration to ensure it can get out to the internet. Just paste it in the bottom and ensure it’s inside the </configuration></configuration> node.

FIle Location: C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config

<system.net>

       <defaultProxy>

         <proxy usesystemdefault="true" proxyaddress= https://proxy.fabrikam.com bypassonlocal="true"/>

      </defaultProxy>

</system.net>

 

DNS

• Run NSlookup sts.fabrikam.com internally and externally to ensure no one else in the company is using it.
• Create an external DNS Host (A) record that points to the external VIP of internet-facing load-balancers.
• Create an internal DNS Host (A) record that points to the internal VIP of the internal-facing load-balancers. Do NOT create CName records as it can cause issues with integrated Windows Authentication.

 

Certificates

• Since the customer also wants to do device registration and the users’ UPN’s are *fabrikam.com, we should ensure the Common Name (CN) on these SSL certificates include fabrikam.com. This will make registration by end-users very seamless. They’ve decided on sts.fabrikam.com.
• One set of publically trusted SSL certificates for the ADFS servers with common name (CN) of sts.fabrikam.com.
• Another set of publically trusted SSL certificates for the WAP servers with common name (CN) of sts.fabrikam.com. The thumbprints on this set will be different but they’ll share the same Common Name (CN).
• If the customer is really driven to save money on these certificates, they can use the same SSL certificate across all servers.
• Since they’ll probably be federating with partners at some point down the road, I would typically recommend the customer also purchase a token signing and token decryption certificate. If they go this route, the Enhanced Key Usage (EKU) on these two certificates doesn’t matter.

Total: 2 different SSL certificates with same common name, 1 token signing certificate, and 1 token decryption certificate.

 

Software

• All ADFS servers including WAP servers will run Windows Server 2012 R2.
• Azure AD Sync- https://go.microsoft.com/fwlink/?LinkId=511690
• Install the ADFS Client Access Policy Builder on an ADFS server: https://gallery.technet.microsoft.com/office/Client-Access-Policy-30be8ae2/view/Reviews

One of the ADFS servers will need the following two pieces of software to complete the federation with O365:

• Microsoft Sign-On Assistant: https://www.microsoft.com/en-us/download/details.aspx?id=39267
• Azure AD PowerShell: https://go.microsoft.com/fwlink/p/?linkid=236297

 

Other

• Ensure we have a process so that all UPN’s are unique cross all AD forests. You definitely want to run: get-aduser -filter {UserPrincipalName -notlike '*fabrikam.com}.
• Also run this in the Contoso forest with the value of their required UPN to identity any outliers: get-aduser -filter {UserPrincipalName -notlike '*contoso.com}.  
• Run a quick check to ensure we won’t have any duplicate SPN’s for the ADFS service name - get-aduser -filter {ServicePrincipalNamePrincipalName -eq 'sts.fabrikam.com}
• A service account or gMSA to run the ADFS service under.
• A service account for the Azure AD Sync tool
• The SQL connection strings for the attribute stores you’ll need to register in ADFS.
• Configure Name Suffix Routing for the other Contoso forest in AD Domains and Trust within Fabrikam.com.
• To support the SharePoint and PivotPoint requirement, the WAP servers will need to be domain joined.
• We’ll need to modify the UA Strings in ADFS to recognize other browsers, which will present them with forms-based authentication (FBA) when they are on the internal corporate network.
• We’ll need them to publish https://*.fabrikam.com to the Internet Explorer intranet zone via group policy or some other method.
• We’ll have to run the Azure AD Powershell cmdlets with the –supportmultipledomain switch.
• Contact Akamai about their Global Traffic Manager for automatic failover to the DR site.

 

Envisioning the Design

Disclaimer: This is just a sample design based on the fictional case study above.

 

We’re not going to go through actually installing ADFS in the blog as that has been covered before:

• https://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx
• https://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx
• https://blogs.technet.com/b/askpfeplat/archive/2014/03/17/how-to-build-your-adfs-lab-on-server-2012-part-3-adfs-proxy.aspx
• https://ppe.blogs.technet.com/b/askpfeplat/archive/2014/03/31/how-to-build-your-adfs-lab-part4-upgrading-to-server-2012-r2.aspx

My next blog will be about what conversations we need to have with application owners that want to onboard their applications to ADFS. Many times, the developers don’t know much about federation, and the ADFS admins don’t know much about their applications so someone has to be the middleman who can broker that conversation and ensure everyone gets what they need. Stay Tuned!

Dave “Stay Tuned” Gregory