Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.
I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?“
So I built it on the test bench, and did it myself.
Solution
To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.
First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.
Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.
WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.
Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.
OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;
But if you want to use the native Windows VPN client you can still use L2TP over IPSEC. I had a look around the net to work out how to do this and most decent articles are written using the older versions of the ASDM, and the CLI information I found on Cisco’s site didn’t help either.
What I’m using
1. Cisco ASA5525 version 9.2(4) and ASDM version 7.6(1).
2. Network behind the ASA 192.168.110.0/24.
3. IP addresses of the remote clients 192.168.198.1 to 254 (DNS 192.168.110.10).
Configure the ASA 5500 for L2TP IPSEC VPNs from ASDM
1. From within the ASDM > Wizards > VPN Wizards > IPSec (IKEv1) Remote Access VPN Wizard)
2. Next.
3. Tick Microsoft Windows Client using L2TP over IPSEC > Tick MS-CHAP-V2 ONLY > Next.
4. Type in a pre-shared key > Next.
5. Select LOCAL authentication > Next.
6. Enter a username/password to use for connection to the VPN > Next.
7. Create a ‘VPN Pool‘ for the remote clients to use as a DHCP pool > OK > Next.
8. Enter your internal DNS server(s) and domain name > Next.
9. Set your internal network(s) > Tick “Enable Split tunnelling…” > Untick PFS > Next.
10. Finish.
11. Save the changes.
Configure the ASA 5500 for L2TP IPSEC VPNs from CLI
1. Connect to the ASA, go to “enable mode”, then to “Configure terminal mode”
[box]
User Access Verification
Password:
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure Terminal
PetesASA(config)#
[/box]
2. First we need to create a “Pool” of IP addresses for the remote client to use.
[box]
PetesASA(config)# ip local pool L2TP-Pool 192.168.198.1-192.168.198.10
[/box]
3. Now to make sure the traffic that’s going to travel over our VPN is not NATTED.
Note: This is assuming that 192.168.100.0/24 is the remote VPN clients subnet, and 10.254.254.0/24 is the subnet BEHIND the ASA.
4. Normally when a remote client is connected they will lose all other connections (including their other internet connections) while connected, to stop this you need to enable “Split Tunnelling“. You will refer to this later but for now we just need to create an ACL.
[box]
PetesASA(config)# access-list Split-Tunnel-ACL standard permit 192.168.110.0 255.255.255.0
[/box]
5. We need a “Transform Set” that will be used for “Phase 2” of the tunnel, I’m going to use AES encryption and SHA hashing, then set the transform type to “Transport”.
6. Remote VPNs usually use a “Dynamic Cryptomap”, the following will create one that uses our transform set, then applies that to the firewalls outside interface.
7. Then enable IKE (version 1) on the outside interface. And create a policy that will handle “Phase 1” of the tunnel, in this case 3DES for encryption, and SHA for hashing, and Diffie Hellman group 2 for the secure key exchange.
8. Create a group policy, that hold the following, DNS server IP(s) that will be leased to the remote clients. Tunnel type (L2TPIPSEC), enable spit tunnelling using the ACL we created in step 4. The domain name that will be given to the remote clients. The “intercept-dhcp enable” looks after a Windows client problem. And finally create a user and password.
Note: In this example I’m using the ASA’s local database of users for authentication.
9. Every tunnel needs a “Tunnel Group”, You HAVE TO use the DefaultRAGroup (Unless you are securing things with certificates which we are not). This pulls in the IP Pool we created in step 2 and the policy we created in step 8.
10. For the tunnel group, setup a shared key, and the authentication method for our clients.
Note: We are disabling CHAP and enabling MSCHAP v2.
[box]
PetesASA(config-tunnel-general)# tunnel-group DefaultRAGroup ipsec-attributes
PetesASA(config-tunnel-ipsec)# ikev1 pre-shared-key 1234567890
PetesASA(config-tunnel-ipsec)# tunnel-group DefaultRAGroup ppp-attributes
PetesASA(config-ppp)# no authentication chap
PetesASA(config-ppp)# authentication ms-chap-v2
[/box]
11. Finally save the new config.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Configure Windows VPN client for L2TP IPSEC connection to Cisco ASA 5500
Note: Windows 10 Enterprise used.
1. Start > Settings > Network and Internet.
2. VPN > Add a VPN Connection.
3. VPN Provider = Windows (Built-in) > Connection Name = (A Sensible name) > Server name or Address = Public IP/Hostname of the ASA > Scroll Down.
4. VPN Type = L2TP/IPSEC with pre-shared key > Pre Shared Key = {the one you set on the firewall in our example 1234567890} > Type of sign-in information = Username and Password.
Note: You may want to untick “Remember my sign-in information” To supply a username and password each time.
5. Start > ncpa.cpl {Enter} > Right click your VPN connection profile > Properties..
6. Security Tab > Allow These Protocols > Tick “Microsoft CHAP version 2 (MS-CHAP v2)” > OK.
7. You can now connect your VPN.
Related Articles, References, Credits, or External Links
