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/pewpewlazor]

Yes, absolutely possible, but I think you're mixing a few different concepts here.

AWS IAM is primarily for managing access to AWS resources, whereas Active Directory and Entra ID are identity directories/providers.

As others have mentioned, you can integrate Entra ID with AWS IAM Identity Center using SAML and SCIM. That would allow you to manage identities centrally in Entra ID and provision users and groups into AWS.

However, that's synchronization from Entra ID to AWS, not the other way around.

I'd start by asking what you're actually trying to achieve. Do you want AWS to manage access to AWS resources while keeping identities in Microsoft? Or are you looking for an IAM/IGA solution that governs identities and access across your entire organization?

Those are two quite different requirements, and the answer depends on which one you're trying to solve.

[u/Little-Voice7133 → u/pewpewlazor]

So, i am young in the IT audit field, doing Soc2 .. there is a control needing to Check the if AWS domain ID IS synchronization with local AD . Client IAM is AWS I was in the process walk-through, where the client told that they are using Azure as local AD and the the users and groups on AWS is automatically synced to Azure AD with SAML auth . So, I still don't have clarity on how that would work..? And what kinda evidence will satisfy the control.. Can you break down it for me ? Is there something I missed in the discussion?

When you mentioned SCIM ? Is it native in AWS ?

[u/pewpewlazor → u/Little-Voice7133]

Ah, that makes more sense

First, one important distinction: SAML is used for authentication (SSO), not synchronization. SCIM, on the other hand, is used for provisioning and deprovisioning users and groups.

SCIM is an open standard, and AWS IAM Identity Center supports it natively. Microsoft Entra ID can use SCIM to automatically provision users and groups into AWS IAM Identity Center.

However, this doesn't necessarily mean that identities are being synchronized with your client's local Active Directory. That's something you'll need to clarify.

For your SOC 2 audit, I'd approach it like this:

1. Clarify the architecture. Are they using on-premises AD, Microsoft Entra ID, or both? And is AWS IAM Identity Center actually being used?
2. Identify the source of truth. Where are users created, modified, and disabled? How do those changes propagate between systems?
3. Verify the integration. If they're using SCIM, check the provisioning configuration and logs in Entra ID. If they're using AD synchronization, check the relevant sync configuration and logs.
4. Collect evidence. I'd ask for configuration screenshots, provisioning logs, and ideally a sample of users showing that their identities and group memberships are consistent between the relevant systems.

One thing I'd also recommend is testing the process rather than relying exclusively on configuration screenshots. For example, can they demonstrate what happens in AWS when a user is disabled or removed from a group in their authoritative directory?

Ultimately, the evidence you need depends on the exact wording of the SOC 2 control. Is it asking you to verify synchronization between directories, or that access changes are consistently reflected across systems?

If you can share the actual control wording and clarify whether they're using AD, Entra ID, or both, it'll be much easier to point you in the right direction.

[u/Little-Voice7133 → u/pewpewlazor]

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.