Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
O
OpenLDAP
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Dragoș Haiduc
OpenLDAP
Commits
21b46054
Commit
21b46054
authored
17 years ago
by
Quanah Gibson-Mount
Browse files
Options
Downloads
Patches
Plain Diff
LDIF output format example. Still to fix modulepath example for auditlog
parent
c3f88226
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/guide/admin/overlays.sdf
+59
-7
59 additions, 7 deletions
doc/guide/admin/overlays.sdf
with
59 additions
and
7 deletions
doc/guide/admin/overlays.sdf
+
59
−
7
View file @
21b46054
...
...
@@ -69,15 +69,67 @@ H3: Access Logging Configuration
H2: Audit Logging
This overlay records changes on a given backend database to an LDIF log
file.
The Audit Logging overlay can be used to record all changes on a given backend database to a specified log file.
H3: Overview
If the need arises whereby changes need to be logged as standard LDIF, then the auditlog overlay {{B:slapo-auditlog (5)}}
can be used. Full examples are available in the man page {{B:slapo-auditlog (5)}}
H3: Audit Logging Configuration
If the directory is running vi {{F:slapd.d}}, then the following LDIF could be used to add the overlay to the overlay list
in {{B:cn=config}} and set what file the {{TERM:LDIF}} gets logged to (adjust to suit)
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: {2}auditlog.la
>
> dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcAuditLogConfig
> olcOverlay: auditlog
> olcAuditlogFile: /tmp/auditlog.ldif
In this example for testing, we are logging changes to {{F:/tmp/auditlog.ldif}}
A typical {{TERM:LDIF}} file created by {{B:slapo-auditlog (5)}} would look like:
> # add 1196797576 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
> dn: dc=suretecsystems,dc=com
> changetype: add
> objectClass: dcObject
> objectClass: organization
> dc: suretecsystems
> o: Suretec Systems Ltd.
> structuralObjectClass: organization
> entryUUID: 1606f8f8-f06e-1029-8289-f0cc9d81e81a
> creatorsName: cn=admin,dc=suretecsystems,dc=com
> modifiersName: cn=admin,dc=suretecsystems,dc=com
> createTimestamp: 20051123130912Z
> modifyTimestamp: 20051123130912Z
> entryCSN: 20051123130912.000000Z#000001#000#000000
> auditContext: cn=accesslog
> # end add 1196797576
>
> # add 1196797577 dc=suretecsystems,dc=com cn=admin,dc=suretecsystems,dc=com
> dn: ou=Groups,dc=suretecsystems,dc=com
> changetype: add
> objectClass: top
> objectClass: organizationalUnit
> ou: Groups
> structuralObjectClass: organizationalUnit
> entryUUID: 160aaa2a-f06e-1029-828a-f0cc9d81e81a
> creatorsName: cn=admin,dc=suretecsystems,dc=com
> modifiersName: cn=admin,dc=suretecsystems,dc=com
> createTimestamp: 20051123130912Z
> modifyTimestamp: 20051123130912Z
> entryCSN: 20051123130912.000000Z#000002#000#000000
> # end add 1196797577
H2: Chaining
...
...
@@ -230,7 +282,7 @@ Whenever an entry with this object class is retrieved, the search is performed.
has to be a subtype of {{F:labeledURI}}. The attributes and values present in
the search result are added to the entry unless {{F:member-ad}} is used (see
below).
* {{F:member-ad}}: if present, changes the overlay behavio
u
r into a dynamic group.
* {{F:member-ad}}: if present, changes the overlay behavior into a dynamic group.
Instead of inserting the results of the search in the entry, the distinguished name
of the results are added as values of this attribute.
...
...
@@ -275,7 +327,7 @@ Let's apply it to the following entry:
> objectClass: groupOfNames
> labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson)
The behavio
u
r is similar to the dynamic list configuration we had before:
The behavior is similar to the dynamic list configuration we had before:
whenever an entry with the {{F:groupOfNames}} object class is retrieved, the
search specified in the {{F:labeledURI}} attribute is performed. But this time,
only the distinguished names of the results are added, and as values of the
...
...
@@ -285,7 +337,7 @@ This is what we get:
!import "allusersgroup-en.png"; align="center"; title="Dynamic group for all users"
FT[align="Center"] Figure X.Y: Dynamic Group for all users
Note that a side effect of this scheme of dy
m
amic groups is that the members
Note that a side effect of this scheme of dy
n
amic groups is that the members
need to be specified as full DNs. So, if you are planning in using this for
{{F:posixGroup}}s, be sure to use RFC2307bis and some attribute which can hold
distinguished names. The {{F:memberUid}} attribute used in the {{F:posixGroup}}
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment