Docs

Appearance

AWS IAM Identity Center Operations ​

How IAM Identity Center Works ​

AWS IAM Identity Center (formerly AWS SSO) is the single control plane for all human access across the 7-account Cirius Group org. Nobody gets long-lived IAM user credentials — you authenticate once through Identity Center and receive short-lived session tokens valid for 8 hours.

Architecture ​

Azure Entra ID (ciriusgroup.com)
      │
      │  SCIM provisioning (users + groups synced automatically)
      ▼
IAM Identity Center  ←─── lives in: Identity account (414134953818)
      │                             administered from: Management account (206820231356)
      │
      │  Permission sets (IAM policies packaged for reuse)
      │  Account assignments (which group gets which permission set in which account)
      ▼
All 7 accounts (Management, Backup, Dev, Identity, Logging, Networking, Prod)

Identity source: Azure Entra ID, connected via SCIM (System for Cross-domain Identity Management). Entra pushes users and groups to Identity Center automatically when membership changes. You do not create users directly in Identity Center — Entra is the source of truth.

Permission sets: IAM policies bundled with a session duration. A permission set is not attached to an account until you create an account assignment. One permission set can be assigned to multiple accounts.

Account assignments: The three-way link between a principal (user or group), a permission set, and an account. When a user logs into the SSO portal, they see only the accounts they have an active assignment for.

SSO start URL: https://d-9267898861.awsapps.com/start

Region: IAM Identity Center is enabled in us-west-2. This is the home region — all Identity Center API calls go to us-west-2 regardless of which account you're working in.

What SCIM Syncs ​

Entra pushes to Identity Center within a few minutes of a membership change. What syncs:

SyncsDoes Not Sync
Users (name, UPN, email)Passwords (SSO is federated — no password in Identity Center)
Group membershipNested groups (Identity Center flattens to direct members)
User enable/disable stateLicenses, MFA methods

Only groups that are explicitly assigned to Identity Center in Entra SCIM config are synced. Not every Entra group exists in Identity Center — only those provisioned for AWS access.

Adding a User to an AWS Account ​

This is a group-based operation. You do not assign individual users to accounts directly — you add the user to an Entra group, and SCIM carries that group into Identity Center.

Step 1 — Identify or Create the Entra Group ​

Find the group that maps to the access level you want in the target account. The naming convention for AWS-facing Entra groups is:

AWS-<AccountAlias>-<PermissionSetName>
Examples:
  AWS-Prod-AdministratorAccess
  AWS-Logging-ReadOnlyAccess
  AWS-All-ReadOnlyAccess    (cross-account group)

