using MS logon data to drive inactive MS identities

  • 259 Views
  • Last Post 08 June 2016
barkills posted this 03 June 2016

For our Active Directory and Azure AD, we’d like to institute some sanity on our large set of currently active user accounts by disabling and after some additional period of inactivity deleting a disabled user.

  Unlike most everywhere else, we have a very large and fluid set of relationships for any given user with a large number of different user populations that permit a given individual to have a UW identity, so it is not just a disable when employee or student leaves. Employees and students are maybe 10% of our total user population. We tend to instead heavily emphasize access controls.   Our technical architecture is also very much a hybrid that spans a diverse set of technologies, mostly hiding from users the fact that any given UW identity actually has many different user accounts and possible authentication technologies being leveraged. In terms of the most relevant bits for this email, our Azure AD federates authentication to ADFS, which federates authentication to our Shibboleth IdP (which leverages a MIT Kerberos realm). Along that path, you can get an ADFS logon token with an AD logon token, if you have one, but otherwise you end up authenticating elsewhere.   If we had a purely AD based authentication architecture, we could simply look at lastLogonTimestamp data to figure out which AD users (and by extension AAD users) we could inactivate. However, we don’t have that simple architecture. And likewise, it’s not viable to use Shibboleth or MIT Kerberos logs for this purpose because they aren’t a direct indicator of whether the associated AD and AAD user account is active or not. This seems to leave ADFS and Azure AD log data (in conjunction with AD lastLogonTimestamp) to determine which AD and AAD users are inactive and good candidates for disabling.   This brings me to my question. Does anyone have any good general purpose solution for determining which user accounts have logged via either ADFS or Azure AD?

  I’d love to see Microsoft add a lastLogonTimestamp attribute to Azure AD user objects, but I don’t think that will happen any time soon, so I’m looking for other solutions. Ideally the solution would allow us to run some simple query across all users to find those who haven’t logged in during a given period of time.

  Brian Arkills

Order By: Standard | Newest | Votes
James posted this 04 June 2016

Our solution has been to enable ADFS Auditing [1], forward these logs to an event log collector, consolidate the logon events (there are 4-6 entries per logon event), and add them to a sql database. From there we run reports to find inactive users. It's not great and it's still a work in progress, but it's the best I've been able to come up with.
[1] https://jorgequestforknowledge.wordpress.com/2013/07/08/enabling-auditing-of-issued-claims-in-adfs-v2-x-and-adfs-v3-x/
James


show

joe posted this 04 June 2016

To be clear, I don't have a solution for finding inactive users but I do have a system for collecting data that could be used to figure this out.
Our system is a little different than the one James mentions and is probably a bit overkill for most. We have a custom attribute store that doesn't actually return any data and simply logs data input into it when it is called to a JSON format rolling log file. The rolling log files are then picked up by a component called "logstash" and dumped into an Elastic Search instance. We then have a Kibana dashboard on top of the Elastic Search index to facilitate reporting and analysis.
The attribute store is triggered by a special claim rule we insert in the Authorization claim rules part of the pipeline. It doesn't actually perform any authorization. We just put it there because it always runs since authorization runs before issuance on the "RP side" of the pipeline.
We are looking at creating a tool to poll the Azure AD "all logins" report API endpoint and do something similar with that data. It outputs data in a similar JSON format so once we get the poling component in place, it should be possible to build some similar reporting and even potentially integrate the two together.
Joe K.


show

robertsingers posted this 05 June 2016

Joe is your tool something you could open source?
On 5 June 2016 at 08:43, Joe Kaplan <joekaplan.net@xxxxxxxxxxxxxxxx> wrote:
To be clear, I don't have a solution for finding inactive users but I do have a system for collecting data that could be used to figure this out.
Our system is a little different than the one James mentions and is probably a bit overkill for most. We have a custom attribute store that doesn't actually return any data and simply logs data input into it when it is called to a JSON format rolling log file. The rolling log files are then picked up by a component called "logstash" and dumped into an Elastic Search instance. We then have a Kibana dashboard on top of the Elastic Search index to facilitate reporting and analysis.
The attribute store is triggered by a special claim rule we insert in the Authorization claim rules part of the pipeline. It doesn't actually perform any authorization. We just put it there because it always runs since authorization runs before issuance on the "RP side" of the pipeline.
We are looking at creating a tool to poll the Azure AD "all logins" report API endpoint and do something similar with that data. It outputs data in a similar JSON format so once we get the poling component in place, it should be possible to build some similar reporting and even potentially integrate the two together.
Joe K.


show

joe posted this 06 June 2016

That's a good question and something I can ask about. I think in general we'd be happy to share this.
There isn't really that much too it that is actually custom. The main tools (Elastic Search, Kibana and Logstash) are all Apache foundation open source things. The custom attribute store is almost certainly the most custom thing as is the claim rule that calls it. This is probably much more of a set up and management thing than a dev thing in general. The Kibana dashboard would be good to share too but it has a bunch of custom claim values that come from my org's demographics that we provision into AD in custom schema so we'd need to figure out how to purge that stuff.
JoeK.


show

patrickg posted this 07 June 2016

As you already noticed not every application trips this. How we worked around this limitation is forcing users to change their passwords every few months. In doing this

we can look for inactive accounts by the PasswordLastSet attribute. We don’t know the actual time they stop using their accounts but we know a point in time that they could not have logged in.



 

~Patrick

 

show

g4ugm posted this 07 June 2016

Providing the user never logs out, so for example hibernates their PC, then “lastlogon” of several years ago does not mean the account is inactive. Dave 

show

slavickp posted this 07 June 2016

Standard users are relatively easy - at least, we can cross-check the employeeId attribute with HR systems that know who is no longer paid. That, and lastLogonTimestamp give us good view. It’s service accounts that become a problem. Why oh why Quest Authentication Services does not log on UNIX users standard way, updating the attribute? On Windows, a service can run for extended periods, but regular maintenance (ok, patching) forces service accounts to log on.
With AAD and iPhones and new use patterns, all will change. We really need lastLogonTimestamp in AAD. I wonder if AAD DS reflects that? Else, whom can we bribe at MSFT to add it?
Regards
Slav
MCM-AD

show

patrickg posted this 08 June 2016

We have a GPOs in place to disable credential caching and force reboots of all domain-joined desktops/laptops weekly so it’s a non-issue for us.

 

~Patrick

 

 

show

g4ugm posted this 08 June 2016

In that case, where accounts are used on PC’s then no problem. I just know users are crafty and try and avoid logging off and on, and I have seen folks bitten by this in the past,, … Dave 

show

Close