Difference between Microsoft Entra ID and Entra Domain services

Question

Hello,

I need some help to understand the difference between Azure Active Directory Vs Azure Active Directory Domain Services (AD DS).

Please check:

Azure Active directory is now Microsoft Entra ID.

1. Is Azure Active directory domain service now Microsoft Entra Domain service?
2. If data is replicated from Microsoft Entra ID to Entra Domain service, we don't use Entra connect sync. Then what is used or how is it replicated?
3. In the module, for benefits of Microsoft Entra Domain services, it says 'Admin doesn't need to deploy and manage Active directory replication' - does this mean - all users, group, accounts created in Microsoft Entra ID won't need to be manually replicated - so is the replication same as question 3?
4. Entra DS now supports a two-way trust. Is this correct?
5. Is Microsoft Entra Suite same as Microsofot Entra Tenant?
6. I logged into the Admin side and got this for my Entra ID:

When I click user sign-ins (non-interactive), I get many other resources displayed:

What are these - IAM supportability, Azure portal RP etc.

Thank you

Best regards

marouf

Answer 1

1. Is Azure Active Directory Domain Services now Microsoft Entra Domain Services? Yes, Azure Active Directory Domain Services (AD DS) is now referred to as Microsoft Entra Domain Services (Entra DS) as part of Microsoft's rebranding of its identity-related products under the "Microsoft Entra" suite.

---

2. If data is replicated from Microsoft Entra ID to Entra Domain Services, what is used? Data is replicated from Microsoft Entra ID to Microsoft Entra Domain Services automatically. This process does not require tools like Azure AD Connect because:

• Entra DS acts as a managed service and uses an internal, proprietary synchronization mechanism to replicate data (users, groups, and credentials) from Microsoft Entra ID.
• This replication includes password hashes (in a format suitable for NTLM and Kerberos authentication) to allow traditional domain-based authentication.

You do not have to configure or manage this synchronization manually; it is handled by Microsoft.

---

3. Does "Admin doesn't need to deploy and manage Active Directory replication" mean replication happens automatically from Microsoft Entra ID? Yes, that's correct. When the documentation states that "Admins don't need to deploy and manage Active Directory replication," it means:

• Users, groups, and accounts created in Microsoft Entra ID are automatically synchronized to Microsoft Entra Domain Services without requiring manual effort.
• This is part of the managed nature of Entra DS. The service ensures that changes in Microsoft Entra ID are reflected in Entra DS without admin intervention.

So, the replication here is the same as in Question 2—it's automatic and handled by Microsoft.

---

4. Does Entra DS now support a two-way trust? No, as of now, Microsoft Entra Domain Services supports only one-way trust with on-premises AD:

• One-way outgoing trust: On-premises Active Directory trusts Entra DS.
• One-way incoming trust: Entra DS trusts on-premises Active Directory.

This limitation means you cannot establish a true two-way trust between Entra DS and an on-prem AD environment. You would need a traditional on-prem Active Directory setup for full two-way trust functionality.

---

5. Is Microsoft Entra Suite the same as Microsoft Entra Tenant? No, they are different:

• Microsoft Entra Suite: Refers to the collection of identity-related products and services under the Microsoft Entra branding, such as Entra ID, Entra Domain Services, Entra Verified ID, and others.
• Microsoft Entra Tenant: Refers to the individual Microsoft Entra ID instance (formerly Azure AD tenant) associated with your organization. It’s the directory tied to your subscription and resources.

---

6. What are the resources listed under user sign-ins (non-interactive)? When you view non-interactive user sign-ins in the Entra ID (Microsoft Entra ID) portal, the resources displayed (e.g., IAM supportability, Azure portal RP) represent:

• Applications and services accessed by the user or service principal during non-interactive sign-ins. These are often background tasks or system-level operations that do not require user interaction, such as:
  • Token refreshes.
  • API calls from applications.
  • Authentication of services using service principals.
• Examples:
  • Azure Portal RP: The "Resource Provider" for the Azure Portal itself, enabling users to interact with portal features.
  • IAM Supportability: Likely refers to identity-related tools or diagnostics being accessed in the backend.

These entries are part of normal operations and indicate which resources or applications are leveraging non-interactive tokens issued by Entra ID.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin