In order to reduce confusion between Azure AD and Windows Server AD, Microsoft changed Azure AD to Entra ID, marking the beginning of the Entra product family.
Microsoft renamed Azure AD (Azure Active Directory) to Microsoft Entra ID to convey the product's multi-cloud, multi-platform capabilities, alleviate confusion with Windows Server Active Directory, and integrate it into the Microsoft Entra product family.
This change makes sense because the AD people are familiar with is actually Active Directory Domain Services (AD DS). To put it simply, Azure AD only manages identities, while policies for devices joined to Azure AD are managed by Intune's Configuration Profile. In other words, the cloud version of AD is a combination of Azure AD + Intune. It was difficult to explain this concept to those who have been accustomed to the traditional AD model for a long time.
By rebranding it as Entra, Microsoft is positioning it as a comprehensive identity and access management platform. When you access the Entra Management Center, you'll notice that it offers more features than when it was known as Azure AD.
Let's take a closer look at Verified ID. We will start with the following technical resource:
First, the background for the emergence of Verified ID is as follows:
In today’s world, our digital and physical lives are increasingly intertwined with the apps, services, and devices we use. This digital revolution opens up a world of possibilities, allowing us to connect with numerous companies and individuals in ways previously unimaginable.
However, with this increased connectivity comes a greater risk of identity theft and data breaches. These breaches can have significant impacts on both our personal and professional lives. But there is hope. Microsoft, in collaboration with various communities, has developed a decentralized identity solution that enables individuals to control their own digital identity, offering a secure and private way to manage identity data without relying on centralized authorities or intermediaries.
-> The key here is the Decentralized Identity solution. To be honest, the other concepts are a bit difficult for me to explain in more detail at my current level. Looking at this… if I had deep-dived into identity management alone, I probably wouldn’t have any trouble making a living.
I think I need to test how to use this practically and eventually gain a better understanding through hands-on experience.
Lead with open standards
Microsoft has implemented the following standards:
W3C Decentralized Identifier
W3C Verifiable Credentials
DIF Sidetree
DIF Well Known DID Configuration
DIF DID-SIOP
DIF Presentation Exchange
-> This suggests that it's not only something used in M365 but is a concept that can be integrated with other systems, similar to SSO or in a different capacity.
What is DID (Decentralized ID)?
DID is an identity management system where individuals, not central authorities or corporations, have direct control over the ownership and management of their identity information.
It ensures the integrity and security of identity information through a decentralized network rather than relying on central servers or institutions. Distributed ledger technologies, such as blockchain, are typically used, with the goal of giving individuals full control over their identity information.
So, what is Microsoft Verified ID? My understanding is that it plays the role of the issuer, verifier, and intermediary (Role Modeler).
The content explained by each item in the diagram is as follows:
1. W3C DID (Decentralized Identifier) Number
- A unique ID.
2. Trust System
- It verifies and authenticates to check DID documents.
3. MS Authenticate App
- Serves as a digital wallet. You can think of it like a wallet where the user stores their ID cards.
4. Microsoft Resolver
- An API that uses the did:web method to query and verify DIDs, returning the DDO (DID Document Object).
5. Microsoft Entra Verified ID API
- A REST API for issuing and verifying W3C Verifiable Credentials, signed using the did:web method, through Azure’s issuance and verification services.
In order to cover this flow in detail, it seems necessary to build a concrete sample environment to fully understand it.
Once I’ve built a sample, posted about it, and gained a reasonable understanding, I will update this post accordingly.
The primary purpose of Conditional Access is to prevent company accounts from being accessed on personal devices. However, Conditional Access cannot prevent other company accounts from being accessed on company devices.
Of course, if a company device can access Naver Mail and Google Drive, it means the company is not very concerned about data leakage, and you may disregard this post.
To use M365, you need to open MS-related URLs such as office.com. Tenant Restriction is a concept used to prevent access with other company or personal accounts (such as outlook.com) during this time.
The Policy ID is generated as shown below. Make sure to copy each value and keep them.
To set up a blocking policy for external accounts, configure it as shown below (default settings).
To block all external apps, configure the settings as shown below.
Step 2: Enable tenant restrictions on Windows managed devices (preview)
In the technical documentation, there are guidelines as shown below.
Tenant restrictions V2 on Windows is a partial solution that protects the authentication and data planes for some scenarios. It works on managed Windows devices and does not protect .NET stack, Chrome, or Firefox. The Windows solution provides a temporary solution until general availability of Universal tenant restrictions in Microsoft Entra Global Secure Access (preview).
-> Although the content is difficult to understand, it can be interpreted as indicating that the feature will be provided in a different way in the future. Currently, it is in the preview stage.
Download the ADMX files for the latest Windows GPO policies.
Once installed, the policy files will be saved to the following location.
Depending on the method of policy deployment in AD, copy the PolicyDefinitions folder to the appropriate location with only the necessary languages. (This part of the policy is related to AD, so we will not cover it here.)
Run gpmc.msc on the Domain Controller (DC).
Create a policy in the Organizational Unit (OU) that you will use for testing. Right-click and select "Edit".
