An Entra app credential is expiring. Which workload still uses it?
A credential rotation ticket often starts with three things: an application name, an expiry date and a deadline. That is enough to know something must happen, but not enough to rotate safely. Before touching the credential, I want to know whether that exact key is still requesting tokens, which resources it accesses and where those requests appear to come from. If Microsoft Entra sign-in logs are already connected to Log Analytics or Microsoft Sentinel, KQL can answer most of that without changing anything in the tenant. This is the workflow I use. What needs to be in the workspace The important diagnostic category is ServicePrincipalSignInLogs. In Log Analytics it becomes the AADServicePrincipalSignInLogs table. Normal SigninLogs are for interactive user sign-ins and are not the right data source for an app authenticating with its own secret or certificate. The diagnostic setting is configured under: Microsoft Entra ID > Monitoring & health > Diagnostic settings Make sure ServicePrincipalSignInLogs is being sent to the workspace you are querying. Microsoft documents the available log categories and their purpose here: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-diagnostic-settings-logs-options From the Entra recommendation or the affected application, copy the Application (client) ID. Do not confuse it with the application object ID or the service principal object ID. In the Kusto table: AppId is the Application (client) ID. ServicePrincipalId is the object ID of the service principal in the tenant. ServicePrincipalCredentialKeyId identifies the secret or certificate key used for the token request. ServicePrincipalCredentialThumbprint can help identify a certificate. ResourceDisplayName and ResourceServicePrincipalId identify the target resource. Those fields are part of the documented AADServicePrincipalSignInLogs schema: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadserviceprincipalsigninlogs Step 1: See every credential recently used by the application Replace TargetAppId with the Application (client) ID from Entra: let Lookback = 30d; let TargetAppId = "00000000-0000-0000-0000-000000000000"; AADServicePrincipalSignInLogs | where TimeGenerated >= ago(Lookback) | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= ago(Lookback) | where AppId =~ TargetAppId | extend SignInSucceeded = tostring(ResultType) == "0" | summarize FirstSeen = min(SignInTime), LastSeen = max(SignInTime), Attempts = count(), SuccessfulSignIns = countif(SignInSucceeded), FailedSignIns = countif(SignInSucceeded == false), CredentialTypes = make_set(ClientCredentialType, 10), SourceIPs = make_set(IPAddress, 20), UserAgents = make_set(UserAgent, 10), TargetResources = make_set( strcat(ResourceDisplayName, " [", ResourceServicePrincipalId, "]"), 20 ) by AppId, ServicePrincipalId, ServicePrincipalName, ServicePrincipalCredentialKeyId, ServicePrincipalCredentialThumbprint, FederatedCredentialId | order by LastSeen desc This gives me a short usage map for the application. If the expiring credential's key ID appears in the result, that exact credential was used for at least one recorded token request during the selected lookback period. The target resources show what it requested a token for. Source IPs and user agents usually help narrow down the workload. They are clues, not host identification. A source IP might be a NAT gateway, proxy or shared outbound address, and user-agent strings are neither guaranteed nor trustworthy. I use them to narrow the search in deployment settings, automation jobs, Key Vault references and CI/CD configuration, not as final proof of where the workload runs. Rows with a populated FederatedCredentialId represent workload identity federation. They should not be mistaken for use of the expiring secret or certificate. Step 2: Inspect the exact credential Once the expiring key ID is known, this query shows the individual sign-in records for that key: let Lookback = 30d; let TargetAppId = "00000000-0000-0000-0000-000000000000"; let ExpiringCredentialKeyId = "11111111-1111-1111-1111-111111111111"; AADServicePrincipalSignInLogs | where TimeGenerated >= ago(Lookback) | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= ago(Lookback) | where AppId =~ TargetAppId | where ServicePrincipalCredentialKeyId =~ ExpiringCredentialKeyId | extend Result = iff(tostring(ResultType) == "0", "Success", "Failure") | project SignInTime, Result, ResultType, ResultDescription, ServicePrincipalName, ServicePrincipalId, ClientCredentialType, ServicePrincipalCredentialKeyId, ServicePrincipalCredentialThumbprint, IPAddress, UserAgent, ResourceDisplayName, ResourceServicePrincipalId, CorrelationId | order by SignInTime desc A successful row is direct evidence that Entra accepted that credential for a token request at that time. Repeated failures can also be useful: they might show an incomplete rotation, an expired credential that is still configured somewhere, or a forgotten workload that keeps retrying. No rows do not mean "safe to delete." They only mean that no matching event exists in the data currently available to this workspace for the selected period. The workload might run monthly, the event might be outside retention, the diagnostic category might have been enabled recently, or the relevant logs might be routed elsewhere. The table also does not contain the application's business owner. I confirm ownership on the application or enterprise application in Entra, or enrich the result from an existing CMDB or Sentinel watchlist. I would not invent an owner from the last source IP or from whoever originally created the app. Step 3: Prove the replacement is actually in use After adding the replacement credential and updating the workload, I use the cutover time plus the old and new key IDs to verify the change: let CutoverTime = datetime(2026-08-26T12:00:00Z); let TargetAppId = "00000000-0000-0000-0000-000000000000"; let OldCredentialKeyId = "11111111-1111-1111-1111-111111111111"; let NewCredentialKeyId = "22222222-2222-2222-2222-222222222222"; AADServicePrincipalSignInLogs | where TimeGenerated >= CutoverTime | extend SignInTime = coalesce(CreatedDateTime, TimeGenerated) | where SignInTime >= CutoverTime | where AppId =~ TargetAppId | where ServicePrincipalCredentialKeyId in~ (OldCredentialKeyId, NewCredentialKeyId) | extend Credential = case( ServicePrincipalCredentialKeyId =~ OldCredentialKeyId, "old", ServicePrincipalCredentialKeyId =~ NewCredentialKeyId, "new", "other" ) | where Credential != "other" | summarize FirstSeen = min(SignInTime), LastSeen = max(SignInTime), Attempts = count(), SuccessfulSignIns = countif(tostring(ResultType) == "0"), FailedSignIns = countif(tostring(ResultType) != "0"), SourceIPs = make_set(IPAddress, 20), TargetResources = make_set(ResourceDisplayName, 20) by Credential, ServicePrincipalCredentialKeyId | order by LastSeen desc Before I remove the old credential, I want to see a successful token request with the new key ID after the cutover. I also run a real operation against the intended resource. A generic process health check is not enough if it never exercises the dependency that uses Entra authentication. Continued sign-ins with the old key after the cutover are a clear sign that another instance, deployment slot or workload still has the old value. An absence of old-key sign-ins becomes meaningful only after the expected workload schedule has been covered and the logs have arrived in the workspace. One final trap is token caching. Service principal sign-in logs show token requests, not every API call made with a token. Removing the old client credential prevents it from obtaining new tokens, but an access token already issued by Microsoft Entra normally remains valid until it expires. The rotation test must therefore force the workload to acquire a fresh token. Access token documentation: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens My rotation order is simple: Identify the exact old credential and the workload using it. Add the replacement while the old credential is still valid. Deploy the new credential to the workload's secret store. Force a fresh token request and execute a real operation. Confirm the new key ID in AADServicePrincipalSignInLogs. Watch for unexpected use of the old key for an appropriate period. Remove the old credential after the evidence and rollback window are sufficient for that workload. Microsoft Entra's preview recommendations for expiring application credentials and expiring service principal credentials are useful starting points. For me, the KQL correlation is the part that turns the warning into a controlled change instead of a blind rotation. Recommendation documentation: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-renew-expiring-application-credential https://learn.microsoft.com/en-us/entra/identity/monitoring-health/recommendation-renew-expiring-service-principal-credential How are you carrying application ownership into Sentinel? A maintained watchlist works, but it can easily become just another stale inventory.
Need Microsoft support to resolve a historical tenant association with a domain I recently acquired
Hello, I recently became the legitimate and independent registrant of a domain that had previously been owned or used by an unrelated organization. I have no affiliation whatsoever with the previous domain holder or that organization. I have now received a Microsoft Power Platform notification at an email address under my domain concerning a Default environment belonging to the previous organization. The notification includes a Tenant ID and Environment ID, and the environment name corresponds to that organization. I do not own, administer, or have access to this tenant or Power Platform environment, and I am not seeking access to or control over it. My main concern is that there may still be a historical association between my domain or its email addresses and the previous organization's Microsoft tenant or related services. I would like Microsoft to investigate this and, where necessary, properly separate my domain and its email addresses from any unrelated historical Microsoft accounts, tenants, directories, or services. Most importantly, I want to ensure that this historical association will not adversely affect my ability in the future to use my domain and its business email addresses to create, verify, and use my own Microsoft 365, Microsoft Entra, Power Platform, or other Microsoft business services. At present, I do not have a Microsoft business account, Microsoft 365 tenant, or Power Platform tenant of my own. As a result, I appear to be unable to use some of the normal business support channels that require an existing tenant or administrator account. Could someone please advise me on the appropriate way to get this matter reviewed by Microsoft Support? If a Microsoft employee or official support representative can assist or direct me to the appropriate private support channel, I would greatly appreciate it. For privacy and security reasons, I have intentionally not posted the actual domain name, email address, Tenant ID, or Environment ID publicly. I am happy to provide all of the relevant details privately to an authorized Microsoft support representative if required. Thank you for any guidance.Ask Microsoft Anything: Why Cybersecurity Needs a New Security Stack for the AI Era with David Weston
David Weston leads Agentic Security at Microsoft, where he and his team build the AI models, autonomous agents, and evaluation systems redefining how defenders operate. At Microsoft since the Windows 7 era, he has worked across exploit mitigation design, malware analysis, APT research, and led security engineering for Windows, Xbox, Azure OS, and Microsoft's Offensive Security Research & Engineering group. His current work is leading teams training frontier security models, agentic security systems for defenders, and pushing AI-driven vulnerability discovery through Microsoft's Multi-Model Agentic Scanning Harness (MDASH). A longtime member of the research community and former CISA technical advisor, David is a regular presenter at BlueHat, Black Hat, and DEF CON. Key areas Dave and his team can discuss: The vision behind Project Perception How AI is changing the economics of cyber offense and defense Lessons learned from building MDASH and Microsoft's AI security initiatives Security-first AI development and deployment What's next for defenders as agentic systems become mainstream This will be a TEXT-BASED AMA, so ask your questions in the comment section down below and David and team will be answering via comment replies during the live hour!Unexpected button behaviour when using the prompt=create parameter in Entra External ID user flows
Hi, In a recent workload, I'm assisting a client to implement Entra External ID for streamlined authorization as well as single sign-on for associated registered external facing third-party applications for external customer users through their Entra External ID identity, as well as assisting the client with auth branding and other UI customizations, and preparing Entra ID federation custom OIDC providers and configuration for enabling SSO with organizational internal and remote work- and school accounts etc. The sign-up / create account experience is of importance to the client, as a rather substantial amount of users are expected to sign-up via self-service sign-up following having received an invite via another app. To ensure that the user lands on the create account view, in order to minimize the number of steps and actions the users need to take to get there, the prompt=create parameter is used to pre-select the sign-up/register experience in the user flows UI. Having stress-tested the user flows and experience recently, we noticed that in a specific scenario, some UI elements behave in a manner that could be described as unexpected, and even though a workaround has mitigated it to some extent, the behaviour of some elements could probably be improved a bit to ensure an even more consistent user experience in the built-in user flows. Specifically, if the user flow is invoked with the prompt parameter set, the user lands on the create account screen as expected, however, unless custom CSS modification is applied, the Back button that would typically be there, as if having arrived there from the initial sign-in screen where it’s also displayed. If pressing the Back button displayed on the Create account view when having navigated there with the prompt=create set in the /authorize request, pressing the button seemingly doesn’t have any impact or result in any action, one can click it, but nothing happens. I'd suspect it's perhaps a "remnant" from if the flow is invoked without any prompt parameter set, or with prompt=login set, but when prompt=create is set, there is no state/page history in the UI to navigate back to, as no previous page has been displayed or rendered yet and added to the history, and the Back button click thus doesn’t have any effect. In general, I think buttons that don't have any tangible action should not be displayed, also, if prompt=login is set, the Back button isn't shown then either on the very initial user flow view shown then, so it would seem the built-in user flows actually already follow such approach in fact, but not when the prompt=create has been set, thus causing some inconsistency in the UI that users could notice unless custom CSS styling is applied. The expected behaviour for our business case would be that if prompt=create is set, then, similar to the prompt=login, no Back button should be displayed, or, if shown, it should result in some navigation (perhaps something like javascript.go(-1), but that could/would be dependent on from where the user arrived, e.g., going back a step in the browser history won't work if the user clicked a link from an invite email ) and preferably not be non-actionable. Furthermore, on the topic of the Back button and its behaviour when the prompt=create parameter is set, there is another case at which we observed some unexpected button behaviour as well, that could probably benefit from some attention. At a specific second scenario, it seems that the Continue button is displayed without providing any action, and when clicking the Back button then, clicking it seemingly resets the "create account", state likely set by the prompt=create initially, and instead switches the flow back to the sign-in state, which can at least affect the display text of some subsequent buttons shown in later steps in the UI. The user arrives at a built-in Entra External ID user flow /authorize endpoint, with the prompt=create query parameter set The user triggers the OTP challenge by entering an email address to verify the email address The user receives the OTP code but enters it incorrectly, i.e., doesn't copy the full code length of eight digits, and instead enters/pastes six of the eight code digits. The UI then shows an error message that the code could not be used/validated, and the email address field is displayed again with the email address that was used for the verification attempt prefilled. If the user clicks the Continue button at this stage, nothing happens. If the user clicks the Back button instead (given that it’s not hidden), it shows the same view one more time, with the Back and Continue buttons at the bottom. However, if the user clicks the Continue button this time, it works and a new code is sent. On the next screen, where the newly sent code can be entered, instead of a button named "Continue", it will now instead show a button with the text "Sign-in" (it would seem like the create account state has gotten lost somewhere along the way at this point, perhaps when the back button in the step 5 above was pressed). If one omits the prompt=create parameter, or when using prompt=login, things seem to work fine, the above occurs when the prompt=create is set. The reason why is the prompt=create is used is due to a business requirement to try to minimize the steps, especially in conjunction with the registration/sign-up, as far a possible when signing up. We have opted for the built-in user flows, not the self-hosted native authentication UI pages, for this project, and then as I understand it, it is the prompt=create parameter that can/should be used to enable the user to land directly on the registration page without having to navigate there manually via the sign-up link, that is otherwise shown on the initial sign-in page. It would thus be great if the prompt=create parameter could have some attention (or perhaps if a dedicated sign-up user flow type could be added potentially, even though that would perhaps warrant some update to the user flow app linking as well, as my understanding is that one user flow can be linked to one app registration at a time currently) to avoid that some buttons become unresponsive when the parameter is used, or falls back to sign-in, to improve the built-in user flows further, as the prompt=create fulfils the business requirement well otherwise. If there would be any further/follow-up questions on the above, e.g., to clarify the requirement, or further explain the reproduction steps and behaviour observed, or anything else, please tell, and I'll ensure to get back as soon as possible. Also, would someone have some input on potential other/additional ways to pre-select the create account/sign-up experience, that would naturally be much appreciated as well, thanks! Regards Kristoffer
Verifying domain name issue
We're trying to verify our custom domain in Entra ID, but it turns out the domain is already claimed on another tenant that we have no access to (unknown account, no admin credentials). Because of that, verification on our own tenant fails. Normally the fix for a claimed-domain conflict is to open a support request so Microsoft can help release it. The problem: doing that requires a support plan, and purchasing one doesn't work for us. "payment" always succeeds and we dont get an error, but we don't get charged and the account status doesn't change, we have nothing more to go on. So we're stuck in a loop: we need support to release the domain, but we can't buy the support plan needed to reach support. Has anyone dealt with a domain claimed on an inaccessible tenant? And is there another route to Microsoft support when the support plan purchase itself fails?
Best practices: Open OneDrive/SharePoint sharing but restrict Teams guest access by domain
Hi all, Since SharePoint Online and OneDrive moved fully to Microsoft Entra B2B for external sharing, we've run into a policy conflict and would like to hear how others are handling it. Our requirements Enable OneDrive and SharePoint file sharing with external users, regardless of their email domain. Restrict Microsoft Teams guest access to a predefined list of approved partner domains. Continue allowing Teams external access (federated chat and meetings) for all domains. The problem: Teams guests, SharePoint guests, and OneDrive guests are now governed by the same Microsoft Entra B2B invitation framework and the single Collaboration restrictions allow/deny list under: External Identities → External collaboration settings As a result, restricting guest invitations by domain also restricts OneDrive and SharePoint sharing for domains not on the allowlist. According to Microsoft's response in the following Q&A, this behavior is currently by design: https://learn.microsoft.com/en-us/answers/questions/5954975/onedrive-external-sharing-no-longer-working-with-a Questions to the community Has anyone implemented a solution where OneDrive/SharePoint sharing remains open to all domains while Teams guest access is restricted to approved domains only? Are there recommended approaches using Entitlement Management, Access Packages, Connected Organizations, or other Entra capabilities? Is there any roadmap item for workload-specific collaboration restrictions (e.g., separate policies for Teams guest invitations and SharePoint/OneDrive sharing)? Any real-world experience or best practices would be greatly appreciated. Thanks, BejhanMicrosoft Entra Suite hands-on tour of identity and network access protections
Enforce least privilege access across every app and resource. Wire lifecycle workflows directly to your HR system to strip stale permissions on role changes, gate sensitive data behind biometric step-up verification, and replace your VPN with per-app, identity-scoped access that revokes tokens the moment risk spikes. Secure AI usage at every layer. Block confidential data from reaching public AI tools and stop adversarial prompt injections before your agents process them. John Damon, Microsoft Entra Suite Senior Product Manager, shares how to lock down identity, network access, and AI usage from a single control plane. Zero stale permissions after a role change. Entra Suite lifecycle workflows auto-assign the right access package and remove old entitlements. Check it out. Cut legacy VPN. Global Secure Access in Entra Suite scopes access per app, ties it to identity, and exposes no inbound ports or public IPs. See how it works. Expose adversarial instructions hidden in plain text. Prompt Injection Protection in Entra Suite matches the injection class and blocks the prompt before the model processes it. Check it out. QUICK LINKS: 00:00 — Identity and network controls 00:45 — Lifecycle Workflows 01:28 — Verified ID with Face Check 02:15 — Request access for direct reports 03:17 — Global Secure Access + Token Revocation 04:32 — Secure AI usage 06:20 — Network DLP / ChatGPT Block 07:12 — Prompt Injection Protection 08:31 — Wrap up Link References Check out our related deep dives at https://aka.ms/EntraSuitePlaylist For more information, go to https://aka.ms/EntraSuite Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -With AI, where action happens at machine speed and where access can be granted and inherited instantly, identity and network access has never been more important. Securing AI starts with securing people, and for that, your identity and network controls need to come together to close gaps that attackers can exploit, and that’s where Microsoft Entra Suite comes in. It combines best-in-class capabilities into a single solution to help you enforce least-privilege access to make sure users have access to what they need, and only as long as necessary. Apply unified access controls to any app and resource, and secure access to AI by discovering AI apps and agents, assessing risk, and enforcing policy. -Let’s bring this to life by following a user, Violet Martinez, throughout her day, I’ll start by showing how she gets access to exactly what she needs, with least-privilege access. In this scenario, our user has changed job roles. Her role change was signaled overnight by an HR system, Workday, and her permissions need to be adjusted for her new position in the IoT department. This is where a lifecycle workflow we set up in advance in Entra Suite comes into play. We’ve created a “Mover” workflow that automatically adjusts access when a user role changes, and I can click to see how it’s defined. Importantly, stale entitlements from her previous role are automatically removed, and a new access package bundling the right apps and permissions for her new IoT product marketing role is automatically assigned. -Now let’s switch to showing you our user Violet’s experience. When she signs in with a passkey for her new role, every app and permission from the baseline package is already set up, and she can request access to specific resources that she might be missing using the My Access page at myaccess.microsoft.com. For example, in order to start her work in competitive analysis, she needs access to Zava’s on-prem IoT Pricing Dashboard. So she makes the request. Because the package grants access to highly confidential on-prem pricing data, the workflow requires Verified ID step-up with Face Check. This requires Microsoft Authenticator, which prompts for Face Check, a verification process to match her real-time selfie to her government-issued ID on file, and once verified, she’s given access to the dashboard. -Now, as a manager, you can request access for your direct reports to make it easier for users to onboard with the access they need. In fact, let me show you the perspective from Violet’s manager. In the same My Access page, I can see the Pricing Dashboard access package we just saw, along with another access package that I can assign to my team. In this case, I want to extend the access to the Zava Assistant AI agent used by the team, and can initiate an access package request for the agent on Violet’s behalf. -From the dropdown, I see the directs on my team, I’ll choose Violet. Now I’ll choose a start date followed by an end date, and along with those, I’ll type in the business justification, which was set up by IT as mandatory properties for this access package. And because in this instance, as the manager, I am both the requester and approver, Entra ID Governance both provisions and grants just-in-time and time-bound access. Least-privilege access is enforced automatically, with stale permissions removed and updated baselines assigned, and sensitive access controlled using step-up verification. -From here, let’s move on to applying real-time context-aware access controls to apps and resources as our user goes about her day. She starts in the Edge browser and navigates to local IP to open on-prem Pricing Dashboard. We can see that she has the Global Secure Access client installed, so she doesn’t need to use a VPN. To access internal resources, our IT policy requires her to sign in using her work account with passkey, which uses Conditional Access to evaluate her risk and session context before allowing access to on-prem Pricing Dashboard. Importantly, Global Secure Access permissions are granted per app and scoped to identity, with no inbound firewall ports and no public IPs exposed. And by the way, Global Secure Access will also work with other on-prem apps and Active Directory that do not natively support modern authentication. -The good news is, even if her device is compromised because of a hardware-based token theft and a token replay attack, with dynamic policies in place, once the user risk is flagged as elevated, token access can be automatically revoked. This forces self-remediation for any user account with elevated risk. That way, privilege never accumulates and trust is continuously reevaluated without standing privilege to stop identity attacks. Next, we already saw that our user is expected to use AI as part of her job, but how does Entra Suite help with securing AI usage? -Let’s take a look. When our user leaves the office, she uses her personal laptop to work on an FY27 presentation from her team’s SharePoint site. She’s in Microsoft Edge, and using her personal browser profile. A SharePoint site is bookmarked, and she tries to access it. In order to get to the protected location on her laptop, she signs in with her work account, and Conditional Access requires an app protection policy, which then prompts her to switch the Edge profile to her work account. When she does, the device is now registered and the app protection policy is delivered to the browser. This automatically applies security settings and policies to the work browser profile. It enables explicit forward proxy settings and TLS inspection to add visibility into encrypted traffic, so that the company’s data protection policies can work with it. This includes Microsoft Edge data loss protection controls, as well as Microsoft Entra Internet Access, Secure AI and Web gateway policies. That way, she can access her work documents securely, like you’re seeing here with the internal FY27 planning presentation. -That said, when using her work profile in the browser, if she opens a new tab and she tries to access a social media site, we can see access is blocked based on the company policy. But once she switches back to her personal profile, access to Facebook works as expected. Policies are pushed automatically, even though she’s not using a managed device. -In fact, Entra Suite inspects and controls access to data. As she interacts with any website, her traffic routes through Entra Internet Access as a forward proxy. So every egress path is inspected in real time against the Purview sensitivity label applied at the source. Same label, same policy, whether she’s on a corporate laptop or a personal device. This time, our user returns to work with her managed work laptop, and she wants to analyze the data from the Pricing Dashboard using ChatGPT. She has a confidential internal product pricing schedule opened as a PDF and selects everything in the document, and she copies everything on the page. Then she moves over to ChatGPT and pastes the pricing info from her clipboard. -Here, Secure Web and AI Gateway in Entra Suite blocks the upload because there’s an organization-wide policy that prohibits sharing confidential data through a public AI tool. This adds an important layer of protection because a standalone web gateway or CASB can only see traffic, but not the data classification. This is made possible because network DLP parsed the chat text to spot sensitive information before ChatGPT saw the payload, and network DLP also will block the sharing of sensitive files over non-Microsoft email services like Gmail. Next, let’s look at the secure AI usage when the user leverages her company-sanctioned AI tool. Here’s the Zava Assistant that her manager approved. She starts opening a competitor blog and copies everything into her clipboard. Then she invokes the agent and starts to interact by pasting in the blog for summarization, but there’s a catch. Hidden inside the text is a human-invisible instruction telling the model to leak her query history. -Here, prompt injection protection inspects the outbound prompt against Microsoft’s adversarial pattern model, matches the known injection class, and blocks it before it’s processed. Additionally, new web filtering rules let you block agents from conducting risky operations on specified resources, by creating policies for browser-based and local apps communicating over web protocols. This time, our user remembers that she’s left a sensitive Zava partner memo in the shared Dropbox location. -So, using her locally installed Claude app, she requests another in-house developed Zava agent to remove that file from Dropbox. Immediately, she can see that this action was prevented based on the network policy from her company. And moving to the admin experience, these rules can differ whether it’s a user or agent session performing the operation. They can be configured to assess multiple HTTP methods, including POST, PATCH, PUT, and DELETE operations scoped to specific URLs or FQDNs. -Those were just a few examples of Microsoft Entra Suite and its unified approach to access. With Microsoft 365 E7, you can get Entra Suite protections and apply them to AI agents with Agent 365. -Check out our related deep dives at aka.ms/EntraSuitePlaylist, and to learn more, go to aka.ms/EntraSuite. Subscribe to Microsoft Mechanics for the latest tech updates, and thanks for watching.Looking for an on-prem MFA solution for Active Directory and RDP
Hi everyone, We're reviewing options for adding MFA to our on-premises Active Directory environment. Most of our users authenticate with Active Directory, while administrators also use RDP for managing Windows servers. Because part of our infrastructure is isolated from the Internet, we'd prefer an on-premises MFA solution instead of relying on a cloud-only service. Has anyone implemented something similar recently? I'm interested in hearing: Which solution did you choose? How difficult was the deployment? Did you run into any compatibility or performance issues? Is there anything you'd do differently if you were deploying it again? Any real-world experience or recommendations would be greatly appreciated. Thanks!Can the built-in "No account? Create one" link redirect to a custom sign-up page?
I'm using Microsoft Entra External ID with a built-in sign-in/sign-up user flow. On the Microsoft-hosted sign-in page, the "No account? Create one" link always redirects users to the default Entra sign-up page. I already have a custom registration page and would like this built-in link to redirect to my custom URL instead. Is there any supported way to customize the destination of this link in a built-in user flow? If not, could someone confirm whether this behavior is fixed by design? Thanks!