If the right group already exists, skip to Step 2. If you need a new group, create it in Entra (see "Creating a New Permission Set" for when you'd also need a new permission set).

Step 2 — Add the User to the Entra Group ​

Portal: Entra ID → Groups → [group] → Members → Add members → select user

CLI (Azure):

bash
# Get the group object ID
az ad group show --group "AWS-Prod-AdministratorAccess" --query id -o tsv

# Add the user
az ad group member add \
  --group "AWS-Prod-AdministratorAccess" \
  --member-id $(az ad user show --id user@ciriusgroup.com --query id -o tsv)

Step 3 — Wait for SCIM Sync ​

SCIM sync runs on a short cycle (typically 2–5 minutes). You can check the sync status in Entra if you want to confirm it fired:

Entra ID → Enterprise applications → [Identity Center SCIM app] → Provisioning → Provisioning logs

Filter by the user's UPN. A successful sync shows Action: Update, Status: Success.

Step 4 — Verify in Identity Center ​

bash
# List all users in Identity Center
aws sso-admin list-account-assignments \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --account-id 807267566999 \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

# Or look up the user specifically in Identity Center
aws identitystore list-users \
  --identity-store-id d-9267898861 \
  --filters AttributePath=UserName,AttributeValue=user@ciriusgroup.com \
  --region us-west-2 \
  --profile main

To get your Identity Center instance ARN and identity store ID:

bash
aws sso-admin list-instances --region us-west-2 --profile main

Step 5 — Verify the User Can Access the Account ​

Have the user log in at https://d-9267898861.awsapps.com/start and confirm the target account appears in their list. If it doesn't appear within 10 minutes of SCIM sync completing, check account assignments (Step 4 above) — the group may be synced to Identity Center but not yet assigned to that account.

Removing a User from an AWS Account ​

Option A — Remove from Entra Group (Preferred) ​

Remove the user from the Entra group. SCIM propagates the change automatically.

Portal: Entra ID → Groups → [group] → Members → select user → Remove

CLI:

bash
az ad group member remove \
  --group "AWS-Prod-AdministratorAccess" \
  --member-id $(az ad user show --id user@ciriusgroup.com --query id -o tsv)

After SCIM sync completes (~5 minutes), the user's account assignment is revoked. Their active SSO session continues until it expires (up to 8 hours) — if you need immediate revocation, also do the step below.

Option B — Revoke Active Sessions Immediately ​

If you need to cut access right now (incident response, employee termination):

bash
# Get the user's Identity Center user ID
USER_ID=$(aws identitystore list-users \
  --identity-store-id d-9267898861 \
  --filters AttributePath=UserName,AttributeValue=user@ciriusgroup.com \
  --region us-west-2 \
  --profile main \
  --query 'Users[0].UserId' --output text)

# List their active SSO sessions (not directly exposed — use CloudTrail or portal)
# Portal: Identity Center → Users → [user] → Active sessions → Delete all sessions

The portal path for session revocation: IAM Identity Center (in Management account) → Users → [user] → Active sessions → Delete session

Verify Removal ​

bash
# Confirm the user no longer has assignments in the target account
aws sso-admin list-account-assignments \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --account-id 807267566999 \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

Creating a New Permission Set ​

Permission sets define what someone can do once they have access to an account. Think of them as IAM role templates — the same permission set can be deployed to multiple accounts.

Naming Convention ​

<AccessLevel>[-<Scope>]
Examples:
  AdministratorAccess         (AWS managed policy, full admin)
  ReadOnlyAccess              (AWS managed policy, read-only)
  PowerUserAccess             (AWS managed policy, no IAM changes)
  SecurityAuditAccess         (custom — CloudTrail, Security Hub, Audit Manager read)
  BackupOperatorAccess        (custom — Veeam target operations only)
  NetworkingReadOnly          (custom — Palo Alto/VPC inspection only)

Use AWS-managed policies when they fit. Custom inline policies are for cases where managed policies are too broad.

Session Duration ​

Use CaseDuration
Break-glass / emergency admin1 hour
Standard admin (AdministratorAccess)8 hours
Read-only / audit8 hours
CI/CD automation (use OIDC instead)N/A — do not use Identity Center for CI/CD

Create the Permission Set ​

bash
# Create the permission set shell
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --name "SecurityAuditAccess" \
  --description "Read-only access to CloudTrail, Security Hub, Config, and Audit Manager" \
  --session-duration "PT8H" \
  --region us-west-2 \
  --profile main

# Attach an AWS managed policy (if using one)
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --managed-policy-arn arn:aws:iam::aws:policy/SecurityAudit \
  --region us-west-2 \
  --profile main

# Or attach a custom inline policy
aws sso-admin put-inline-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --inline-policy file://security-audit-policy.json \
  --region us-west-2 \
  --profile main

Assign the Permission Set to Accounts ​

A permission set does nothing until it's assigned to an account + principal combination.

bash
# Get the group ID from Identity Center (not the Entra group object ID)
aws identitystore list-groups \
  --identity-store-id d-9267898861 \
  --filters AttributePath=DisplayName,AttributeValue="AWS-Logging-SecurityAudit" \
  --region us-west-2 \
  --profile main

# Create the account assignment
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --target-id 038901680748 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --principal-type GROUP \
  --principal-id <identity-center-group-id> \
  --region us-west-2 \
  --profile main

After creating an account assignment, Identity Center provisions an IAM role in the target account. This takes 30–90 seconds. You can check status:

bash
aws sso-admin describe-account-assignment-creation-status \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --account-assignment-creation-request-id <request-id> \
  --region us-west-2 \
  --profile main

Existing Permission Sets ​

AdministratorAccess ​

  • Policy: AWS managed AdministratorAccess (arn:aws:iam::aws:policy/AdministratorAccess)
  • Session duration: 8 hours
  • Who has it: Rory (via the primary AWS admin Entra group)
  • Accounts assigned: All 7 accounts
  • Notes: Unrestricted admin. SCPs at the org level still apply (e.g., cannot disable org trail, cannot leave the org, no root-equivalent actions).

ReadOnlyAccess ​

  • Policy: AWS managed ReadOnlyAccess (arn:aws:iam::aws:policy/ReadOnlyAccess)
  • Session duration: 8 hours
  • Who has it: Kevin, Greg (DR Domain Admins who consume compliance reports and need visibility without modification rights)
  • Accounts assigned: Prod, Logging (at minimum — verify current assignments via CLI)
  • Notes: Good for read-only investigation and compliance report review.

PowerUserAccess ​

  • Policy: AWS managed PowerUserAccess (arn:aws:iam::aws:policy/PowerUserAccess)
  • Session duration: 8 hours
  • Who has it: Reserved for technical staff who need resource management but should not touch IAM. Not currently assigned to anyone — verify before granting.
  • Accounts assigned: None currently active — assign per-engagement
  • Notes: Full resource access except IAM, Organizations, and Billing. Good for developers or contractors who need to deploy but not manage permissions.

Custom Permission Sets ​

Check current inventory:

bash
aws sso-admin list-permission-sets \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

# Get details on a specific one
aws sso-admin describe-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

# List attached policies
aws sso-admin list-managed-policies-in-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

Auditing — Who Has Access to What ​

List All Account Assignments for a Specific Account ​

bash
# List all permission sets assigned to an account
aws sso-admin list-permission-sets-provisioned-to-account \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --account-id 807267566999 \
  --region us-west-2 \
  --profile main

# For each permission set, list who's assigned
aws sso-admin list-account-assignments \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --account-id 807267566999 \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

List All Accounts a Permission Set Is Assigned To ​

bash
aws sso-admin list-accounts-for-provisioned-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --region us-west-2 \
  --profile main

Full Access Matrix — Script It ​

The AWS CLI doesn't give you a single cross-account view. Use this pattern to build an access matrix across all accounts:

bash
INSTANCE_ARN="arn:aws:sso:::instance/ssoins-XXXXXXXXXX"
ACCOUNTS=(206820231356 863609217450 040067931468 414134953818 038901680748 238342914131 807267566999)

for ACCOUNT in "${ACCOUNTS[@]}"; do
  echo "=== Account: $ACCOUNT ==="
  PERMISSION_SETS=$(aws sso-admin list-permission-sets-provisioned-to-account \
    --instance-arn "$INSTANCE_ARN" \
    --account-id "$ACCOUNT" \
    --region us-west-2 --profile main \
    --query 'PermissionSets[]' --output text)
  for PS in $PERMISSION_SETS; do
    PS_NAME=$(aws sso-admin describe-permission-set \
      --instance-arn "$INSTANCE_ARN" \
      --permission-set-arn "$PS" \
      --region us-west-2 --profile main \
      --query 'PermissionSet.Name' --output text)
    echo "  Permission set: $PS_NAME"
    aws sso-admin list-account-assignments \
      --instance-arn "$INSTANCE_ARN" \
      --account-id "$ACCOUNT" \
      --permission-set-arn "$PS" \
      --region us-west-2 --profile main \
      --query 'AccountAssignments[].{Type:PrincipalType,ID:PrincipalId}' --output table
  done
done

CloudTrail Events for Identity Center ​

Identity Center API calls land in CloudTrail as sso-admin.* events in the Management account's org trail. The trail is in the Logging account (038901680748) → S3 bucket for archive, and forwarded to the central Log Analytics Workspace.

Key event names to watch:

EventWhat It Means
CreateAccountAssignmentAccess granted to an account
DeleteAccountAssignmentAccess removed from an account
CreatePermissionSetNew permission set created
PutInlinePolicyToPermissionSetCustom policy added to permission set
AttachManagedPolicyToPermissionSetManaged policy attached to permission set
AuthenticateUser authenticated via SSO portal
FederationUser assumed role in an account

CloudTrail query via AWS CLI (Logging account):

bash
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=sso-admin.amazonaws.com \
  --start-time "2026-05-01T00:00:00Z" \
  --end-time "2026-05-25T23:59:59Z" \
  --region us-west-2 \
  --profile logging \
  --query 'Events[].{Time:EventTime,Name:EventName,User:Username}' \
  --output table

KQL Queries in Log Analytics (If Forwarded to LAW) ​

If CloudTrail events are forwarded to cirius-logging-law-central (workspace ID 5d76d1f2), use these queries:

kql
// All Identity Center access grants in the last 30 days
AWSCloudTrail
| where EventSource == "sso-admin.amazonaws.com"
| where EventName in ("CreateAccountAssignment", "DeleteAccountAssignment")
| extend RequestParams = parse_json(RequestParameters)
| project TimeGenerated, EventName, UserIdentityArn,
    AccountId = RequestParams.targetId,
    PermissionSet = RequestParams.permissionSetArn,
    PrincipalType = RequestParams.principalType,
    PrincipalId = RequestParams.principalId
| sort by TimeGenerated desc

// Who authenticated through SSO in the last 7 days
AWSCloudTrail
| where EventSource == "sso.amazonaws.com"
| where EventName == "Authenticate"
| project TimeGenerated, UserIdentityArn, SourceIPAddress, UserAgent
| sort by TimeGenerated desc

// Permission set changes (any policy modification)
AWSCloudTrail
| where EventSource == "sso-admin.amazonaws.com"
| where EventName in (
    "CreatePermissionSet",
    "PutInlinePolicyToPermissionSet",
    "AttachManagedPolicyToPermissionSet",
    "DetachManagedPolicyFromPermissionSet",
    "DeleteInlinePolicyFromPermissionSet"
  )
| project TimeGenerated, EventName, UserIdentityArn,
    Params = parse_json(RequestParameters)
| sort by TimeGenerated desc

SCIM Sync Troubleshooting ​

When a user or group doesn't show up in Identity Center after an Entra change, work through this in order.

1 — Check Entra Provisioning Logs ​

Entra ID → Enterprise applications → [IAM Identity Center SCIM app] → Provisioning → Provisioning logs

Filter: Status = Failure, or search by the UPN. The logs show exactly what Entra tried to push and what Identity Center responded with. Common errors:

ErrorCause
400 Bad RequestAttribute mismatch — Identity Center requires specific attribute format
409 ConflictUser already exists in Identity Center with different external ID
403 ForbiddenSCIM token expired or wrong permissions
429 Too Many RequestsRate limit — Entra will retry automatically

2 — Trigger a Manual Sync Cycle ​

In Entra provisioning, click Provision on demand and enter the specific user. This runs an immediate sync for that user and shows the full SCIM payload and response — much faster than waiting for the scheduled cycle.

Alternatively, restart the provisioning job: Provisioning → Stop provisioning → Start provisioning (forces a fresh cycle).

3 — Verify the Group Is in SCIM Scope ​

Only groups explicitly added to the SCIM app's scope are synced. Check:

Entra ID → Enterprise applications → [IAM Identity Center SCIM app] → Provisioning → Edit provisioning → Mappings → Provision Azure Active Directory Groups

Under Target Object Actions, confirm the group filter includes the group you're trying to sync. If the group is not in scope, add it:

Users and groups → Add user/group (in the SCIM app, not in the Entra group itself).

4 — Check Identity Center Directly ​

After confirming SCIM pushed successfully, verify Identity Center received it:

bash
# Search for the user in Identity Center
aws identitystore list-users \
  --identity-store-id d-9267898861 \
  --filters AttributePath=UserName,AttributeValue=user@ciriusgroup.com \
  --region us-west-2 \
  --profile main

# Search for the group
aws identitystore list-groups \
  --identity-store-id d-9267898861 \
  --filters AttributePath=DisplayName,AttributeValue="AWS-Prod-AdministratorAccess" \
  --region us-west-2 \
  --profile main

# Check group membership in Identity Center
aws identitystore list-group-memberships \
  --identity-store-id d-9267898861 \
  --group-id <identity-center-group-id> \
  --region us-west-2 \
  --profile main

5 — SCIM Token Rotation ​

If you're seeing persistent 403 errors in the provisioning logs, the SCIM token may have expired or been rotated.

To generate a new SCIM token:

AWS console → IAM Identity Center → Settings → Identity source → Actions → Manage SCIM credential → Generate new token

Copy the new token and update it in Entra:

Entra ID → Enterprise applications → [IAM Identity Center SCIM app] → Provisioning → Admin Credentials → Secret Token → paste the new token → Test Connection → Save

6 — User Has Duplicate External ID ​

If a user was manually created in Identity Center (e.g., during an outage) and then SCIM tries to create them again, you get a 409 conflict. Resolution:

  1. In Identity Center, delete the manually created user
  2. Trigger an on-demand sync for that user in Entra
  3. SCIM will recreate the user with the correct external ID linkage

Break-Glass — If SCIM Is Down ​

If the Entra SCIM connection to Identity Center is broken and you need to grant emergency AWS access before it's repaired:

Option A — Manual User in Identity Center (Temporary) ​

This is a stopgap. Any manually created user must be deleted once SCIM is restored.

bash
# Create a user directly in Identity Center
aws identitystore create-user \
  --identity-store-id d-9267898861 \
  --user-name "emergency-rory@ciriusgroup.com" \
  --display-name "Emergency Rory" \
  --name FamilyName=Garshol,GivenName=Rory \
  --emails Value=rgarshol@gmail.com,Type=work,Primary=true \
  --region us-west-2 \
  --profile main

# Assign to a permission set in the needed account
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --target-id 807267566999 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --principal-type USER \
  --principal-id <new-user-id> \
  --region us-west-2 \
  --profile main

The user can then log in via the SSO start URL with the temporary credentials. Document this in SecOps as an incident. Delete the manual user within 24 hours of SCIM restoration.

Option B — AWS Root Account (True Break-Glass) ​

If Identity Center itself is broken (not just SCIM), use the AWS root account for the affected account. Credentials are in Keeper → "AWS Root — [Account Name]". The physical MFA token is required and is kept in the office.

AWS root bypasses all IAM and Identity Center. Use only for the minimum action required to restore Identity Center or IAM access. Sign out immediately after.

Any root account use triggers a CRITICAL incident in SecOps — do not suppress it.

See Break-Glass Procedure for the full root account activation checklist.

Option C — Existing IAM Role (If Any) ​

The devops-admin IAM user exists in the Management account for automated tooling that cannot use OIDC. Do not use it for interactive work during an Identity Center outage — its permissions are scoped to automation tasks, not admin access.

If you need cross-account access during an Identity Center outage, the OrganizationSecurityAudit role in each account can be assumed from the Prod account. This role is read-only — useful for inspection but not remediation.

Adding a New AWS Account to the Org and Identity Center ​

When a new account is added to the Cirius Group org, Identity Center does not automatically know about it — you have to wire it in manually.

Step 1 — Create or Accept the Account ​

Creating a new account in the org:

bash
# From the Management account
aws organizations create-account \
  --email new-account@ciriusgroup.com \
  --account-name "cirius-new-purpose" \
  --iam-user-access-to-billing DENY \
  --profile main

# Check creation status
aws organizations describe-create-account-status \
  --create-account-request-id <request-id> \
  --profile main

New accounts created within the org automatically land in the root OU. Move to the correct OU immediately — SCPs apply at the OU level.

bash
# List OUs to find the target OU ID
aws organizations list-organizational-units-for-parent \
  --parent-id <root-id> \
  --profile main

# Move the account
aws organizations move-account \
  --account-id <new-account-id> \
  --source-parent-id <root-id> \
  --destination-parent-id <target-ou-id> \
  --profile main

Step 2 — Enable Security Hub and CloudTrail in the New Account ​

The org CloudTrail trail covers all accounts automatically — no action needed there. Security Hub needs to be enabled explicitly:

bash
# Assume the OrganizationAccountAccessRole in the new account
aws sts assume-role \
  --role-arn arn:aws:iam::<new-account-id>:role/OrganizationAccountAccessRole \
  --role-session-name new-account-setup \
  --profile main

# Export temporary credentials from above, then:
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-west-2

# The Logging account (038901680748) is the Security Hub delegated admin
# Enroll the new account from the delegated admin:
aws securityhub create-members \
  --account-details AccountId=<new-account-id>,Email=new-account@ciriusgroup.com \
  --region us-west-2 \
  --profile logging

Step 3 — Assign Permission Sets to the New Account ​

This is what makes Identity Center aware of the account for access purposes.

bash
# Assign AdministratorAccess to the admin group in the new account
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-XXXXXXXXXX \
  --target-id <new-account-id> \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-XXXXXXXXXX/ps-XXXXXXXXXX \
  --principal-type GROUP \
  --principal-id <admin-group-id-in-identity-center> \
  --region us-west-2 \
  --profile main

Assign all permission sets that should apply to the new account. At minimum: AdministratorAccess for the admin group, ReadOnlyAccess for the read-only group.

Step 4 — Add an AWS CLI Profile for the New Account ​

Update ~/.aws/config on any workstation used for this account:

ini
[profile new-account-alias]
sso_start_url = https://d-9267898861.awsapps.com/start
sso_region = us-west-2
sso_account_id = <new-account-id>
sso_role_name = AdministratorAccess
region = us-west-2
output = json

Update AWS Account Access Guide with the new account alias.

Step 5 — Verify Access ​

bash
aws sso login --profile main
aws sts get-caller-identity --profile new-account-alias

The call should return the new account ID with the AdministratorAccess role name.

Step 6 — Tag the Root Resources and Enable Required Controls ​

bash
# Create the account alias for the console URL
aws iam create-account-alias --account-alias cirius-new-purpose --profile new-account-alias

# Enable AWS Config (required for Security Hub findings)
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::<new-account-id>:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig \
  --region us-west-2 \
  --profile new-account-alias

aws configservice put-delivery-channel \
  --delivery-channel name=default,s3BucketName=<central-config-bucket> \
  --region us-west-2 \
  --profile new-account-alias

aws configservice start-configuration-recorder \
  --configuration-recorder-name default \
  --region us-west-2 \
  --profile new-account-alias

Verify the new account appears in Security Hub findings in the Logging account within ~15 minutes of Config being enabled.

Document History ​

DateChangeAuthor
May 2026Initial draft — Identity Center architecture, user add/remove, permission set creation, existing permission sets, access auditing, SCIM troubleshooting, break-glass procedures, new account onboarding.Rory

Internal use only — Cirius Group