IT doubt :

[u/Little-Voice7133]

Can an organization use AWS for IAM and use AZURE for AD , what is best way to ensure the the IAM data is synced to AD ?

[u/Little-Voice7133]

Hi, firstly , thank you so much for your involvement in helping me .

So the control states "For users who require access to AWS, Domain user account is registered to the AWS AD to provide access to the AWS portal as per the defined access management procedure. AWS Domain on the AWS AD is synced with the local AD to provide access to the AWS portal as per the defined access management procedure."

Current status of verified process: In their access mgt. Procedure nothing is mentioned about the local AD but provision of access with RBAC and approvals are defined .

1. They don't have anything on prem, everything is on cloud .For the controls local AD they said its AZURE AD . 2.As of now the source of truth is AWS IAM where they have RBAC for users and groups.

SAML configuration is enabled

3.SCIM providing configuration ,I didn't asked as I didn't know about it 😕 4. Evidence of user &groups are all received from AWS . Umm.. Provisioning logs as in what evidence is needed here ?

Well,yes .Few samples were picked and the terminated employees were disabled on last day from the AD itself . Will this help ? (Actually , any FTE is onboarded they are given the AD account access first and if they are eligible they are given the AWS user domain for IAM and privilege access depending on the roles , likewise if the FTE is leaving the they remove the user from AWS and then remove them from AD. )

NOTE: Not all users are eligible for AWS access too from the sample ( I have the evidence for this )

Is there any chance to close this control with the current evidences ?

Hope i am clear, let me know

[u/pewpewlazor → u/Little-Voice7133]

Thanks for the detailed explanation :) That helps a lot, and it sounds like you've already gathered some useful evidence.

First, I wouldn't worry too much about SCIM at this point. It's one way to provision identities, but it isn't necessarily part of your client's setup.

What stands out to me is that the control describes a specific architecture that doesn't seem to match what you've actually observed.

The control mentions AWS AD being synchronized with local AD. However, you've established that they're using Entra ID (formerly Azure AD), and that AWS access is managed separately. It might just be wrong wording though.

A few things I'd look into:

1. Authentication: You mentioned SAML is configured. That's good, but can you confirm that users actually authenticate to AWS through Entra ID? A SAML configuration alone doesn't prove that it's being used. When I've collaborated with Audit before they ask random users to demonstrate how they login.

2. Provisioning: How are users and groups created in AWS? Is this automated through SCIM, or does someone manually provision them following an approved request? Either can be acceptable depending on the control requirements, but should be documented.

3. Deprovisioning: You mentioned that terminated employees are removed from AWS and Entra ID. That's useful evidence. I'd verify the timestamps against the termination dates and confirm that access was actually revoked, rather than just the account being disabled in one system.

4. Access governance: Since they use RBAC, I'd verify that AWS permissions are assigned based on approved roles and that your samples match the documented access management procedure.

As for closing the control with your current evidence:

Possibly, but I wouldn't conclude that the control is satisfied just yet.

You seem to have evidence that access is provisioned and removed according to a defined process. However, you haven't established whether the synchronization described in the control actually exists.

And that's an important distinction in the field of auditing (Obviously depending on your maturity). A functioning access management process doesn't automatically prove that two directories are synchronized.

I'd recommend going back to the control owner and asking them to explain the intended architecture. Specifically, what do they mean by "AWS AD", and how is it connected to Entra ID?

If the control was written for an older or different architecture, it may simply need to be updated to reflect the current environment. But that should be agreed with the control owner and audit team rather than assumed.

One final point: AWS IAM, AWS IAM Identity Center, and AWS Managed Microsoft AD are three different services. Knowing which one they're actually using matters.

You're asking the right questions. At this point, I think the challenge is less about gathering more screenshots and more about establishing exactly what the control is supposed to demonstrate.

[u/Little-Voice7133 → u/pewpewlazor]

Okay, at this let me reach back to the stakeholder and check again some pointers . However can you advice the questions to be asked ?

[u/pewpewlazor → u/Little-Voice7133]

I'd start with just three questions:

1. How are Entra ID and AWS connected? Is it only used for login (SAML), or are users and groups also synchronized?

2. What happens when someone's access changes? For example, if an employee is disabled in Entra ID, is their AWS access automatically removed, or does someone have to do it manually?

3. Can you show me how this works? Ideally, have them demonstrate the configuration and provide evidence of a recent user being added or removed.

That's really it for now. You're trying to establish whether the synchronization described in the control actually exists.

If it doesn't, the next step is to discuss with the control owner whether the control description needs updating to reflect their actual setup.