Sign-in reports - missing events for specific users

%3CLINGO-SUB%20id%3D%22lingo-sub-326625%22%20slang%3D%22en-US%22%3ESign-in%20reports%20-%20missing%20events%20for%20specific%20users%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-326625%22%20slang%3D%22en-US%22%3E%3CDIV%3E%3CFONT%3EI'm%20poking%20around%20AAD%20Sign-In%20reports%20(AAD%20Premium%20license%2C%20EMS%2BSecurity%20E3)%20and%20notice%20that%20some%20of%20my%20users%20whom%20I%20know%20definitively%20have%20been%20signing%20in%20are%20no%20where%20to%20be%20found%20in%20the%20logs.%20Not%20a%20single%20event%20for%20certain%20users.%20%3C%2FFONT%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CFONT%3EFor%20example%2C%20a%20user%20with%20whom%20I%20am%20exchanging%20emails%20(he's%20using%20Outlook%20mobile%20app%20on%20his%20iPhone%2C%20Skype%20for%20Business%20for%20IM%20and%20PSTN%20calling%20on%20his%20phone)%20shows%20no%20sign-ins%20whatsoever.%20There%20are%20no%20filters%20applied%20to%20the%20report%2C%20I%20am%20pulling%20all%20events%20from%20the%20past%207%20days.%20I%20am%20seeing%20this%20for%20a%20few%20other%20known%20users%20as%20well.%3C%2FFONT%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CFONT%3EDoes%20anyone%20know%20what%20might%20be%20going%20on%20or%20what%20might%20be%20causing%20this%3F%3C%2FFONT%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CFONT%3EThanks%2C%3CBR%20%2F%3EBob%3C%2FFONT%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-326625%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESign-ins%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-331579%22%20slang%3D%22en-US%22%3ERe%3A%20Sign-in%20reports%20-%20missing%20events%20for%20specific%20users%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-331579%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20are%20facing%20similar%20issues.%20We%20use%20SailPoint%20to%20automatically%20disable%20user%20identities%20for%20on-premises%20Active%20Directory.%20There%20are%20VIPs%20who%20only%20use%20O365%20services%20so%20they%20never%20logon%20to%20on-premises%20AD%20and%20their%20lastlogontimestamp%20is%20never%20updated.%20We%20want%20to%20build%20a%20correlation%20between%20Azure%20AD%20and%20on-premises%20AD%20so%20that%20before%20a%20decision%20is%20made%20by%20SailPoint%20to%20disable%20an%20account%20it%20considers%20both%20on-premises%20lastlogontimestamp%20and%20Azure%20AD%20sign-in%20logs.%20We%20face%20same%20issue%20as%20described%20above%20and%20there%20is%20no%20other%20attribute%20to%20refer%20to%20in%20AzureAD%20which%20can%20allow%20this%20correlation%20to%20happen.%20So%20the%20method%20we%20have%20today%20is%20not%20full%20proof%20and%20has%20chances%20to%20fail%20if%20we%20use%20sign-in%20logs%20as%20correlation%20attribute.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-326714%22%20slang%3D%22en-US%22%3ERe%3A%20Sign-in%20reports%20-%20missing%20events%20for%20specific%20users%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-326714%22%20slang%3D%22en-US%22%3E%3CP%3EAs%20Steven%20said%20above%2C%20MA%20greatly%20reduces%20the%20number%20of%20sign-in%20events.%20I%20just%20wanted%20to%20add%20that%20if%20you%20are%20looking%20for%20%22when%20was%20this%20user%20last%20active%22%20type%20of%20report%2C%20you%20should%20look%20at%20the%20Unified%20audit%20log%20in%20the%20SCC%2C%20which%20should%20give%20you%20a%20lot%20more%20events.%20When%20it%20works%2C%20that%20is.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EP.S.%20I%20wonder%20how%20many%20more%20years%20will%20have%20to%20pass%20until%20we%20get%20a%20LastLoginDate%20attribute.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-326668%22%20slang%3D%22en-US%22%3ERe%3A%20Sign-in%20reports%20-%20missing%20events%20for%20specific%20users%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-326668%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20apps%20are%20using%20Modern%20Authentication%20then%20you'll%20only%20see%20reauthentication%20events%20when%20the%20token%20expires%2C%20which%20can%20be%20forever%20...%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Factive-directory-configurable-token-lifetimes%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Factive-directory-configurable-token-lifetimes%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Regular Contributor
I'm poking around AAD Sign-In reports (AAD Premium license, EMS+Security E3) and notice that some of my users whom I know definitively have been signing in are no where to be found in the logs. Not a single event for certain users.
 
For example, a user with whom I am exchanging emails (he's using Outlook mobile app on his iPhone, Skype for Business for IM and PSTN calling on his phone) shows no sign-ins whatsoever. There are no filters applied to the report, I am pulling all events from the past 7 days. I am seeing this for a few other known users as well.
 
Does anyone know what might be going on or what might be causing this?
 
Thanks,
Bob
3 Replies
Highlighted

If apps are using Modern Authentication then you'll only see reauthentication events when the token expires, which can be forever ...

 

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-...

 

 

Highlighted

As Steven said above, MA greatly reduces the number of sign-in events. I just wanted to add that if you are looking for "when was this user last active" type of report, you should look at the Unified audit log in the SCC, which should give you a lot more events. When it works, that is.

 

P.S. I wonder how many more years will have to pass until we get a LastLoginDate attribute.

Highlighted

We are facing similar issues. We use SailPoint to automatically disable user identities for on-premises Active Directory. There are VIPs who only use O365 services so they never logon to on-premises AD and their lastlogontimestamp is never updated. We want to build a correlation between Azure AD and on-premises AD so that before a decision is made by SailPoint to disable an account it considers both on-premises lastlogontimestamp and Azure AD sign-in logs. We face same issue as described above and there is no other attribute to refer to in AzureAD which can allow this correlation to happen. So the method we have today is not full proof and has chances to fail if we use sign-in logs as correlation attribute.