ADFS Duo Adapter 2.4.0.0 for two factor authentication causes ADFS authentication issues when debug logging is enabled

 Recently when we updated our ADFS Duo adapter to version 2.4.0.0 we started getting Event ID 364 logged in the ADFS Admin log on certain relying party trusts which resulted in login failures.  In the exception details, we could see it referencing the Duo ADFS adapter.  

Working with Duo support, we found that one of the ADFS nodes that was experiencing the issue had debug logging turned on for the ADFS duo adapter.  Although debug logging had been turned on at some point in the past for previous troubleshooting, and was probably forgotten about, we didn't experience issues until the upgrade of the ADFS Duo adapter to version 2.4.0.0.

Turning debug logging off for the Duo ADFS adapter and restarting the ADFS service stopped the Event ID 364 errors and relying parties worked as expected.

Since I didn't see anything when searching the issue, I wanted to document it here.

Here are instructions on enabling / disabling debug mode for the Duo ADFS adapter:

https://help.duo.com/s/article/1098?language=en_US

Deep Security and Citrix Provisioning Services (PVS) targets

 We wanted to protect our Citrix PVS targets with the Deep Security agent in our organization and didn't find documentation on how to do it. You can read about Citrix Provisioning services here to get a better understanding of how a vdsik works and why it is not just a VM clone - https://deptive.co.nz/blog/what-is-citrix-pvs-and-why-should-you-use-it/

Our Deep Security environment:

• Two Deep security managers
• Deep Security manager version 12
• Sync with virtual center
  

Since these are not clones, the setting below did not seem to resolve our activation issues.  We would get errors about duplicate computers until it sorted itself out some 20 minutes later.

What we found worked:

• Boot the vdisk in read/write mode on a server you wish to use as your template box
  
• Install Deep Security, assign the correct policy, get everything updated and drivers loaded on the server and reboot to make sure no additional reboot will be requested on the PVS targets.
• Deactivate the template box in Deep Security console
  
• Change the 3 or 4 Deep Security services to manual.
• Edit the local logon script to include a check for whether the server is in read/write mode or read only mode.  This can be a scheduled task running a batch file at startup.
  
• If read/write mode, do not start the 4 TrendMicro Deep Security services
• If in read mode, start the 4 TrendMicro Deep Security services
• If in read mode, activate the agent and assign the correct policy  

This method prevents the template box from needing to be de-activated every time its booted to make changes to things on the vdisk other than DS.  When you are ready to add updates to the vdisk image you can start the services and let everything update and then deactivate the agent before saving the vdisk image. 

You can place batch files on the desktop for activation and de-activation of the template box.  So bring up template box with vdsik you want to update in read/write mode and then run the batch file to activate the agent and start the services.  Do all required DS updates.  Then run the deactivation command right before you are sealing the image that deactivates and stops the services.

 This is the stanza we used for Deep Security in our local startup script.

********* Trend Deep Security Activation *****************

find "_DiskMode=S" C:\Personality.ini >nul 2>&1
if %errorlevel%==0 (
net start "ds_agent"
net start "ds_monitor"
net start "ds_notifier"
net start "Amsp"
cd \
cd "C:\Program Files\Trend Micro\Deep Security Agent"
dsa_control -a dsm://yourserverhere:4120 "policyid:xxx"
)

Migrating your ADFS 2012 R2 SQL Database to a new or different SQL Server

I couldn't find good instructions on exactly how to migrate an existing ADFS SQL configuration to a new SQL server.  In my case, I was migrating from a stand alone SQL server to an AlwaysOn SQL Server for higher availability. 

ADFS has two databases it uses - AdfsConfiguration and AdfsArtifactStore.  So you have two places that you need up update the path to the new SQL Server.

Here are the steps I performed:

1.  Stop all ADFS Servers in your ADFS Farm.  ADFS Proxy servers are OK to leave up.
2.  Copy the two DB's to the new SQL server.
3.  Run the following command on each ADFS server in your farm to get the current information and take screenshots in case you need to revert the changes:

Get-WmiObject -namespace root/ADFS -class SecurityTokenService

Get-AdfsProperties

4. Run the following commands to update the location of the  "Adfsconfiguration" DB on each ADFS server you have: 

 

PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService

PS:\>$temp.ConfigurationdatabaseConnectionstring=”data source=<YourSQLServer>;initial catalog=adfsconfiguration;integrated security=true”

PS:\>$temp.put()

5.   Start ADFS Services now because the following command cannot be run with ADFS Service off.

6.  Run the below command on one of your ADFS server to update the location of the "ADFSArtifactStore" DB (Doesn't have to be run on all ADFS servers like the first command):

PS:\> Set-AdfsProperties –artifactdbconnection ”Data source=<YourSQLServer>;Initial Catalog=AdfsArtifactStore;Integrated Security=True”

7.  After the command is run, it will let you know to restart ADFS services on all servers in the farm, so do so at this time. 

8.   Run the following commands to verify that everything is now pointing at the new SQL server location:

Get-WmiObject -namespace root/ADFS -class SecurityTokenService

Get-AdfsProperties

9.  Test your configuration. You should now be pointing to the new SQL server.