Troubleshooting: Resolving "503 Service Unavailable" Error

Version Affected: All
 
 

Overview

Users see a "503 Service Unavailable" error when accessing the SecureAuth Identity Provider (IdP) — for example at the local admin console URL https://localhost/secureauth0/localadmin.aspx or at a realm's login page.

This error has several independent causes:

• See Cause 1 - The appliance has run out of disk space on the D: drive.
• See Cause 2 - The SecureAuth0 service account or its application pool is broken.
• See Cause 3 - The error appears specifically on the Password Policies or Password Deny Lists screens in the New Experience, on Identity Platform 22.02 or 22.12.
• See Cause 4 - The error appears specifically on the Password Policies or Password Deny Lists screens in the New Experience, after upgrading to Identity Platform 23.07 or later.
• See Cause 5 - The .NET 4.5 application pool crashes or stops, and the appliance has the Microsoft Monitoring Agent (SCOM) installed.

Check each cause below. The causes are not related, so a fix for one cause will not resolve another cause.

 

In this article

• Cause 1: The D: drive is full
• Cause 2: The SecureAuth0 service account or application pool is broken
• Cause 3: Password Policies/Deny Lists Feature Was Deprecated in 22.02/22.12
• Cause 4: IIS URL Rewrite Rules Point to the Wrong Version After Upgrading to 23.07+
• Cause 5: SCOM/APM Crashes the .NET 4.5 Application Pool

Cause 1: The D: drive is full

The D: drive is where SecureAuth stores realm configuration and logs. A "503 Service Unavailable" error occurs when this drive runs out of free space. This is typically caused by Audit logging or Debug logging being left enabled on one or more realms, which fills the drive with log files over time.

Resolution 1:

To resolve a full D: drive:

1. Open Windows Explorer and go to D:\SecureAuth
2. Point to each SecureAuth<Realm> folder to see which realm is using the most space.
3. Open the AuditLogs and DebugLogs folders for that realm, and delete old log files.
4. Once you have freed enough space, open the Internet Information Services (IIS) Manager console.
5. Go to Application Pools, and start the .NET 4.5 AppPool, DefaultAppPool, and SecureAuth0Pool application pools.
6. Open the SecureAuth Admin Console for the realm you identified in step 2, go to the Logs tab, and turn off Audit logging and Debug logging until you need them again.

Cause 2: The SecureAuth0 service account or application pool is broken

The IdP application runs under a Windows service account named SecureAuth0. A "503 Service Unavailable" error occurs when this account, or the application pool that uses it, is not configured correctly.

Resolution 2:

Work through each of the following checks in order.

Check the application pool's configuration file

A "503 Service Unavailable" error that affects every realm except the Admin Realm (SecureAuth0), together with Event ID 2307 from source IIS-W3SVC-WP in the Windows Application Event Log — reading similarly to "The worker process for application pool 'APPLICATION_POOL_NAME' encountered an error 'Cannot read configuration file' trying to read configuration data from file '\?\<EMPTY>'" — means IIS cannot read that application pool's own configuration file. This file is normally located at D:\inetpub\temp\appPools\APPLICATION_POOL_NAME\APPLICATION_POOL_NAME.config, and the error occurs when it is missing, corrupted, or has the wrong permissions.

1. Confirm the file exists and contains valid XML.
2. Confirm its access control list (ACL) grants Full control to SYSTEM and Administrators, and Read access to IIS AppPool\APPLICATION_POOL_NAME.

If the file is missing, corrupted, or its permissions cannot be corrected, recreate the application pool instead:

3. In IIS Manager, expand Server > Application Pools.
4. Right-click the existing APPLICATION_POOL_NAME, select Basic Settings..., and record its settings; repeat for Advanced Settings.
5. Right-click Application Pools, select Add Application Pool..., give the new pool a name, set it to match the settings just recorded, then click OK.
6. Right-click the new application pool, select Advanced Settings, confirm every setting matches what was recorded, then click OK.
7. Right-click the original APPLICATION_POOL_NAME and select View Applications.
8. For each application listed, right-click it, select Change Application Pool..., choose the newly created application pool, and click OK. Repeat for every application that was assigned to the old application pool.

The affected realms should now work.

Check the SecureAuth0 account permissions

• The SecureAuth0 account must be a member of the local Administrators group.
• The SecureAuth0 account must not be locked or disabled.
• If the appliance is joined to a domain, confirm that no domain Group Policy Object (GPO) is restricting the rights of local service accounts.

Check the Application Pool Identity

