Azure
496 TopicsCannot login to Service Trust Portal
Hi, I'm trying to get some certificates from the service trust portal, but I keep getting "Service Trust Portal no longer support Microsoft Account (MSA) access." I'm using an account registered on Azure and I checked the Azure Active Directory, and the user exists (seeing it's the owner of the account). What am I missing here?3KViews1like5CommentsAnomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon Tüpker909Views1like1CommentRSS feeds to security blogs?
Hello, After the update of blogs here i no longer see any RSS feeds or links. Where can those RSS feed be found now? It was the only newsfeed where blogs could be aggregated. perhaps im just blind :) but i cant find the new RSS feeds. Thank you! Previously (before this weeks update) the links to those RSS feed was as follows: https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftSecurityandCompliance https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=Identity https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=CoreInfrastructureandSecurityBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=AzureNetworkSecurityBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=IdentityStandards https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftThreatProtectionBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftDefenderCloudBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftDefenderATPBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftDefenderIoTBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=DefenderExternalAttackSurfaceMgmtBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=Vulnerability-Management https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=DefenderThreatIntelligence https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftSecurityExperts https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=Microsoft-Security-Baselines https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftSentinelBlog https://techcommunity.microsoft.com/gxcuf89792/rss/board?board.id=MicrosoftDefenderforOffice365Blog982Views12likes4CommentsSMTP XOAuth authentication and Microsoft authentication libraries
Due to the upcoming deprecation of basic authentication our company is looking to move all our products to modern authentication protocols for sending emails but we have some unusual usage scenarios that have me running in circles. I have been through all available documentation multiple times and I'm stuck. The problem is that we have on premise web applications that are running on multiple client servers and not a central location. This creates a problem when using standard OAuth flows since there is no fixed URL to use as a redirect URI. Because of this I have created a separate API on a fixed URL that will serve as the redirect URI for all clients and instances of our web applications. This breaks the standard usage of MSAL library and I had to go around chasing my tail to even be able to implement something that could possibly work. I have been able to do it using Microsoft.Identity.Client MSAL library but I hit a problem since I need to use the ConfidentialClientApp.AcquireTokenByAuthorizationCode call to redeem the access code obtained after user login but apparently SMTP does not allow confidential clients to login. We need the application to be able to send emails from any account any tenant or personal accounts. I have obtained the access token for a personal account but SMTP rejects it with this error: 535: 5.7.3 Authentication unsuccessful [AM8P251CA0016.EURP251.PROD.OUTLOOK.COM]. If I switch to PublicClientApplication then there is no AcquireTokenByAuthorizationCode method and I can't even use client secret so I'm not even sure how this works in redeeming a code. I am going by instructions on this page: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth and it mentions no requirement of a public client application. It states I can use authorization code flow and the documentation on authorization code flow states it can be used by web apps and desktop apps. Well how am I supposed to use it when SMTP won't accept a confidential app and the PublicClientApplication does not have a method to redeem it? If I drop the authentication library and go for pure REST API call implementation, which application credentials should I use that the acquired tokens will be accepted by the SMTP server? Also I would like to know if office 365 users still have to disable security defaults and enable STMP Authentication to use SMTP with OAuth 2? This would defeat the whole purpose of migrating to OAuth 2 and the blog about deprecation states that moving to OAuth 2 is the way to prepare your app for this deprecation, but I've seen instructions on SMTP OAuth that state SMTP Authentication still needs to be enabled.2.4KViews0likes3CommentsWAF custom rule for bock others cookie and permit only a specific cookie name and value
Hello all, I need to create a custom WAF rule that only allows traffic for a specific request URI (/example-path) if it contains a particular cookie, Cookie=abc123, and blocks all other requests. Additionally, could someone clarify the difference between configuring the policy this way: RequestHeaders['Cookie'], Operator=DoesNotEqual, Values="Cookie=abc123" RequestCookie, Values="CookieName", Operator=Equal, valueOfTheCookie="abc123" I hope I explained myself clearly. Thanks in advance for your responses!166Views0likes0CommentsAzure OpenAI FedRAMP High + M365 Copilot Targeting Sept 2025 for GCC High/DOD
We’re excited to share two major updates for our public sector and defense customers: Azure OpenAI Service is now FedRAMP High authorized for Azure Government. This approval allows government agencies to securely leverage advanced AI capabilities, including GPT-4o, within their Azure Government environment. For the first time, we’re targeting a General Availability (GA) of September 2025 for Microsoft 365 Copilot in GCC High and DOD environments (pending government authorization). Copilot will deliver powerful AI tools tailored for decision-making, automation, and enhanced collaboration, all while meeting the strict compliance and security needs of our defense and government customers. For more information on these updates and how they can impact your workflows, check out the full blog post Let’s discuss how you’re planning to use these AI advancements in your environments!775Views0likes0CommentsBlock standard C:\Users\%User%\AppData\Local\Microsoft\WindowsApps Path environment variable
Hello togehter, for security reasons I like to block (GPO?) / delete the standard Windows-path-enviroment variable: C:\Users\%User%\AppData\Local\Microsoft\WindowsApps First of all: Does it make sense to do this? I want to exclude a case that some user / unwanted software are copied here by attackers. Thanks a lot Kevin1KViews0likes1CommentNew Blog | Onboard to Azure Arc with Security in Mind
By Simone Oor Introduction Azure Arc allows certain on-premises resources, typically servers, to be managed from Azure, depending on the configuration mode selected and currently available features. While this allows for a more integrated approach to hybrid environments, it also further blurs the administrative boundary between on-premises and cloud. This increases the risk that a vulnerability on either side lowers the level of security across the entire plane. This article contains tips for managing this risk and approaching Arc Onboarding with security in mind. It focuses only on servers. The link below contains information about the full range of Azure Arc: Azure Arc overview - Azure Arc | Microsoft Learn. Azure Arc and its service principal Onboarding to Azure Arc can be done using a service principal in Entra ID for authentication. Service principals can be thought of as “service accounts” in Azure. One way of generating this service principal is from the Azure Arc blade in the Azure portal. Navigate to Azure Arc / Management / Service principals. Below one such an entry: Figure 1: Azure Arc service principals Here the scope of the service principal (for example the resource group “RG-ARC”) and the Arc-specific roles can be assigned. Most common is the “Azure Connected Machine Onboarding” role, as shown above. Read the full post here: Onboard to Azure Arc with Security in Mind361Views0likes0CommentsAzure’s layered approach to physical security
We have heard from many customers that cloud security is one of their top concerns. Another thing we’ve heard from customers is that they want clarity around what they are responsible for securing in Azure and what Azure will do. Azure helps provide a highly secure foundation, built from the ground up, to host your infrastructure, applications, and data. We understand the importance of protecting customer data, which is why we are committed to helping secure the datacenters that contain your data. Microsoft has invested over a billion dollars into security, including the physical security of the Azure platform, so you can devote your time and resources towards other business initiatives. Over the next few months, as part of the secure foundation blog series, we’ll discuss the components of physical, infrastructure (logical) and operational security that help make up Azure’s platform. Today, we are focusing on physical security. Read about it in the Azure blog.3KViews1like1CommentQuestioning Azure PIM Security: Can MFA Requirements Be Bypassed?
Hi everybody, I recently came up with a scenario to test a use case in which a threat actor could potentially steal your Azure access token. With this token, the actor attempts to elevate privileges within the system by activating a highly privileged role (e.g., Owner) through Azure Privileged Identity Management (PIM). In my current PIM configuration, I have set it to require multi-factor authentication (MFA) upon role activation. However, I've noticed that when I authenticate using the stolen access token from a non-trusted device, I am still able to activate the Owner role through PIM without being prompted for MFA. This leads me to question the effectiveness of PIM, and more specifically, the "Require MFA on activation" setting. What security benefits does it provide if it can be bypassed in this manner? Thank you for your insights, John1.1KViews1like2Comments