New to ADFS (setup/diagram)

Janus Bariñan 1,126 Reputation points
2020-06-07T08:29:41.917+00:00

I am new to ADFS and I want to use one but don't know what the architecture would look like.

For Internal use. Am I right to use this diagram?

9225-adfs-internal.png

What ports are needed to communicate between the ADFS and DC?
Do I need to use ADFS proxy for internal network use?
Do internal clients need certificate of ADFS server?

For External use (internet). Would this be the right diagram?
9186-adfs-external.png

Am I right to say that only port 443 is used between ADFS proxy and ADFS Server?
ADFS proxy should be the only connected to the internet?
And that only traffic from port 443 should be allowed to the ADFS proxy ?
Do External users need a certificate from ADFS proxy or ADFS Server?
Should the ADFS proxy be joined to the domain?
How to secure ADFS proxy since it is facing the internet?

I am planning only 1 ADFS Server, is the ADFS farm a failover solution? Can I easily add new one ADFS server to an existing one to form a FARM?

I have been searching the internet and there are tons of resource that so much information it's hard to have an answer to my questions. I hope somebody could give clarity to my questions.

Active Directory Federation Services
Active Directory Federation Services
An Active Directory technology that provides single-sign-on functionality by securely sharing digital identity and entitlement rights across security and enterprise boundaries.
1,195 questions
0 comments
Accepted answer
  1. Mylo 86 Reputation points
    2020-06-08T19:52:19.297+00:00

    The ADFS proxy cert can be a wildcard cert, from a publicly trusted certificate authority. The proxy will need a public DNS record pointing to the public IP of the published service (the ADFS proxy should ideally be behind a firewall/load balancer). The ADFS proxy does not need to be joined to the domain. For the internal network, ADFS does not need a wildcard cert, but you can use one if you wish. It's not best practise, but often done for expediency. The ADFS and WAP must be part of the same DNS domain (e.g. abcdomain.com) and share the same URL, e.g. adfs.abcdomain.com, with records registered in Internet and Internal DNS. So, an ADFS service reachable at https://adfs.abcdomain.com would need:

    An (A) record in DNS called adfs to be created in Internet DNS in the abcdomain.com domain, with public IP address pointing to ADFS proxy/external firewall.
    An (A) record in DNS called adfs to be created in your Active Directory in the abcdomain.com domain, with internal IP address point to ADFS farm. Now, if abcdomain.com is not the same as your AD domain name, then you'll need to create a zone in AD DNS called abcdomain.com or a pinpoint zone (see here).

    Regards,
    Mylo

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mylo 86 Reputation points
    2020-06-07T21:21:45.13+00:00

    Hi Janus,

    Welcome to ADFS ... haven't posted in a while so this whole new Q&A setup is new to me :) .. Let's try and help with some of your questions. Your diagrams are looking pretty good. One thing you might want to add by way of explanation is the external/internal representation of how ADFS works with regards to DNS. AD FS uses split(brain) DNS. In a basic ADFS Internet-facing configuration, the external name will resolve to the internet registered IP address of your AD FS proxy, more commonly known as Web Application Proxy (WAP), or the external firewall in front of it, which is then doing NAT to the proxy. Internally, on the LAN, via AD, the federation service will point to the internal address of your AD FS farm nodes. This is an important distinction because externals connect to the Web Application Proxy (WAP) and do forms-based logon, entering username/password by way of a web form. Your internal clients point to the AD FS farm nodes, and, having line-of-sight to domain controllers get transparent login to web resources protected by AD FS, by way of Single-Sign On (SSO), for domain-joined machines. The ADFS management interface, allows tweaking authentication options based around Extranet (Internet) and Intranet (Internal), according to the desired authentication methods that need to be supported.

    "What ports are needed to communicate between the ADFS and DC?" ... your AD FS farm nodes should be right next to your DC, since they are security-equivalent to domain controllers. If they happen to be in a different zone/compartment of your network, then you'll need to open all the usual Windows firewall ports expected of communication between a member server and a domain controller on the firewall. Check here for more information. Port 443 is the only port required between the WAP and AD FS farm, until we add more complex configurations like load balancers between WAP.

    On the question of scaling out, you can begin with single nodes and expand to more nodes later. If your organization doesn't have hardware load balancers in place, you could use Windows Load Balancing to load balance traffic across multiple WAP or farm nodes in each respective segment. It's a limited solution feature-wise compared to dedicated offerings in the market, but might afford some availability should you wish to expand to the configuration.

    On the certificate side of things, it depends on what is in place and the size of your organization. If you have an AD Certificate Services (AD CS) platform in place, it's quite common to see the AD FS farm nodes using a service communications certificate issued to it from that PKI platform. The WAP, conversely, would have a certificate issued to it from one of the many commerical SSL certificate providers available on the Internet. In smaller configurations, the latter 3rd party certificate is often shared between AD FS farm and WAP, or a wildcard certificate is purchased and shared between front and back-ends.

    As you state, yes, the ADFS proxy should be the only thing connected to the Internet and normally this will be behind a NAT firewall of some sort (in a DMZ). In most configurations, the WAP does not need to be domain-joined, although mileage does vary on this. For example, if your DMZ has a dedicated domain, the WAP might be joined to that for management purposes. Another reason might be if you need to provide Kerberos SSO to on-premise web applications using constrained delegation.

    Security ADFS is a layered approach and the best practises that are applicable, often apply to the platform as a whole. Here a few:

    1. Disable AD FS endpoints you are not using. WAP endpoints can be disabled, independent of the AD FS farm nodes.
    2. Use Multi-Factor Authentication (MFA) either through Azure MFA or a 3rd party MFA provider for all Extranet clients.
    3. Enable Smart Extranet Lockout to shield AD passwords from attacks and build-out risk-based access.
    4. Use a gMSA instead of a standard service account
    5. Add the ADFS farm URL to the Local Intranet Zone of your (IE) browser, so that clients do Kerberos to AD FS instead of NTLM.
    6. Disable idpinitiatedsignon.aspx to prevent password spray attacks against AD, if the version you are using has it enabled (check via PowerShell --- Get-ADFSProperties)
    7. Use "Conditional Access" policies to differentiate between managed/unmanaged clients and/or IP location or user/groups
    8. Download the Microsoft Security Compliance Toolkit 1.0 and apply Group Policy (GPO) baselines to your servers (as a whole). You can use LGPO as a tool to export server baselines to your WAP if not domain-joined.
    9. Use Fine-Grained Password Policies
    10. Disable weaker SSL ciphers (SSL 3.0,TLS 1.0,1.1)
    11. Patch regularly!

    There are lots of other things that deserve mention security-wise, such as further OS/AD/application security points, or those that my memory and ignorance preclude/elude me respectively. Let's call this a starter :) Good luck!

    Regards,
    Mylo