AWS SaaS provisioning fails with “Failed to create assume role credentials”

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

We are testing AWS account provisioning using the AWS SaaS connector in SailPoint ISC.

image
image640×564 43.3 KB

The identity does not already have an AWS account, so SailPoint should create the IAM user first and then assign the requested AWS managed policy.

We configured the Create Account profile as follows:

UserName               = Identity Attribute (email)
password               = Create Password
AccountId              = Static: 3*********81
PasswordResetRequired  = true
AccessKey               = false

Provisioning is enabled on the source.

The access request now reaches the AWS connector, but fails with:

[ConnectorError]
AWS Client creation failed:
Failed to create assume role credentials from connectorServices
for role ARN:

arn:aws:iam::aws:role/SailPoint-Test

The requested entitlement is:

arn:aws:iam::aws:policy/AdministratorAccess

On the AWS side, we have already verified:

  • SailPoint-Test role exists in the target AWS account
  • sts:AssumeRole permission is configured
  • Trust relationship is configured
  • SailPoint External ID is configured
  • IAM provisioning permissions are available
  • Target AWS Account ID is 3***********81

The expected role ARN should normally be:

arn:aws:iam::3*********81:role/SailPoint-Test

However, SailPoint is trying to use:

arn:aws:iam::aws:role/SailPoint-Test

Has anyone faced this behavior before?

Could this be related to requesting an AWS-managed policy where the entitlement ARN contains ::aws:policy/..., causing SailPoint to incorrectly resolve aws as the target account when creating the role ARN?

Any guidance on how SailPoint determines the target AWS Account ID during new IAM account provisioning would be appreciated.

2

Hello Ahmed. I would look at this malformed role ARN:

arn:aws:iam::aws:role/SailPoint-Test

For the target account, that should contain the 12-digit AWS account ID, for example:

arn:aws:iam::<account-id>:role/SailPoint-Test

Since the same aws value appears in the requested AWS-managed policy ARN (arn:aws:iam::aws:policy/AdministratorAccess), I would treat that as a strong hypothesis for where the wrong account value is coming from, though the docs do not confirm that internal behavior.

I would test this in order:

  1. Confirm AccountId resolves to the correct target account during Create. SailPoint supports either the 12-digit ID or the AWS Account ARN.
  2. Try the exact ARN from the aggregated AWSAccount object as AccountId.
  3. If you can trigger account creation independently, test the same Create request without AWSManagedPolicies. If the role ARN then uses the correct account ID, that strongly isolates the combined managed-policy request as the trigger.
  4. After the IAM user exists, request AdministratorAccess separately.

If it still generates arn:aws:iam::aws:role/..., I would raise a SailPoint Support case. At that point, it looks more like target-account resolution inside the connector than an AWS trust-policy issue.