ADFS high availability

[Uber22]

Hey everyone

 

After some advice I am looking to put in place high availability and redundancy for our adds server our current setup is 1 server connect to the das witch runs ADFs and few other VM and the other side of the das is second domain controller setup for load balancing dchp ect but can't replicate the files so if our domain controller file server goes down we can really on login .I was thinking of replicatinf to a server setup in ovh or using my second server onsite.

 

The other issue if the main DC does off is everyone loses folder redirection and desktops.

 

Would be great full for some ideas.

 

Thanks .

[HPlum78]

Need to iron our a few things, so you have two DC's connected to a (1) DAS host? (how many nodes are in your virtual environment?) on a host you also have an ADFS sever (is this multi role?) on the same or another host you have a files server? (again where is this? On the same server as your one of your DC's/ADFS server) what versions of the OS are we talking about?

[Uber22]

So Host 1 (Physical ) plugs into our MDS600 DAS via sas cable right draw, host 1 runs virtal machine witch is active directory files server then on the same server we have a couple of vms that are the print server, finance server. on the DAS left side draw number 2 connects to the second host via 2 sas cables then this run AD server in load balancing mode for dhcp this server does replicate the data. OS version server 2016 and server 2019 on host 2

[EddyAllen]

I just made two small VM's in Azure that were on a site to site VPN link one is a DC the other is a ADFS server. This should cover all bases for availability and redundancy and have decent performance.

 

Have one as a DC and use the smallest VM size possible and use a server core image. The ADFS server is set up as the second from smallest VM size, once its set up add it to your server farm and make it the primary ADFS server and change the old one to secondary.

Change the relevant DNS settings on your web host to point your sts.organization.com to the Azure VM. You can set your own sts.organization.com internal DNS entry to only point to your local adfs server for performance reasons but if you have a reasonable WAN link this shouldn't be a problem.

 

You can make sure that the new DC in azure is only used for the ADFS server instead of being one that local users will authenticate on by changing the ldapserverpriority in the registry or by adding a new AD Site for Azure.

 

With this solution I find that if we have had an extended power cut, users from home are still able to access all federated services. I personally have set our internal DNS entry for STS to point to our local ADFS server due to having a shocking WAN link and due to having the ADFS server just move to another HyperV cluster node in the event of a hardware failure.

[HPlum78]

Yeah exactly what @EddyAllen has said. Although you still need to solve the file server dependencies.

[free780]

If you enable password hash sync and in the event of a power cut/Internet outage on prem. Could you not just disable authentication via federation (using a cloud only account) ? Will this save on the Azure costs?

[HPlum78]

@free780 that would allow auth to continue for some applications and is something I have setup as a fall back position. I dont know how many apps @Uber22 is securing behind ADFS and where they actually exist (cloud/ on prem) but in a DR situation how important are those apps? Some of my users would argue that they need access to the apps I have behind our ADFS environment but I have ~40 apps that leverage it, we have considered a small IaaS deployment in Azure to use in an DR situation, and we a number of data centers.

[DrCheese]

If you enable password hash sync and in the event of a power cut/Internet outage on prem. Could you not just disable authentication via federation (using a cloud only account) ? Will this save on the Azure costs?

 

This is what I used to do - Bump into Azure using the cloud only account and switch off federation/put it in password sync mode. When ADFS came back up put it back.

 

But I've recently dumped all our ADFS servers and moved to just Azure SSO - It works exactly as ADFS does internally and externally it forwards everything to Microsoft rather than your internal ADFS (It basically works in the same way) - The only downside is you need to put a ticket into MS to switch to password fall through if your servers lose connection to the web (As it requires a low maintance agent on a few servers) but that's not a big deal.

 

The benefits you get are easy MFA, no faffing around supporting ADFS & upgrading it, the ability to audit *all* your logins easily for a user & Microsoft's risk protection feature is the absolute dogs nackers - It can flag up when a users credentials have been leaked in a password breach, or warn you if they've done something like login in from Bristol but 5 minutes later logged in in Japan - Indicates the account is likely hacked. I did have to buy Azure P1 one for this, but it's absolutely worth it

[HPlum78]

@DrCheese Azure SSO is not yet a direct replacment for ADFS its close but not everything is there yet... I would and keep looking at doing as you have done but just leverage some bits of ADFS that stop us.

 

Oh and you can still do MFA and have all the impossible travel reports and compromised account reporting and still leverage ADFS as that's what we do, not a mutual Azure SSO feature.

Edited February 12, 2019 by HPlum78

[Uber22]

I just made two small VM's in Azure that were on a site to site VPN link one is a DC the other is a ADFS server. This should cover all bases for availability and redundancy and have decent performance.

 

Have one as a DC and use the smallest VM size possible and use a server core image. The ADFS server is set up as the second from smallest VM size, once its set up add it to your server farm and make it the primary ADFS server and change the old one to secondary.

Change the relevant DNS settings on your web host to point your sts.organization.com to the Azure VM. You can set your own sts.organization.com internal DNS entry to only point to your local adfs server for performance reasons but if you have a reasonable WAN link this shouldn't be a problem.

 

You can make sure that the new DC in azure is only used for the ADFS server instead of being one that local users will authenticate on by changing the ldapserverpriority in the registry or by adding a new AD Site for Azure.

 

With this solution I find that if we have had an extended power cut, users from home are still able to access all federated services. I personally have set our internal DNS entry for STS to point to our local ADFS server due to having a shocking WAN link and due to having the ADFS server just move to another HyperV cluster node in the event of a hardware failure.

 

Hi Eddy

 

Would you able to pM me your email address and maybe some screenshots of your VM setup in azure.

Thanks