DocumentationExperience Cloud KCS

AEM 6.5 TarMK cold standby: HTTP 503 AuthenticationSupport service missing error

Last update: October 19, 2026

✨ This content is AI generated and could be inaccurate. Generative AI Terms

This article describes why the ‘AuthenticationSupport service missing’ HTTP 503 error appears on AEM 6.5 TarMK cold standby nodes and provides steps to validate proper standby configuration and operation.

Description description

Environment

  • Adobe Experience Manager (AEM) 6.5 On-Premise
  • TarMK cold standby architecture

Symptoms

When setting up a TarMK cold standby in AEM 6.5 and synchronizing the crx-quickstart directory from primary to standby (with the standby runmode), accessing /aem/start.html on the standby instance results in an HTTP 503 error:

HTTP ERROR 503
Problem accessing /aem/start.html. Reason: AuthenticationSupport service missing. Cannot authenticate request.

Error logs may also show:

*ERROR* org.apache.sling.engine.impl.SlingHttpContext handleSecurity: AuthenticationSupport service missing. Cannot authenticate request.
*ERROR* org.apache.sling.engine.impl.SlingHttpContext handleSecurity: Possible reason is missing Repository service. Check AuthenticationSupport dependencies.

This occurs after synchronizing the primary to the standby and updating the runmode to “standby”.

Cause

The HTTP 503 ‘AuthenticationSupport service missing’ error on a TarMK cold standby node is expected because the standby is not intended to serve normal AEM endpoints. Only the OSGi Web Console is accessible for administration. This ensures data consistency and prevents user access to a read-only, sync-only node.

Resolution resolution

Follow the steps below to resolve the issue.

  1. Understand expected standby behavior:

    • In AEM TarMK cold standby architecture, the standby node is designed for content synchronization only and does not serve normal AEM endpoints (such as /aem/start.html, Sites, CRXDE, or Package Manager).

    • The HTTP 503 error with ‘AuthenticationSupport service missing’ is expected when accessing these endpoints on the standby node.

  2. Validate standby node health:

    • Access the OSGi Web Console at http(s)://<host>:<port>/system/console.

    • Confirm that /system/console is accessible on the standby node.

    • Verify the run modes at /system/console/status-slingsettings include standby (and as applicable, crx3, crx3tar).

    • Check the error.log for a successful standby-sync startup message, such as StandbyStoreService started standby sync with <host>:8023.

    • Review the Standby JMX MBean (org.apache.jackrabbit.oak:type="Standby") for:

    • Running = true

    • Status = running

    • SecondsSinceLastSuccess is not -1

    • Inspect tarmk-coldstandby.log for segment-transfer activity during initial synchronization.

  3. Ensure correct standby setup:

    • Only copy the complete installation to the standby after stopping the primary.

    • Configure separate filesystem-backed install.standby configurations.

    • Start the standby instance with run modes: standby,crx3,crx3tar (as applicable).

    • The standby run mode alone is not sufficient; ensure all required run modes are present.

  4. Promote standby to primary (if needed):

    • To test failover, stop or isolate the primary.

    • Update the standby’s run mode from standby to primary in crx-quickstart/conf/sling.properties.

    • Start the node and verify normal AEM access is restored.

recommendation-more-help
experience-cloud-kcs-help-kbarticles