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.
28 comments
-
Bas van der Kruijssen
commented
Any progress reports on this?
-
Or
commented
This issue is urgent for security team because this data is missing from SIEM logs, if you're triggering risky sign in alert based on non-interactive sign in you should definitely log this activity via Azure/MCAS!
-
Frane Borozan
commented
Hi there, (non-interactive) login are still not available through the GraphAPI. I am able to see those in the Azure AD signins inside the Azure AD logs but not through the API.
-
Henry Selzer
commented
Hi Microsoft, the new non-interactive sign-in report is great. Should I be able to retrieve these events via the Graph API or the Get-AzureADAuditSignInLogs command?
Thanks,
Henry -
Ben Siler
commented
Service principal and non-interactive events are now available in the Azure AD Sign-ins blade in public preview! You can see the new sign in reports using the Non-interactive user sign ins, Service principal sign ins, and Managed identities sign ins here: https://portal.azure.com/?Microsoft_AAD_IAM_signinstabview=true#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/SignIns
-
Brian Gancherov
commented
Any updates?
-
David Okeyode
commented
Looks like work is in progress on this. Saw the option to export three new signin logs while testing some functionality today but the export or view doesn't seem to be active yet
-
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.
-
Steeno, Ryan
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?
-
Ste Walsh
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.
