Join Merill Fernando and other guests for our Identity and Network Practitioner Webinar Series!
This October, we’re hosting a three-part webinar series led by expert Merill Fernando for Identity and Network Access practitioners. Join us as we journey from high-level strategy to hands-on implementation, unifying identity and network access every step of the way. Each session builds on the last, helping you move from understanding why a unified approach matters to what are the foundations to get started, and finally to how to configure in practice. The goal is to equip you with actionable skills, expert insights, and resources to secure your organization in a unified, Zero Trust way. Register below: Identity and Network Security Practitioner Webinar Series | Microsoft Community Hub
API-driven provisioning field mapping changes resynchronize all users and groups
We have configured API-driven provisioning for on-premises Active Directory, along with Azure AD Connect, to synchronize on-premises AD users with Azure Entra ID. As part of the provisioning setup, we have used a separate Organizational Unit (OU) in on-premises AD (designated as the default OU for new users) while configuring API-driven provisioning. We are attempting to make some changes to the API field mapping, specifically the ‘UserPrincipalName’ regular expression (custom domain) and the ‘manager’ field, and saving the configuration. Upon attempting to save, a prompt appears (as highlighted below screenshot), indicating that this action will resynchronize all users and groups. Could you please clarify: Will this resynchronization update any existing users outside the default provisioning Organizational Unit (OU)? Specifically, what does the resynchronization operation update? For instance, will it modify the 'UserPrincipalName' and 'manager' attributes for all users including old users outside of provisioning Organizational Unit (OU)? Screen Shot - While Saving Mapping.
Microsoft Entra Connect connecting always to old DC
We are planning on demoting old DC server. When doing checkups I noticed that Entra Connect keeps connecting to this specific DC we'ew planning to demote everytime it connect to Active Directory. So now I'm wondering does this need any additional configuration to keep sync working after DC Demote. I found out that there is option to "Only use preferred domain controllers" but I'm not sure if that's what I want do do. There were the red line is is the old DC to be demoted. "Only use preferred domain controllers" setting. If I enable this setting I got this kind of notice. I don't feel like this is the right way to do it so I canceled at this point.
The salt sizes required for signing with RSAPSS do not match those used by TPM.
Good evening everyone. I'm getting this error when I try to perform the first sync on my Windows Server 2022. I'm trying to sync the entire directory to manage my employees' licenses. I already have a tenant with users who can stay there without any problems. I had already synced the tenant with my old server in the past. For business reasons, the infrastructure has changed, and so has the server. In Entra ID, I don't see any old syncs, but in Admin Center, I do. Could this be the problem? Any advice is invaluable, as I'm at my wits' end.
User Identities in EntraID - how to remove?
I have a user that shows up with multiple identities. No other users are like this and we believe its stopping him from logging in with his alias email address. When i run get-entrauser it returns the following under Identities: {@{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} Every other account just has this @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} How would i go about removing those identies from that user? Struggling to find any info online.
Understanding Sign-In logs - password hash sync from another country?
Gday Had a couple users show up today at risk - failed logins from the US, while we're in Canada. Users are not in the US, not using VPNs, logins are to Microsoft services (Office Home, One Outlook Web). The useragent is the axios client, the auth method is 'password in the cloud' - which as i understand it, means the password is being auth'd directly against Entra. However, one of them is Azure AD sync'd. The auth method on this is 'password hash sync' - as I understood it, this means the password is going to the DC first, then the resulting hash is being passed to the cloud. This is what we have on our Hybrid 1-way tenants. But I don't really understand what's going on when I see a Password Hash Sync attempt, from another country. Is that random person passing a (wrong) password to my closed-off server? Or... is it just that the hash that Entra has to authenticate with, is from the DC? Is the 'password to DC, to Cloud' the 'passthrough' auth method? Thanks
Entra ID Connect cloud sync: User and group sync is quarantined
Hi, I connected our on-premise AD with Entra ID with Azure AD Connect Cloud Sync. Agents are active, but User and group sync is quarantined with the following error. Error code: HybridSynchronizationContainerStateEnumerationFailed Error message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.... Additional details: Encountered an error while enumerating container changes in the provisioning agent. Please make sure you are running the latest version of the agent. Contact support if the issue persists. Additional Error Details: UnwillingToPerform: The server cannot handle directory requests.. ResultCode: UnwillingToPerform, HResult: -2146233088, responseType: System.DirectoryServices.Protocols.SearchResponse, serializedResponse: {"MatchedDN":"","Controls":[],"ResultCode":53,"ErrorMessage":"error in module dsdb_paged_results: Unwilling to perform during LDB_SEARCH (53)","Referral":[],"References":[],"Entries":[],"RequestId":null}. I use SaMBa servers (4.19.4) as DCs. Agents are installed on Windows 2019 servers. How can I resolve the problem?Control "preferredLanguage" for local AD synced accounts
We got a single tenant for several branches around the world. There is a single forest, single domain with Entra ID Connect in place. In AD the properties of the user accounts that are related to user location are populated according to this standard: branch AD attribute c AD attribute co AD attribute countryCode AD attribute msDS-preferredDataLocation Switzerland CH Switzerland 756 EUR Germany DE Germany 276 DEU Italy IT Italy 380 EUR Netherlands NL Netherlands 528 EUR Poland PL Poland 616 EUR UK GB United Kingdom 826 EUR US US USA 840 NAM There is a Entra ID user attribute called "preferredLanguage". This is not set for most of our users. How could we solve this? Which attribute in local AD do we have to use? Do we need to change anything in Entra ID Connect? Hopefully someone could give advice and the information needed to achieve being able to configure the Entra preferredLanguage for our synced users out of our local AD. Thanks in advance!
