Troubleshooting: FileSync Creates Lowercase Realm Folder and IIS App Names

Version Affected: FileSync 4.0.13 and lower
 
 

Overview

On the secondary server(s), realm folder and IIS application names created by FileSync are all lowercase, instead of matching the master server's CamelCase naming. If a SAML, OIDC, or WS-Fed integration requires the URL to use a specific case, this can break that integration -- and it can also interfere with the Copy Utility in the SecureAuth Updater.

• See Cause 1 - Fix the Folder and Application Names Directly
• See Cause 2 - Only the IIS Path Needs to Match

Both options fix the same underlying cause -- pick whichever matches how much you need to fix.

 

In this article

• Cause 1: Fix the Folder and Application Names Directly
• Cause 2: Only the IIS Path Needs to Match

Cause 1: Fix the Folder and Application Names Directly

Windows itself is case-insensitive, but a service provider's server technology may not be. Older versions of FileSync (4.0.13 and lower) don't preserve the case of each character in the folder name during replication, so realm folder and IIS application names on the secondary server(s) end up all lowercase instead of matching the master's CamelCase naming (for example, secureauth123 instead of SecureAuth123). To fix the underlying folder and application names directly -- not just how IIS routes to them -- rename both on the secondary server(s).

Resolution 1:

To resolve this:

1. Take a full backup/snapshot of the IdP.
2. Open PowerShell as Administrator.
3. Stop the SecureAuth FileSync service.
4. If not already imported, import the IIS Administration module:

Import-Module WebAdministration

5. Rename the filesystem folders:

cd D:\SecureAuth; gci -Directory | ?{$_.name -cmatch "secureauth[0-9]{1,3}$"} | %{ren $_ "_$($_.name)"; ren "_$($_.name)" $_.name.replace('secureauth','SecureAuth')}

6. Rename the IIS apps:

cd 'iis:\sites\default web site'; gci | ?{$_.name -cmatch "secureauth[0-9]{1,3}$"} | %{ren $_.name $_.name.replace('secureauth','SecureAuth')}

7. Start the SecureAuth FileSync service.

Cause 2: Only the IIS Path Needs to Match

Windows itself is case-insensitive, but a service provider's server technology may not be. Older versions of FileSync (4.0.13 and lower) don't preserve the case of each character in the folder name during replication, so realm folder and IIS application names on the secondary server(s) end up all lowercase instead of matching the master's CamelCase naming (for example, secureauth123 instead of SecureAuth123). If only the IIS-facing path needs to match -- for example, a single SAML/WS-Fed service provider's URL -- it's enough to repoint IIS without renaming anything on the filesystem.

Resolution 2:

To resolve this:

1. Back up C:\Windows\System32\inetsrv\config\applicationHost.config.
2. Open the original file in a text editor and replace path="/secureauth with path="/SecureAuth.
3. Save the file -- IIS picks up the change automatically.

The case used must match how the SAML/WS-Fed URLs are configured on the service provider's side. This may need to be repeated on multiple servers, depending on how many are in the FileSync configuration.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.