Microsoft Entra ID Continuous access evaluation and how it works!
Dear Microsoft Entra ID Friends, In this article, we take a closer look at Microsoft Entra ID continuous access evaluation. What is Microsoft Entra ID Continuous access evaluation (CAE)? https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation How should CAE support us? Microsoft Entra ID continuous access evaluation is a feature that helps to improve the security and resilience of cloud applications. It allows Microsoft Entra ID to issue access tokens that are valid for a longer time, but can be revoked immediately if there is a change in the user account or the tenant policy. This way, applications can enforce the latest security policies without relying on the expiration of the access tokens. For example, if an administrator disables a user account or changes the IP address range for accessing the application, the existing access tokens for that user will be invalidated and the user will have to reauthenticate with Microsoft Entra ID. This reduces the risk of unauthorized access and also reduces the number of token requests, which makes the application more resilient to network issues. Build resilience by using Continuous Access Evaluation https://learn.microsoft.com/en-us/entra/architecture/resilience-with-continuous-access-evaluation Revoke access in (near) real time with Continuous Access Evaluation Continuous Access Evaluation (CAE) allows Microsoft Entra applications to subscribe to critical events that can then be evaluated and enforced. CAE includes evaluation of the following events: User account deleted or disabled Password for user changed MFA enabled for user Administrator explicitly revokes a token Elevated user risk detected Let's examine CAE on the example of a connection with Microsoft Graph. Lets start with the following scenario: In the PowerShell ISE we create a connection with Microsoft Graph and in the background we record it all with the Fiddler tool. In the Fiddler tool we copy the access token: Now we can decode the access token on the web page https://jwt.ms/: We can see that the access token is valid for approximately 24 hour: With the fiddler tool we can see that the microsoft graph is continous access evaluation aware: Now lets generate an event that will revoke the access token: Back in the PowerShell ISE we can see that the access token is no longer valid (Request for re-authentication): In the Fiddler tool we can see that the access token is no longer valid: The exact info from Fiddler: I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on GitHub! https://github.com/tomwechslerActive Directory Vs Azure Active Directory
Active Directory (AD) and Azure Active Directory (AAD) are both identity management solutions from Microsoft, but they serve different purposes. In this blog post, we’ll explore the differences between AD and AAD and when you might want to use one over the other. Active Directory (AD) Active Directory is a service provided by Microsoft that is used to manage users, computers, and other resources in a Windows-based network. It was first introduced in Windows 2000 and has since evolved into the core identity management solution for most organizations that use Windows-based systems. AD is a domain-based directory service, which means that it is designed to work within a single organization’s network. AD stores user and computer account information, authentication and authorization data, and security policies. It also provides services such as Group Policy, which allows administrators to configure and enforce policies for users and computers in the domain. AD is typically deployed on-premises and requires a domain controller to operate. Domain controllers are servers that store and manage AD data and provide authentication and authorization services to users and computers in the domain. Azure Active Directory (AAD) Azure Active Directory is a cloud-based identity management solution that is used to manage users and groups, control access to cloud-based applications, and integrate with other cloud-based services. It is a multi-tenant directory service, which means that it can be used by multiple organizations at the same time. AAD provides many of the same features as AD, such as user and group management, authentication and authorization, and security policies. However, AAD is designed to work with cloud-based applications and services, and it does not require a domain controller. AAD is often used in conjunction with other cloud-based services, such as Office 365, Azure, and other SaaS applications. AAD provides a single sign-on (SSO) experience for users, which means that users only need to log in once to access all of the cloud-based applications and services that they have access to. When to use AD vs AAD AD is still the go-to solution for managing identity and access in on-premises Windows-based networks. If you are running a Windows-based network and you need to manage users, computers, and other resources within your organization, then AD is the right choice. AAD is best suited for organizations that are using cloud-based services and applications. If you are using Office 365 or other cloud-based services and you need to manage users and control access to those services, then AAD is the right choice. It is also possible to use both AD and AAD in a hybrid environment. In this scenario, AD is used to manage on-premises resources, while AAD is used to manage cloud-based resources. This allows organizations to maintain a consistent identity and access management strategy across their on-premises and cloud-based environments. Active Directory and Azure Active Directory are both powerful identity management solutions, but they serve different purposes. AD is designed for on-premises Windows-based networks, while AAD is designed for cloud-based services and applications. Depending on your organization’s needs, you may choose to use one or the other, or a combination of both in a hybrid environment.Double entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?
Unable to add Azure Virtual Desktop Client Enterprise App to Conditional Access
We currently use conditional access to allow certain contractors to sign into VMs, and from these VMs, access other MS Apps. Currently we block all applications from outside the VM ip range, but exclude the Virtual desktop applications to allow the users to do the initial signin to the VM. When contractors are using the Virtual Desktop app, it seems to work ok. However, recently when signing in via the browser only and launching from there, the conditional access rule is blocking them as the application ID isn't in the exclude list, and we are unable to add it: a85cf173-4192-42f8-81fa-777a763e6e2c The documentation: https://learn.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa?tabs=avd shows that web signins may originate from this application ID, but without the ability to add this to the exclusion apps, we cannot find another workaround that allows access via the browser. I also tried adding this app in to the policy via GraphAPI, but I get an error saying that this first party application isn't allowed. I need to know if there is another workaround or if Microsoft are planning to add this to the CA compatibility list? I'm not sure why some of the Virtual desktop apps are there but this one is not.Questions about moving Windows endpoint from locally joined domain to Azure AD
Just a couple questions, when moving a current AD domain joined endpoint (i.e. Windows 10/11 Pro) to Azure AD. 1. Does the user's desktop look/feel change upon their next Azure AD-centric login, versus their previous domain joined profile? 2. If there were previously changes pushed out to the endpoints via local AD Domain GPOs, do those changes still remain on the endpoint machine, even after the cutover to Azure AD? 3. Is there a way to have an Azure AD authenticating machine, while still allowing the machine to access local network SMB shares, if the Azure AD and Local AD domain are in hybrid mode?
Azure AD extension attributes from AD Connect
I'm struggling with finding my data in AAD. We've been running Azure Connect for years to bring the data from our on-prem AD over to our AAD instance. Back last spring, I expanded the scope of the fields we were bringing over; in Azure Connect I configured it to also send the uid from AD, where we were storing a value that I needed for SSO for a specific application. I was able to configure the claims rules for the enterprise application that I configured in AAD to send the value along to the app, and SSO works fine. My problem is where that data is. I'll be referring here mostly to Powershell commands to look at the users. If I run a Get-Azureaduser a user -- I've tried several, all who can successfully use the SSO -- then pipe that along to select to expand the extension properties, the extension property isn't even in the list. The one place I have found it is if I run Get-AzureADApplication | Get-AzureADApplicationExtensionProperty It is in the list of defined extension properties, targetting users. Ideally, I'd like to be able to see the value for a given user from AAD, and set it through Powershell as well. Help? Why doesn't it show up in the extension attributes for our users?
New Blog | Microsoft Entra ID named leader in KuppingerCole’s Access Management Leadership Compass
For the second year in a row KuppingerCole has recognized Microsoft Entra ID as an Overall Leader in the 2023 Leadership Compass for Access Management. This is the highest distinction that KuppingerCole grants to an identity and access management solution, writing that “Microsoft continues to move Microsoft Entra ID in a positive direction with innovative capabilities” while awarding us a 5/5 rating in the categories of: security, functionality, deployment, interoperability, and usability. Additionally, Entra ID has been designated as a Product Leader, Innovation Leader, and Market Leader within the segment. Read the full update here: Microsoft Entra ID named leader in KuppingerCole’s Access Management Leadership Compass - Microsoft Community Hub
Migration FSR to DFSR stuck at level 3 due PDC crash
Hi all, I'm a nb for this level ov AD operations... We have two mandatory goals: 1- raise the domain from 2012 to 2019 or 2022 2- change actual old PDC hardware with a new one The first steps they looked at promote DC, demote PDC, PDC roles transferred from old to the virtual machine DC, all without visible errors. At the moment of the migration from FSR to DFSR, the old hardware PDC has unrecoverably crashed at logical or/and hardware level in the middle of migration at operation 3 that not consent rollback. Due this the migration is now stucked at 'Preparing' State - Primary DC. We have tried many attempts among wich: - restore backup on PDC hw crashed but without success - retore backup of othe DC throuh wich we have seen the condition of inconsistency indicate below. Some elemente of the environment: - original domain is composed by 1 harware PDC and 2 virtual machine with DC roles in SAN VMWare. We not hawe RODC. - I cannot recover the PDC from backup due hardware issues. - The second and third DC has inconsistent state of replication despite all system message they were correct and whithout errors. - DNS work properly The last chance was create a new virtual DC, promote this and apparently it synced with the other DC but SYSVOL is empty and the level of DFSR results FRS on old DC and DFSR on new virtual DC with obviously inconsistency of SYSVOL. At this moment the old virtual DC hold up the entire domain base on populated SYSVOL and FSR service. If i stop this service and start DFSR service, FSR run 2 minute and stoppping. Afther this SYSVOL desappear sharing It does not work anymore. IT's sufficient stop DFSR and start FRS and SYSVOL apparently work but non replicate in new virtual DC. Do you have any suggestion to unlock the FSR-->DFSR migration? Thanks a lot. Massimiliano
How to use AD Log On To restriction but allow Azure AD Pass-Through Authentication
As the title says I am attempting to utilize the "Log On To..." setting in on-premises AD but still allow users to log onto Azure AD authenticated resources such as Office 365. The test accounts can log into only the specified workstation when the setting is enabled. Which is the expected outcome but when this is enabled and the user attempts to log into anything that authenticates via Azure AD, the authentication fails with "Pass-through Authentication" Succeeded: "False". This totally makes sense but I am required to lock down user account(s) to specific computers and still allow Azure AD Authentication for these same users. Is this even possible without going through group policy which gets messy when you only want certain user accounts on certain machines.
