Make SPN (non-interactive) login events logged and available
Currently in Azure AD when using SPN (non-interactive) logins via code (.Net, Powershell, etc.) for automated processes (server to server communication/API) that interact with Azure, there is no event in Azure AD logs to show that this login has occurred. Please make this exposed in the logs in the same fashion that an interactive user login is logged. This is not only beneficial for troubleshooting, but more importantly from a security, compliance, and risk audit trail standpoint.
SGrinker
shared this idea
We are working on this but we don’t have a public ETA to share at this time. We will keep you updated as we get closer.
21 comments
-
Vladimir Nekic
commented
Please decrease the time needed to update security logs for user sign in. We find it extremely difficult to review logs for APP PASSWORD sign in failures and security audits when set to 24 hours. Please decrease the time between updates for user logins to post to Azure Active Directory Sign In logs.
-
Chris Harrison
commented
We are due to deploy a Azure AD-based system in the coming months and audit is a business-critical function. Please can this be prioritised and an updated provided?
-
About sign-in activity reports in the Azure Active Directory portal.
The sign-ins report only displays the interactive sign-ins, that is, sign-ins where a user manually signs in using their username and password. Non-interactive sign-ins, such as service-to-service authentication, are not displayed in the sign-ins report.
Are there any plans to improve the Non-interactive sign-ins to be displayed -
Anonymous
commented
I just came across this. and was sad to see its so old.
I just changed my EWS app to use an SPN for login with OAuth instead of basic as per microsoft recommendations.
Not sure if it is all secure though as I cant audit the login.
The only way I think it may have worked is beacuse I turned off Legacy auth.Not great security auditing microsoft.
-
Jim Smith
commented
Any update on the progress of this? We are in the process of implementing OAuth via Azure AD in our web api and the visibility of sign-in information is crucial.
-
Ryan Steeno
commented
This is absolutely critical to have. In the event that an client_id/secret is used outside of the organization customer need to know. This will also help in the lifecycle management of application registered to AAD; with out this information we have no idea if applications are still used.
-
Anonymous
commented
Any updates on this? This is an important topic.
-
Jon Webster
commented
Vendor claims their product didn't make changes to our environment, but we have evidence the enterprise application used only by them made the change. There is no way to prove what happened without this capability.
-
SGrinker
commented
Any updates since Dec 1, 2017 on this? Shouldn't this have been marked as "Under Review" based on that comment?
-
Eddy Elbers
commented
Any news from Microsoft on this request?
-
Walsh. Stephen (Enterprise Services)
commented
This would be very useful for troubleshooting and auditing
-
Lidvar Kornberg
commented
Today the Sign-In Activity log in AAD contains end-user authentication events, but does not have any log events when an application authenticate with AAD using client_credential grants. This must be logged or we are not able to trace successful or failed logon event for debugging and this is also a security concern as we can not trace and detect successful or failed logon events from unknown sources.
-
Anonymous
commented
In order to provide a complete and wholistic view on failed login attempts it’s imperative that we are able to consistently capture such events for users (as we can today) but also for service principles given the enabling role they play in the identity sphere in Azure. Not being able to do so [other than via a support call] feels like a major flaw when trying to surface such events via a SIEM solution.
-
Anonymous
commented
These logs need to be exposed or at the least available for extraction in order to detect and monitor any anomalous behaviour from a user entity behaviour analysis perspective.
-
Anonymous
commented
Completely agree with this our Security team has identified this as a risk - there simply isn't enough information being surfaced about activity on app registrations and Service Principals. If we only had some log of the success/failure of Service Principals we could provide our own mitigation - but not available. Nor is this omission documented to caution the owner. In this day of app to app interactions I can only think that this requirement will become more and more necessary.
-
Dhanyah Krishnamoorthy
commented
Hi All,
We are looking to add this feature into our Sign-ins Activity logs in the near future. We will keep you posted.
-
Edmund C Soyza
commented
Hello, was just wondering if there has been any new developments on this? I actually opened a case with Microsoft to inquire how to get this info myself before I found this page.
-
Anonymous
commented
Yes , and this should be a dashboard widget with email alerts as well
-
JH
commented
Any update on this? Having no login information is especially problematic for SPN logins since no conditional access can be applied to them.
-
Hi,
We have received this feedback and looking to add this information in our Sign ins report. I will let you know as soon as I have an update
