PAG Stage Fails in Privilege Task Automation Workflow – “Bind failed. LDAPS server az3.wxyz.com:636 is down”

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi Developers

1 Overview

We’re automating Privileged Access in IdentityNow (IDN) and the workflow consistently fails at Stage 4 – Privilege Automation Gateway (PAG), which retrieves OU data from Active Directory (AD). The rest of the stages complete without issue.

2 Environment

Component Details
Workflow Privilege Task Automation
Stage 4 PAG – List OU from AD
Virtual Appliance (VA) Hosted in Azure
AD endpoint az3.wxyz.com:636 (LDAPS)
Credential Provider AWS Secrets Manager (referenced via Credential Provider in IDN)
Certificates All IQService certs imported to sailpoint/certification on the VA
Hosts file hosts.yaml updated with correct FQDNs

3 Steps Leading to Failure

  1. Workflow executes Stages 1-3 successfully.
  2. On entering Stage 4 – PAG, IDN should:
  3. Retrieve AD bind credentials from the Credential Provider (AWS Secrets Manager).
  4. Bind to AD over LDAPS (636) and list OUs.
  5. Instead, the bind fails and the stage aborts or keep waiting on this stage.

4 Error Message

Screenshot (43)
Screenshot (43)1919×754 63.4 KB

No organizational units were found in Active Directory due to a command failure.
Detail Code: 500.1.504 Downstream Target Timeout
Error: Bind failed. LDAPS server az3.wxyz.com:636 is down.

5 Troubleshooting Already Performed

  • Imported IQService root & intermediate certs to VA keystore (sailpoint/certification).
  • Verified firewall rules – port 636/tcp open between VA (Azure) and AD.
  • Confirmed AD endpoint resolves via DNS inside VA.
  • Updated hosts.yaml with az3.wxyz.com.
  • Tested manual openssl s_client -connect az3.wxyz.com:636 from VA – successful TLS handshake.
  • Ensured AWS Secrets Manager secret contains valid username/password pair (bind account).

6 Key Questions

  1. Authentication sequence
    2.Does Stage 4 first authenticate to the Credential Provider to fetch credentials, or does it contact AD first?*
  2. Credential string format
    Field currently set to:
secrets://aws-vault/arn%3Aaws%3Asecretsmanager%3Aus-east-1%3A123456789012%3Asecret%3AmySecret/username

4.“aws-vault”* – Is this meant to be the Credential Provider name configured in IDN, or the literal AWS Secrets Manager “vault” name? Documentation is unclear.

Regards
Vatan

2

Read this and use it as a guideline. I say use the upn as the username else bind can fail

3

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.