Find users currently logged in using ldap?

Question

We have Openldap configured here and users are able to use ldap for login to client machines. But any way to check the users currently logged into machines using LDAP ? I would like to find which user has logged into which machine using LDAP ?

Answer 1

AFAIK LDAP does not implement session management - it just provides a directory service - and its data can be cached heavily elsewhere. Also it can provide information other than authentication. So there's no such thing as "logged into LDAP" and no way to practically measure it.

Presumably you maintain your LDAP implementation so that your users can access applications - you'd need to look at these applications to determine who currently has an open session (assuming the applications are stateful - HTTP is not).

Answer 2

Quoting symcbean, "there is no such thing as logged into ldap". But there is such a thing as users who authenticate through ldap.

More specifically, when you configure your host to use an authentication backend like ldap, the Name Service Switch (nsswitch) could (and arguably should) cache your user information to allow you to log into your system. Actually, from my point of view, it does not matter if data is being cached, it is still information comming from that backend.

Users whether they belong to NIS, Unix or ldap backend have an UID. In a proper configured system, UID from one backend should not match those in another backend (usually unix and ldap backends live together).

To finally make my point, you have a /etc/passwd, and the output of getent passwd, which should not match (ldap extends unix backend), therefore you know which users exists solely on ldap. Last, you have last :D which will tell you who logged in when from where, besides the syslog facility auth to double check. You could make a simple script that could tell you which ldap users logged in with this information on a per host basis.

NOTE: if you have duplicated users in unix and ldap, with same IDs then you'r on your own :)

Answer 3

I largely agree woth symcbean's answer (http://serverfault.com/questions/180918/find-users-currently-logged-in-using-ldap/180931#180931), but...

You could try parsing the DC's security logs, but that will return a lot of data. Depending on what you want to do with the data long-term, it may be worth sending into a database.

===

I'm not sure about OpenLDAP, but on AD, you can set Group Policy and/or a login script to run (in Windows Batch):

echo logon %username% %computername% %date% %time% >> \\shared\path\FILE_LOCATION.txt

Either parse out the username or computername from FILE_LOCATION.txt, or: Save by computername by:

echo logon %username% %computername% %date% %time% >> \\shared\path\%computername%.txt

Likewise, save by username with:

echo logon %username% %computername% %date% %time% >> \\shared\path\%username%.txt

Answer 4

Generally you cannot. You could try and implement it, so that some LDAP attribute is updated every time a user logs in and out an application, but this is overkill. From the question I am assuming that OpenLDAP is used as a central directory and users with credentials stored in it login to a number of linux machines in your network. If that is the case, then you need to install something like finger and then "finger" every machine in the network to see who is logged in.

Answer 5

Perhaps the client machines should authenticate via RADIUS instead — it does accounting in addition to authentication.

Answer 6

You could achieve it using LDAP+kerberos, but not every application that can logon to LDAP can use kerberos for authentication.

You can use FreeIPA to get it in a easy-to-use package.

Answer 7

Personally I like where gWaldo is going but like mfinni said, we might be talking about linux machines.

This may be overkill but... a Barracuda Web Filter can do that, IIRC.

I think you can do something like this with a barracuda web filter that uses LDAP authentication. IIRC the barracuda maintains a list of everyone currently authenticated to it. I used it in an AD environment but it should work with all flavors of LDAP.