identity protection
78 TopicsAnomalous Token & activity from Microsoft
Hi, I am trying to understand the following activity. I have had a few users in my organization flagged as a "Risky User" due to an anomalous token. This is normally supposed to flag if a users session token is stolen and replayed. Upon investigating the flagged sign ins, the IP addresses used for these are within Microsoft's Exchange Online IP range. https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide 52.96.172.x It is also common to see these as non-interactive sign ins. I am trying to understand why there would be a sign in from a Microsoft Exchange Online IP address to one of our accounts that would be attempting to use a token from a users client as per the error message reported? Is there a service running in Exchange Online I am not aware of that signs in on the users behalf? Why would it be using a token granted to a users device? I have also noticed consistent activity from these IP addresses in Cloud App Security. Any help or clarification would be greatly appreciated! Kind Regards, Jacques78KViews2likes1CommentExcessive MFA prompts for a specific user
One specific user in my tenant is prompted for MFA multiples times/day. Our conditional access policies specify that a user must re-authenticate every 90 days with MFA. All other users do not get prompted daily without a new risk factor like new device/unknown IP address. I have tried the following: Re-registered authentication methods and revoked previous multifactor auth sessions. Enabled Multifactor Authentication in Security Defaults for this user (Rather than conditional access) Exempted this user from the standard CA policy, and created a new one. None of these steps have helped. Microsoft support was no help. Some other information: This user uses 1 to 2 IP addresses throughout the week. (Home and office) This user is using the same devices every day. We have replaced the devices and issue persists. There are at least 1, up to 5 prompts daily. No other users are experiencing this issue, and MFA behaves as expected. Azure Identity Protection lists the risk for this user as none. Zero risk detections within the last 90 days. Any suggestions are appreciated.13KViews0likes7CommentsAchieve higher security with certificate bindings - How it works!
Dear Microsoft Entra friends, In this article I would like to take a closer look at the subject of certificate affinity binding. So that even more security can be applied during authentication. Let's start with a few links to the Microsoft documentation pages. Overview of Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication How to configure Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication Microsoft Entra certificate-based authentication technical deep dive: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive What does it mean "Achieve higher security with certificate bindings"? Microsoft Entra ID, formerly known as Azure Active Directory, is a cloud identity and access management solution that controls application access and protects identities. The term “Achieve higher security with certificate bindings” refers to a feature of Microsoft Entra ID that enhances user authentication security. This feature is part of the certificate-based authentication (CBA) process. Certificate bindings refer to the methods used to bind a certificate to a user’s identity, enhancing the security of the authentication process. There are seven supported methods for certificate bindings. These methods are considered high-affinity if they’re based on identifiers that can’t be reused, such as Subject Key Identifiers or SHA1 Public Key. This way, Microsoft Entra ID provides a secure and efficient way for users to authenticate and access applications. Let's examine achieve higher security with certificate bindings. Object Identifiers (OID): First we look at the certificate template on the certificate server (sorry some print screens are in German). Here we see the details of the Object Identifiers (OID). Add a new rule: Configure an additional rule in the Entra ID Admin Center and use the same Object Identifiers (OID) value here as in the certificate template. Subject Key Identifier (SKID): The certificate was issued on the user's system. We obtain the subject key identifier (SKID) from this certificate. We need this value in the Entra ID Admin Center to assign it to a person. The same person for whom the certificate was issued on the system (in my case it is Tina Fluenza). Authorization info: In the Entra ID Admin Center, we now set the value of the Subject Key Identifier (SKID) for the user in the properties. Note: Please pay attention to the syntax (X509:\<SKI\>a8052e8485eb17d865ba5d5ff0f7b326234f2860) Entra ID Sign-In Logs: "Tina Fluenza" has now registered on the portal https://myapps.microsoft.com and selected the certificate during the application process. This information can be found in the Entra ID Admin Center in the sign-in logs. With the confirmation of MFA by the claim in the token. HAPPY BINDING! I hope this information was helpful to you. I would like to thank you for your interest and 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/tomwechsler7KViews2likes0CommentsHow to correctly implement Entra ID Connect sync when users exists in Entra ID as cloud users?
Hi Everyone, I have a small on-premises exchange server 2016 setup which we're planning to make Hybrid. We do have a O365 environment (Business Standard Licensed) which is independent as users signed in for Teams and SharePoint Online usage. We now have to implement Entra ID Connect (Azure AD Connect) to facilitate Exchange Hybrid deployment. My questions are: 1. These users currently exists in Entra ID as cloud accounts (as they've been using Cloud Apps such as Teams, SPO with their Windows 10 joined to Entra ID) will there be any issues when sync is configured ? (i.e. duplicate of identity errors etc..) 2. What's the best approach to implement Entra ID Connect and sync these user from AD to Engtra ID without having to remove these accounts from Entra ID? Any inputs are highly appreciated ! Thank you!6.1KViews0likes2Commentsunable to run Update-AzureADSSOForest
Dear All, We encounter an issue with update-azureadssoforest it prompt below errro, need help Update-AzureADSSOForest : one or more error occurred。 所在位置 行:1 字符: 1 + Update-AzureADSSOForest + ~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Update-AzureADSSOForest], AggregateException + FullyQualifiedErrorId : System.AggregateException,Microsoft.KerberosAuth.Powershell.PowershellCommands.UpdateAzureADSSOForestCommandSolved4.5KViews0likes2CommentsHow to bring two Entra ID tenants together for 365 apps and Entra ID Ent apps related collaboration?
Hi All, I'm looking for an option to enable open collaboration between two Entra ID tenancies (two companies recently merged and now a single ORG). It seems Direct connect doesn't offer much to this context. I need to achieve the following at a minimum: 1. Let users work as they're in one ORG. i.e. users from both ORGs can be browsed/discovered in 365 apps Outlook, Teams and Delve etc.. 2. Granting user access across SharePoint, OneDrive etc.. has to be seamless. Users from both tenants will be appeared when trying to share, add permissions to items in SharePoint and OneDrive etc.. 3. Outlook specially, should show users across both tenants (centralized GAL kind of a experience). I need to enable the full potential of calendar/mailbox sharing in Outlook across these two tenants so that users from both tenants get to share calendars, edit, see tasks, inbox via delegation etc... is this possible with B2B ? if not what are the potential alternatives ? 4. How will the trust work for Azure Enterprise Apps ? i.e. I have an app called "Interfox" but this has been only configured in the primary tenancy (Tenant A). How to leverage B2B options to leverage the “trust” between the tenancies so that InterFox would permit SSO [subject to the InterFox back end having knowledge of the Tenant-B.com emails]? Thank you and really appreciate any thoughts ! Kev3.6KViews0likes1CommentProtect your identities from a Token theft using Token Protection in Conditional Access
In this blog post, I will show you the steps required to enable the Token Protection feature using Conditional Access in Entra ID. Along with a brief simulation of the Token Theft and how Token protection will prevent the attacker from stealing the token. https://www.linkedin.com/pulse/protect-your-identities-from-token-theft-using-access-elie-karkafy3.5KViews2likes0CommentsHybrid Azure AD Joined and Azure AD Registered dual state
Dear All, Recently we enabled hybrid azure ad joined on some of our test device, on azure portal those devices will shows dual state, one is hybrid azure ad joined and the other is azure ad registered status. However, Microsoft also claim dual state will not happen to windows version 1803 and above. but this bug is observed on our environment. Machines tested are Windows 11 latest build, in order to resolve dual state issue we had to let user manually disconnect account from windows setting (no bueno ). Could any expert provide some insight, how can assure the dual state will not happen. this issue had to be resolved before go online Thank you in advanced2.9KViews0likes2CommentsAzure AD | Workload License
A new basic information on Azure Active Directory that shows the license type used for your Azure AD Workload identities. What is Workload identities? A workload identity is an identity used by a software workload (such as an application, service, script, or container) to authenticate and access other services and resources. In Azure AD, workload identities are applications, service principals, and managed identities. With Premium plan for workload identities, you can: :pushpin: Create Conditional Access Policies to target the workload access :pushpin: Monitor the workload identities using the lifecycle management :pushpin: Detect and remediate compromised workload identities using the identity protection. Microsoft Entra Workload Identities license plans FAQ - Microsoft Entra | Microsoft Learn2.9KViews1like0CommentsIssues with setting up AiTM phish prevention using conditional access
We are a managed IT company and AiTM phishes (the ones that reverse proxy the true sign in page and steal session cookies) have been everywhere. We've started experimenting with User-Risk and Sign-In risk policies, and what I thought we had set up made sense to me, but I was doing some more indepth testing and found that what I set up has been basically useless/harmful? We have the basic conditional access environment: MFA: MFA enforced for every sign in Sign-In Risk: MFA Enforced for Risk Signing with Session Control "Every Time" for all levels of sign-in risk User-Risk: Require password change for Medium/High Risk My understanding was that particularly, the sign in risk policy, would apply an "Every Time" control to the session cookie, that way when it was stolen via a reverse-proxy, and re-imported to their browser it would request them to sign in again, because in my mind every time their session is reevaluated it should ask them to sign in. https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime says to use this control when I want to reauthenticate everytime, which is what I want to have happen when the session has risk. Issue is it looks like it doing in my environement instead: User signs in to reverse proxy link that was sent to them in a phish Microsoft sees that there is sign in risk, processes the Sign-In Risk conditional access policy Requires Grant Controls "MFA" Bad actor at this point would be given this authentication cookie Microsoft marks the Sign-in and its associated risk as Remediated because the user "passed mfa". Bad actor imports the session cookie to their browser Bad actor signs in fine and goes about their day ruining everyone elses These subsequent sign ins do not show up as "risky" because the risk associated with it was "remediated" -- which is talked about https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-remediate-unblock#self-remediation-with-risk-based-policy All I am trying to do is impose stringent session controls on these AiTM/reverse-proxy phishing and now I worry that I have been doing more harm than good because I basically set it to "remediate" the risk the very second it occurred. Any help in pointing me in the right direction is greatly appreciated.2.8KViews0likes2Comments