Azure AD account vs On-premise AD account

Account in Active Directory (AD) and account in Azure AD (AAD)

Here AD is being referred to as the on-premise AD and Azure AD (AAD) is the cloud based Active Directory. Here are two scenarios of user accounts. 

The AAD user accounts are called as M365 accounts that are required to access MS services in the cloud, like M365 tenants, Exchange online mailboxes etc.

Scenario: You only have Azure AD account, and an Exchange online mailbox. In this scenario how are the credentials synced.

There is no syncing. Azure AD account acts as the single identity source for accessing both Azure AD and Exchange Online.

The Azure AD account is the authoritative source for your identity and credentials. When you are assigned an Exchange Online mailbox, it is linked to your existing Azure AD account.

Your Azure AD credentials (username, password) are used to authenticate and access both Azure AD and your Exchange Online mailbox.

There is no synchronization of credentials happening because the Azure AD is the cloud identity provider, and Exchange Online leverages the same Azure AD identity for mailbox access. Note: Your single set of Azure AD credentials provides access to all Microsoft 365 services, including Exchange Online mailboxes.

Scenario: You have an on-premises AD account and another account in Azure AD. How are these two accounts synched?

Your on-premise AD account is the authoritative source for your user identity and credentials. Azure AD Connect synchronizes your on-premise AD account, including the username, password hash, and other attributes, to your existing Azure AD account. To match and link the on-premises AD account to the existing Azure AD account, Azure AD Connect performs a "soft match" by comparing the userPrincipalName (UPN), primary email address (mail attribute), and proxyAddresses attributes between the two accounts. If the soft match fails, you may need to perform a "hard match" by modifying the on-premises Azure AD's objectGUID to match the immutableID of the Azure AD account. Once matched, any changes to your on-premises AD account (e.g., password updates) will be synched to the linked Azure AD by Azure AD connect. 

Notes: Difference between Soft Match and Hard Match

Soft Match: match on UPN Email and proxyAddress. This is easier to implement if you have a lot of users that need to be synced with Azure AD.

Hard Match: match on immutable ID. This requires several steps and no easy way to implement this for multiple users.

The sync happens from AD to Azure AD. Not in the reverse direction.

Check the AD attributes ProxyAddress and UPN before starting the sync.

Comments

  1. OncourseDecember 16, 2024 at 12:40 AM

    Understanding the difference between an Azure AD account and an on-premise AD account is crucial for managing access and security. If you're looking for seamless integration and support, Club Hosty offers solutions that can help bridge the gap between these two types of accounts.

    ReplyDelete

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Image
Recently we got a OVA file for a virtual machine. The vendor instructions were to import the ova file in vmware Workstation, Player for Windows/Linux, Fusion for Mac, and VirtualBox as well.  The instructions were to take the available package and launch the VM with VMware workstation. The package contained  Module.mf, Module.ovf and Module-disk.vmdk and a Module.ova file. The .mf and .ovf file were 2 KB each whereas the vmdk was several gigs. The package also contained a Module.ova file which was several gigs as well. OVF           Open Virtualization Format MF             Manifest file VMDK       Virtual Machine Disk OVA           Open Virtualization Appliance The ovf file is a xml file that contains metadata for the ovf package The mf file contains the SHA1 hash codes of all files in the package The vmdk file is the disk image of the virtual mac...
Read more

Session Timeout in Oracle Access Manager

Image
Session Timeout in Oracle Access Manager (OAM) The session lifetime and Idle timeout entries control how long a user's session is valid. In OAM, a user session is an object which represents an authenticated user. This object is stored in the server memory and if Database session persistence is enabled, this object is stored or available in the database. Each session is unique and is identified by both a userid and Session ID (session identifier), see screenshot below "OAM User Session Management".  A valid session means a user has been authenticated with OAM. A session can have following three states: 1) active 2) inactive 3) expired When a session is created it is in active state and is available as an object in the OAM. After a set time - idle timeout, the session moves or transitions to inactive state. And finally after the Session Lifetime time, the session is marked as expired. Expired sessions are removed from server memory. Read more about Session Lifetime ...
Read more

SOAPUI - import certificate

Image
Note: SoapUI has two versions, one is open source and second Professional version. The open source can be download here . (confirmed link 12/19/2018). SSL Handshake issue:   There is an Issue in SoapUI version 5.3.0 (and 5.2.0 version) with SSL handshake error. It was resolved by updating below in vmoptions file ( refer here ). However, the error that shows up while trying to load wsdl is "Error loading WSDL" as below The fix is to Enable TLS 1.2 protocol for SOAP/REST calls in SoapUI, by ammending the vmoptions file to add the directive for TLS as (-Dsoapui.https.protocols=TLSv1.2). Refer here . Update: Version 5.5.0 does not have this issue. If you are on 5.3.0 better upgrade to 5.5.0 which is available now (Feb 2019). I had above issue as well as another issue reaching to https endpoint. Upgrade to 5.5.0 resolved issue. Select "Check for updates" under the Help menu and you will get option for upgrade. Select upgrade current version and accept all defaul...
Read more