https://github.com/aidan-/ldap-access-parser
A simple utility to parse LDAP (389ds, RHDS, Fedora DS, etc) access logs into contextual aware events for analysis
https://github.com/aidan-/ldap-access-parser
access-log fedorads ldap ldap-access-parser logging openldap parse
Last synced: 5 months ago
JSON representation
A simple utility to parse LDAP (389ds, RHDS, Fedora DS, etc) access logs into contextual aware events for analysis
- Host: GitHub
- URL: https://github.com/aidan-/ldap-access-parser
- Owner: aidan-
- License: mit
- Created: 2015-10-16T13:40:07.000Z (over 10 years ago)
- Default Branch: master
- Last Pushed: 2016-04-04T10:46:16.000Z (about 10 years ago)
- Last Synced: 2024-06-20T05:03:35.960Z (almost 2 years ago)
- Topics: access-log, fedorads, ldap, ldap-access-parser, logging, openldap, parse
- Language: Go
- Homepage:
- Size: 8.79 KB
- Stars: 14
- Watchers: 7
- Forks: 10
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
LDAP Access-log Parser [](https://travis-ci.org/aidan-/ldap-access-parser/)
======================
LDAP Access-log Parser (LAP) is a simple program designed to parse 389 Directory Server (also Fedora Directory Server, Red Hat Directory Server, etc) access logs into individual context aware events ready to be sent to upstream services like ElasticSearch for further analysis.
This application doesn't handle the sending of data to specific endpoints, but that can easily be achieved by piping to something like [log-courier](https://github.com/driskell/log-courier) or [logstash](https://www.elastic.co/products/logstash).
Usage
-----
Use the `-h` flag to view application usage.
```
Usage of ./lap:
-format string
format to output log events. possible values are 'json' or 'xml'. (default "json")
-tail
tail the log file to receive future events
```
You can begin parsing logs with a simple command:
```
./lap -tail /path/to/access_log
```
This continue to parse the file even if it gets rotated.
Design
------
The applications functionality and output format tries to follow the design specification laid out [here](http://directory.fedoraproject.org/docs/389ds/design/audit-events.html) as much as possible, however there are a few use-cases which were not covered in the design spec that needed to be defined.
More detailed information about the access log format is available in the [Red Hat Directory Server documentation](https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Configuration_and_Command_Reference/logs-reference.html).
Example Output
--------------
Given the raw access log input of:
```
[21/Apr/2009:11:39:55 -0700] conn=14 fd=700 slot=700 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2009:11:39:55 -0700] conn=14 op=0 BIND dn="" method=sasl version=3 mech=DIGEST-MD5
[21/Apr/2009:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[21/Apr/2009:11:39:55 -0700] conn=14 op=1 BIND dn="uid=jdoe,dc=example,dc=com" method=sasl version=3 mech=DIGEST-MD5
[21/Apr/2009:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=jdoe,dc=example,dc=com"
```
The JSON output would look like:
```json
{"time":"21/Apr/2009:11:39:55 -0700","client":"207.1.153.51","server":"192.18.122.139","connection":14,"ssl":false,"operation":0,"authenticateddn":"__anonymous__","action":"BIND","requests":["BIND dn=\"\" method=sasl version=3 mech=DIGEST-MD5"],"responses":["RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress"]}
{"time":"21/Apr/2009:11:39:55 -0700","client":"207.1.153.51","server":"192.18.122.139","connection":14,"ssl":false,"operation":1,"authenticateddn":"uid=jdoe,dc=example,dc=com","action":"BIND","requests":["BIND dn=\"uid=jdoe,dc=example,dc=com\" method=sasl version=3 mech=DIGEST-MD5"],"responses":["RESULT err=0 tag=97 nentries=0 etime=0 dn=\"uid=jdoe,dc=example,dc=com\""]}
```
and XML output would look like:
```xml
21/Apr/2009:11:39:55 -0700
207.1.153.51
192.18.122.139
14
false
0
__anonymous__
BIND
BIND dn="" method=sasl version=3 mech=DIGEST-MD5
RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
21/Apr/2009:11:39:55 -0700
207.1.153.51
192.18.122.139
14
false
1
uid=jdoe,dc=example,dc=com
BIND
BIND dn="uid=jdoe,dc=example,dc=com" method=sasl version=3 mech=DIGEST-MD5
RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=jdoe,dc=example,dc=com"
```
TODO/Notes
-----
- If a connection was initialized before the log monitoring began, the events associated with that connection number will be skipped. This should probably be a configurable option.
- Connections that disconnect without any operations do not get outputted as an event. Is this okay?