IBM Security Directory Server (SDS) has been the go-to LDAP solution for lot of customers around the world, some of them are using it to achieve simple business needs, others are using it for complex and advanced use cases, it also comes bundled with the majority of IBM products including the IAM solutions, Domino and others, for audit purposes, you may find yourself in need to feed you SIEM solution with SDS logs, specially when SDS is used as a critical component such as a user repository or an authenticator…In this article, I’ll show you how you can achieve this integration using the built-in tool called idslogmgmt.
idslogmgmt a powerful tool that comes out-of-the box with your SDS, its primary use it to rotate and archive log files without the need to third party tools, but it is also used among many administrators to send log files to the QRadar, since idslogmgt uses syslogs protocol to send the events, you can basically integrate it with any other SIEM solution as long as it supports LEEF parsing, otherwise, you may need to create your own parser make the received events readable, see appendix A for more information. Idslogmgmt uses a combination of Java and JS scripts called Assembly Lines (ALs) to do all the magic, which means that IBM Security Directory Integrator (SDI) must be installed on the same machine where LDAP server is running in order to execute these ALs.
PS: We will only focus on sending audit.log events to QRadar, you can send more events such as ibmslapd, audit, tools, bulkload, admin, admin audit, db2cli, replication, and ddsetup as per the documentation here.
The following high level architecture describes how idslogmgmt is integrated with QRdar/SIEM.
- LDAP Client: Akbank’s applications using with SDS
- SDS Server: The main LDAP instance server
- Audit.log: The audit log file used by SDS to log all activated operations
- Idslogmgmt: The built-in log management tool
- Security Directory Integrator ALs: Pre-installed Assembly Lines used by idslogmgmt
- SIEM: Security Information and Event Management System
- The LDAP client connects to the LDAP server to perform an operation, e.g search, modify, compare…
- The LDAP server performs the requested operation and writes a new entry on audit.log file.
- By default, idslogmgmt is triggered each 15 minutes to run the Assembly Lines using IBM Directory Integrator.
- The Assembly Lines check for new audit.log entries and convert them to LEEF format.
- The syslog message is built and sent to the SIEM using either UDP or TCP protocol.
The goal of this article is not to describe the installation steps of SDS or SDI, but here are a few things to take in consideration before and after the installation:
- If you are using Linux, make sure that libstdc++ package is installed before performing SDI installation, otherwise, SDI will not be able to startup.
- idslogmgmt supports both TDI (Tivoli Directory Integrator) 7.1.1 and SDI (Security Directory Integrator) 7.2, both products are supported by IBM and achieve the same results, although, after the installation of the base product, make sure to install the latest Fix Pack available, I’ve seen some weird issues while using the base version, so always update the product to the latest version.
- On Redhat, you may get some Java errors while installing SDI/TDI, if you do, make sure to disable SELinux and try again.
- Make sure to open firewall ports if needed between the LDAP Server machine and the SIEM, the ports include 514 if you’re sending logs through UDP or 601 if using TCP.
Enable Logs Integration
To enable the log integration, you basically have 2 options: using the CLI or the GUI (Web Admin Tool), the first option gives you more control and understanding of the involved parameters and properties, the only down side is that it requires a full restart of the LDAP instance which is not always possible, that’s why I will explain the second option which is restartless, you can always check the public documentation here for using the CLI.
Now, follow carefully the below steps:
1- If you did not do so already, click Server administration in the Web Administration navigation area.
2- Click Logs in the expanded list.
3- Click Modify log settings.
4- In the Log Name column, click Server audit log.
Make sure audit logs are enabled and operations to log are checked correctly
5- Under Server audit log settings, click Log Management Integration.
6- Select Enable QRadar Integration.
7- In the Host field, specify the host name or IP address of the QRadar server.
8- When you specify the host name or IP address, the value is stored and read from the configuration file.
If you do not specify a value in this field, local host is used by default.
The attribute ibm-slapdLogEventQRadarHostName is associated with this field.
9- In the Syslog Port field, specify the syslog port number on which the QRadar server listens.
When you specify the syslog port number, the value is stored and read from the configuration file
If you do not specify a value in this field, 514 is assigned as the default syslog port number. For more information, see Ports used by QRadar.
The attribute ibm-slapdLogEventQRadarPort is associated with this field.
10- In the Map file location field, specify the path and file name of the map file that sets up the various QRadar attributes for the event.
The default location is /opt/IBM/ldap/V6.4/idstools/idslogmgmt/.
The attribute ibm-slapdLogEventQRadarMapFilesLocation is associated with this control
Make sure the ldap instance owner has permissions to execute idslogmgmt command and has ownership over TDI installation path.
You can start idslogmgmt tool using the below command
if you get the above results, it means that idslogmgmt is running as expected, now you can check your SIEM to see the received syslog packets, you can also monitor your network interface to see the outbound traffic using tcpdump:
tcpdump -nnAs0 -i eth0 udp port 514
where eth0 is the concerned interface.
Monitor idslogmgmt process
You may want to make sure that idslogmgmt is running all the time to make sure you’re not missing any event, you can either do that through third party tools, but I like ti this locally, that’s why I wrote a simple shell script to check if idslogmgmt is running, if not, it will try to start it, the script then is registered as Cron job and executed each 5 minutes, if you’re curious, this is how the script looks like:
#The following function checks if idslogmgmt is running using the pid file
if [[ -n "$pid" && $(ps -p $pid | wc -l) -eq 2 ]]
echo "[+] Process already running..."
echo "[+] Process is not running...Starting the process..."
#The following function starts idslogmgmt and forward the output to /var/log/checkProcess.log
/opt/IBM/ldap/V6.4/sbin/idslogmgmt -I ldapinst & >> /var/log/checkProcess.log 2>&1
if [ "$retval" == "1" ]
echo "[+] sleeping for 30 seconds and checking the status after waking up"
if [ "$retval" == "0" ]
echo "[-] looks like the process is broken, will clean files and try again.."
#Process is unable to start because it wasn't stopped properly before
#Clean remaining files from the previous run and start again
echo "[+] cleaning idslogmgmt.pid file"
echo "[+] cleaning idslogmgmt.lock folder"
rm -rRf /home/ldapinst/idsslapd-ldapinst/tmp/idslogmgmt.pid
rm -rRf /home/ldapinst/idsslapd-ldapinst/etc/idslogmgmt.lock
#echo $! > /tmp/portal.pid
now, while logging in as the ldap instance owner, set a Cron job to run the shell script:
*/5 * * * * /path/to/my/shellScript.sh
Once done, you can monitor /var/log/checkProcess.log for the script’s output, make sure the instance owner has write access to mentioned path.
If your SIEM doesn’t support LEEF parsing out-of-the box, you will need to develop your own, to help you with that, I have attached a file containing LDAP Audit entry for each supported operation and its respective syslog message, I also created a small list containing internal syslog message attributes and their respective descriptions:
src: Source IP address
usrName: The user attempting the request
accStatus: The user's account status
srcPort: The source port
authChoice: Authetication method used
devtime: devTime Date Yes The device time is the raw event date and time generated by your appliance providing the LEEF event.
dst: destination IP, typically the SDS Server
Sev: The severity
cat: the audit version + the operation type
accountName: the account name of the user doing the operation
devTimeFormat: the format used by "devTime" attribute, by default, it's yyyy-MM-dd'T'HH:mm:ss.SSSz
dstPort: The SDS port
opResult: The operation result (in this case, it's failure: Invalid credentials)
typesOnly: If typesOnly is set to TRUE, only the attribute types will be sent to the client without the attribute values.
derefAliases :indicates whether to dereference an aliases encountered during the search, read more here: https://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html
searchFilter: The filter used during the search operation
numEntries: Number of entries returned during the search operation
searchBase: The search base used during the search operation
searchScope: The scope of the search operation
objectName: The entry to be modified
modTypes: modification type (replace or add)
modAttrs: attribute to be modified
attributes: In an add operation, the "attributes" attribute will list all attributes to be added
entryName: indicates the entry's DN to be added
entryDeleted: indicates the entry to be deleted.
entry: If a compare operation is successful, this attribute's value will be the DN that match the compare request's input.
Latest posts by AYOUB BAHAR (see all)
- Facebook has yet proven than user privacy isn’t a priority! - April 21, 2020
- ISIM REST API Samples - July 10, 2019
- IBM DB2 HADR: Dummy guide - April 13, 2019