The SecureAuth0Pool application pool must run under the built-in ApplicationPoolIdentity account. If this Identity has been manually changed to a domain or local service account, the application pool stops and the site returns a "503 Service Unavailable" error.

1. Open Internet Information Services (IIS) Manager and click Application Pools.
2. Confirm whether SecureAuth0Pool shows a Status of Stopped and an Identity other than ApplicationPoolIdentity — for example, a domain account such as DOMAIN\secureauth0.
   
3. Right-click SecureAuth0Pool and select Advanced Settings.
4. Next to Identity, click the ... button to open the Application Pool Identity window.
5. Select Built-in account, then choose ApplicationPoolIdentity from the drop-down list, and click OK twice.
6. Start the SecureAuth0Pool application pool.

Reset the SecureAuth0Pool password

A "503 Service Unavailable" error occurs when the password stored in the SecureAuth0Pool application pool no longer matches the actual password of the local SecureAuth0 account.

1. On the appliance, click Start.
2. Go to All Programs > SecureAuth.
3. Run Refresh_SecureAuth0. This resets the local account password and updates the application pool to match.

Reset file permissions and shares

1. On the appliance, click Start.
2. Go to All Programs > SecureAuth.
3. Run Reset File Perms and Shares. This restores the file and folder permissions that the SecureAuth0 account needs.

Repair the .NET Framework

If none of the checks above resolve the error, the .NET Framework installation may be corrupt.

1. Open Programs and Features in Windows.
2. Select .NET Framework 4 (or the installed 4.x version) and choose Repair.
3. If the repair option is not available, download and reinstall the same .NET Framework version from the Microsoft website.

Cause 3: Password Policies/Deny Lists Feature Was Deprecated in 22.02/22.12

Applies to versions 22.02 and 22.12 (all Hotfix levels).

On Identity Platform 22.02 and 22.12, accessing the Password Policies or Password Deny Lists screens in the New Experience — or creating a Password Reset realm — can show a 503 error, because this functionality was deprecated in these versions.

Resolution 3:

A new and improved version of this functionality is available starting with Identity Platform 23.07. Upgrade to 23.07 or later to resolve this.

If the 503 error is still shown on the Password Policies or Password Deny Lists screens after upgrading to 23.07 or later, see Cause 4 below.

Cause 4: IIS URL Rewrite Rules Point to the Wrong Version After Upgrading to 23.07+

Applies to versions 23.07 and later.

After upgrading to Identity Platform 23.07 or later, the Password Policies or Password Deny Lists screens in the New Experience can still show a 503 error if certain IIS URL Rewrite rules were not updated to reference the correct version.

Resolution 4:

To resolve this:

1. In IIS Manager, go to Sites > Default Web Site > HttpProxy > URL Rewrite.
2. Confirm the following rules reference the Identity Platform version currently running, and click Apply after making any changes:
   • Coruscant Assets Router — for example, https://sparkles-content.prod.secureauth.com/24.04{R:1} on 24.04.
   • Mandalore Assets Router — for example, https://sparkles-content.prod.secureauth.com/applications/core/24.04/mandalore{R:1} on 24.04.
   • IWA Assets Router — for example, https://sparkles-content.prod.secureauth.com/24.04/Idp-S3-Files/iwa{R:1} on 24.04.

Cause 5: SCOM/APM Crashes the .NET 4.5 Application Pool

Applies to appliances with the Microsoft Monitoring Agent (SCOM) installed.

The Application Performance Monitoring (APM) feature in the Microsoft Monitoring Agent (SCOM) can crash the .NET 4.5 application pool. Restarting the application pool does not resolve this — it crashes again.

Resolution 5:

To resolve this:

1. In IIS Manager, confirm the .NET 4.5 application pool's status is actually Stopped.
2. Check the Windows Application Event Log for a crash matching this signature:

Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x5215df96
Faulting module name: PerfMon64.dll, version: 8.0.10918.0, time stamp: 0x577fd168
Exception code: 0xc0000409
Faulting application path: C:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Program Files\Microsoft Monitoring Agent\Agent\APMDOTNETAgent\V8.0.10918.0\PerfMon64.dll

3. If the module path matches (a crash in PerfMon64.dll under the Microsoft Monitoring Agent's APMDOTNETAgent folder), the immediate fix is to uninstall the Microsoft Monitoring Agent (SCOM Agent).
4. If the SCOM agent is required, follow Microsoft's APM feature causes IIS application pool crash article to learn how to install the agent without APM instead.

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.