LDAP: Last logon timestamp recordings with UCS

In relatively many UCS environments, system administrators have not yet developed consistent processes for detecting, deactivating or deleting inactive user accounts. Over the years, accounts that have not been used for a long time accumulate in the LDAP directory. At Univention, we have developed a new UCS extension on behalf of a customer, which helps to detect such unused accounts. The Lastbind-Overlay-Module and a new Python script detect inactive accounts on LDAP servers, even in large environments with several LDAP instances and distributed system roles.

In this article, I will first explain how admins of mixed environments read the credentials from AD/Samba and introduce how this works in the LDAP directory service. I will also demonstrate how to activate the Lastbind-Overlay-Module in your UCS environment and use our script univention_lastbind.py to contact all LDAP instances of the domain and collect the timestamps of the last user logins.

Reading Samba/AD credentials

If you are supervising an environment where users primarily authenticate themselves against Samba/AD, you’re in the clear: The AD attributes LastLogon, LastLogonTimeStamp and LastLogonDate store information about user logins. The only challenge is that Linux admins may have to convert the values in these attributes because it is a time format that is more common in Windows-based systems, where the time is counted in 100-nanosecond intervals starting at 01.01.1601, 0 o’clock UTC. Unix systems (which also include Linux) use elapsed seconds from 01.01.1970, 0 o’clock UTC (The Epoch). On the Internet, you can find some conversion tools for Windows time data, e. g. the EpochConverter. If you do this by hand, you need to convert from nanaseconds to seconds (devide by 10000000) and bridge the gap between 1601 and 1970 (11644473600 seconds).

Reading and converting on the commandline:

root@ucs01:~# univention-s4search cn=mary lastLogonTimestamp | grep lastLogonTimestamp
lastLogonTimestamp: 132466226840838210
root@ucs01:~# date -d @$(echo $(( 132466226840838210/10000000-11644473600 )))
Do 8. Okt 11:24:44 CEST 2020

In mixed environments, where there are also services that use the OpenLDAP directory service exclusively, this is not very helpful. A workaround that has proven to be effective is to create password policies that force users to change their password regularly – those who have not renewed their expired password after a certain period were considered inactive. However, this is not very practical, and that is why we have integrated the Lastbind-Overlay-Module slapo-lastbind into UCS.

slapo-lastbind and Univention Corporate Server

When implementing the Lastbind-Overlay-Module , we had to make sure that the special features in Univention Corporate Server were accurately displayed. For example, the recording of the time stamp always takes place only on the LDAP server to which the user logs on. Depending on the configuration, however, there can be several of these servers in a UCS environment with different system roles (DC Master, DC Backup, and DC Slave). Also, users log on to different LDAP servers for different services.

Although the individual LDAP servers exchange data with each other using the listener mechanism, the only writable copy is stored with the DC Master. Everything that lastbind records is not being replicated – and that is not useful either. Therefore, we have adapted the configuration so that after activating the Overlay-Module, an attribute called authTimestamp records the timestamp of a successful LDAP bind. This attribute is excluded from replication.

Activating the Lastbind-Overlay-Module

Please note that the overlay module can only be used with UCS version 4.4-3 errata 499 or higher. The activation is quickly done through the Univention Configuration Registry. To do this, the administrator sets the UCR variable ldap/overlay/lastbind to yes for all systems with an LDAP service. It does not make sense to activate the module only on some computers, because depending on the environment, some logon information would get lost otherwise. After activating the module, the respective LDAP server must be restarted.

Another UCR variable called ldap/overlay/lastbind/precision defines the time in seconds that must elapse before the authTimestamp attribute is updated. This prevents a large number of write operations that could affect performance.

Another important note: Once the Lastbind-Overlay-Module is activated, it should not be deactivated again. It adds an LDAP scheme definition for the authTimestamp attribute. If the module is no longer active and entry with an authTimestamp attribute value is changed, replication will cause an error because the attribute is unknown.

You can find more information in our manual and in a Knowledge Base article.

Reading out the information

Since the authTimestamp attribute is excluded from replication as mentioned, we have created a script: /usr/share/univention-ldap/univention_lastbind.py. It collects the last value of the attribute from all accessible LDAP servers of the UCS domain. It can also save and update the timestamp of a user’s last login in the extended UDM attribute lastbind. The extended attribute lastbind is mapped to the LDAP attribute univentionAuthTimestamp.

You can run the script by hand in the shell or create a cronjob that takes care of it once a day for example. We recommend to automate the collection and create a cronjob for it. You can find more information about this in our manual.

Attention: Before using the script, you should check if all registered servers are reachable. Otherwise, the runtime will be extended significantly or other errors will occur.

Further challenges

Both attributes, authTimestamp, and univentionAuthTimestamp, use the GeneralizedTime as their date format. This means that in case of doubt, this information must also be converted. In mixed environments with LDAP and Samba/AD, both authentication methods must be observed to create meaningful lists of inactive accounts.

The evaluation of the collected information is left to the UCS administrators. A useful evaluation could be a customized Univention Directory Report, which generates a corresponding report.

Do you have any suggestions for improvement? Or are you already using the feature and would like to share tips with other UCS users? Then please leave a comment or discuss it with us at help.univention.com.