moved from Incoming to Software Enhancements

h.b.furuseth@usit.uio.no wrote:

> One problem with back-config is that comments in slapd.conf
> are lost when converting to cn=config, and cn=config does
> not offer attributes in which to put comments.  So I suggest:
>
> Add something like 'MAY ( description $ info )' to object class
> olcConfig, and slapd.conf keywords with the same name.  description
> to describe the slapd entry, info for other notes about it.
>
> The slapd.conf keywords would allow admins to "upgrade" most comments in
> slapd.conf before converting to cn=config.  They'll need to insert any
> context into the comments though, and preferably move frontend directives
> with comments in slapd.conf to an explicit frontend database.
>
> I think it'd be best if these attribute names do not have a prefix
> like "olc", so they'll stand out a bit from the rest.  Thus the
> suggestion to stick to preexisting RFCed attributes.  However the
> attribute for general notes ('info') should probably be treated as
> X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do
> that with a preexisting attribute without that feature. The valsort
> overlay does, but I don' suggest to require valsort.

The X-ORDERED flag obviously cannot be added to existing schema elements; you 
need to define a new attribute.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

hyc@symas.com writes:
>h.b.furuseth@usit.uio.no wrote:
>> However the attribute for general notes ('info') should probably be
>> treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient
>> to do that with a preexisting attribute without that feature. The
>> valsort overlay does, but I don' suggest to require valsort.
>
> The X-ORDERED flag obviously cannot be added to existing schema
> elements;

That's why I said "treated as" X-ORDERED (when occurring in cn=config).
If that's too cumbersome though:

> you need to define a new attribute.

An attribute private to OpenLDAP should have a prefix like "olc",
but an RFCed attribute must wait till (X-)ORDERED is standardized.

I suggest "olc-note", then.  Still stands out from the rest since the
others do not use hyphens, and also sorts it before the other "olc"s.

-- 
Hallvard

The problem with adding an attribute is that this means that
comments are per-entry, and cannot be associated with specific
attribute values.

Having to write comments on an entry that apply to a specific
attribute value means having to describe the attribute's value within
the comment.  Most of my comments have to do with particular attribute
values, so this would be awkward -- both for writer and reader.

Below is an alternative design.  It supports commenting both
entries and attributes and working with commented ldif files in
an "expected" way.  The downside is that this design does not
provide a "natural" user interface.  Generic LDAP clients would
not readily associate comment text with the entries or attributes
commented.  The OpenLDAP client tools would need to be used to
produce and consume "commented ldif" files.

No reason why this alternative design could not be implemented
alongside the design previously proposed.


Have a cn=comment,cn=config subtree.  The dn is
index=X,attribute=Y,EntryUUID=Z,cn=comment,cn=config.  (Where index is
the index of the commented attribute when an attribute is
multi-valued.)  Keep all the comments there.

Index and attribute would be optional in the dn; when omitted the
comment is on the entry.

Pass a flag to ldapmodify and ldapadd so that comments are preserved
on input, and a flag for ldapsearch to output such comments.
The flag would only work on the cn=config DIT.

Comments appearing in an ldif before a dn are attached to the entry.
Comments appearing before an attribute are attached to the attribute.

Here are portions of a current slapd.conf file to provide some idea of
the comments that "need" preserving.  (Note also the use of newlines
and whitespace to make values readable.  But that's another
enhancement request.)

This config applies to a very dated version of openldap.  While
one might want to argue that documentation on, say, creating
a crypted password, belongs elsewhere, the only time anyone
needs to make a crypted password was to edit this config file.
So why have a separate document?

include         /etc/openldap/schema/core.schema
# Cosine is the X500 telephone schema, but we need attributes in there
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
# We don't want nis, but we do need it's attributes
include         /etc/openldap/schema/nis.schema
#include         /etc/openldap/schema/redhat/rfc822-MailMember.schema
#include         /etc/openldap/schema/redhat/autofs.schema
#include         /etc/openldap/schema/redhat/kerberosobject.schema
# Here's where inetMailRecipient is defined
include         /etc/openldap/schema/misc.schema
# TROW specific stuff
include         /etc/openldap/schema/trow.schema
# PWM specific stuff
include         /etc/openldap/schema/pwm.schema
# eduPerson
include         /etc/openldap/schema/eduperson.schema
# Amavisd-new stuff
include         /etc/openldap/schema/amavisd-new.schema

TLSCipherSuite !ADH:MEDIUM:HIGH:!SSLv2:@STRENGTH
#
# The next three lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.
#
# Used the procedure below (openssl-0.9.6b-35.7) to make a
# self-signed certificate for trixie.trow.com rsa key 1024 bits, expires
# 365 days from Jul 23, 2003.  (Karl)
#
#TLSCACertificateFile /var/openssl/demoCA/cacert.pem
#TLSCertificateFile /etc/openldap/ssl.crt/trixie.crt
#TLSCertificateKeyFile /etc/openldap/ssl.key/trixie-rsa-1024.key

#
# Self signed cert expires 2037.
#
TLSCertificateFile /etc/openldap/certificates/trixie-trow-com-cert.pem
TLSCertificateKeyFile /etc/openldap/certificates/trixie-trow-com-key.pem

# Nice as it is to be logging, Sam, it uses up a lot of resources.
# Turn off logging.
# loglevel 0
# Log search filter processing, config file parsing, access control processing
# (useful for debugging access rules)
#loglevel 224
# Log configuration file parsing (and errors!)
#loglevel 64
loglevel 256

# To generate a crypted password, try:
# perl -e 'print("rootpw {crypt}" . crypt("secretpassword","sa") . "\n");'
# "secretpassword" is the password, "sa" is the salt.
# (FYI, the salt used in /etc/passwd is the first 2 chars of the
# encrypted password.)
# We should really be using something better than crypt
# to protect our password database!
#rootpw         {crypt}elLJ3HpZEUmIA
#
# To generate a md5 password, try:
# perl -e 'print("rootpw {crypt}"
#                . crypt("secretpassword", "\$1\$somesalt")
#                . "\n");'
# (Yes, {crypt} is correct -- system crypt() call handles md5.)
# "secretpassword" is the password, "$1$somesalt" is the salt.
# (should be 8 chars in addition to the leading $1$).
# (FYI, the salt used in /etc/shadow is from the beginning of the
# encrypted password up to and including the third dollar sign.
# In the program above, all dollar signs should be written with
# a preceeding backslash.)

# Slave server replication. (for this database)
# (This is all probably unnecessary, because we're not making
# dynamic changes to the datbase anyhow.)
#
# Um, we could use kerberos instead of having a plaintext password
# here.  I can't say for sure, but it occurs to me that the
# kerberos keys can't be stored in the filesystem and protected
# better than by simply makeing them unreadable to anybody but root.
# As long as this file is only readable by root (and we're not
# worried about network sniffing) this should be sufficient.

# Need to turn this off in order to replicate to Openldap 2.3 and 2.4.
# Operational attributes are blown away by oracle2ldap daily anyway.
lastmod off

#
# Need to set a limit here as a lot of children accumulate over time
# and they each use close to 50MB of RAM.  3/30/04 Sam
#
threads 20

defaultaccess none

# Evaluated in order.

# CAREFUL, collating sequence could mean weird < compares.
# Give the standard sort of unix access.  Everybody can read
# most stuff, but can't see the password.  (Besides, more restrictive
# access doesn't work.)
# Be persnickity and do some filtering.
# (except that we're filtering them out when we load the database)
# access to filter="(&(objectclass=posixaccount)(uid<1000))" none
# access to filter="(&(objectclass=posixgroup)(memberuid<900))" none

# Order of access controls is very important!  First "access ..." match wins!
# Without a <control> after the <who>, it's only <what> that determines
# the match.

# As many of the 2.1 rules use the "by * + break" construct it might
# be possible to enhance performance by re-ordering the rules so that
# the most common matches are done early, but care is in (*ahem*) order.

# The uid of password maintainers _must_ be the primary uid!

# Some programs use the rootdn (Manager) to obtain global read/write
# access.  The only problem with this is oracle2ldap, where
# if the database gets changed while oracle2ldap has the
# database in read-only mode, the changes will be lost when
# the database is replaced with the new database.


#
# Shipinet and GADS need to read the entire DB.
# At the top to speed things up as ACL processing is hugely inefficient in this
# version of LDAP.
#
access to * 
       by dn.exact="cn=shipinet,ou=Service,dc=trow,dc=com" read
       by dn.exact="cn=gadirsync,ou=Service,dc=trow,dc=com" read
       by * + break


#
# Allow any authenticated users to see the intrinsic root dn.
#
access to dn.base=""
       by users read
       by * + break

#
#Oracle Self Service
#
access to dn.subtree="ou=People,dc=trow,dc=com"
       attrs=entry,preferredUid,oraclePClass,oracleId,preferredEmail,gec
os,cn
       by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" read
       by * + break
access to dn.subtree="ou=People,dc=trow,dc=com"
       attrs=objectClass
       by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" search
       by * + break


#
# Other global access
#
# (This is not really necessary and slows things down a _mite_, but is kind.)
# Shipinet does need these -- I think.
access to dn="^dc=trow,dc=com$"
       by * read


#
# Control access to the Service branch of the ldap database.
#

# Allow the "syscheck" service to read itself.
access to dn.base="cn=syscheck,ou=Service,dc=trow,dc=com"
       by self read
       by * + break

# PWM LDAP connection health checks.
# Remove 'pwmGUID' once the three instances are using their own GUID attrs.
access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$"
       attrs=entry,userPassword,pwmGUID,pwmLiveGUID,pwmTestGUID,pwmDevGUID
       by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" write
       by * + break

access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$"
       by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" read
       by * + break

# Apparently PWM needs to read its own objectClasses.
access to dn.base="cn=pwm,ou=Service,dc=trow,dc=com"
       attrs=entry,objectClass
       by self read
       by * + break

# Folks in Network Services can write, service DNs can bind.
access to dn.subtree=ou=Service,dc=trow,dc=com
       by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write
       by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write
       by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write
       by anonymous auth

#
# Contral access to the group branch.
#
access to dn.subtree="ou=Group,dc=trow,dc=com"
       by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read
       by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write
       by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write
       by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write
       by * compare

#
# The rest of this is access to the People branch.
#

#
# Binding
#
# These access lists disable binding to subsets of the directory.
#

# Accounts must be active for the user to bind.
#
# When firstActivated is missing, the account's not yet activated.
# If the deactivated attribute is present then the account's
# been deactivated.
access to dn.subtree="ou=People,dc=trow,dc=com"
       filter=(|(!(firstActivated=*))(deactivated=*))
       attrs=entry
       by anonymous none
       by * + break

#
# Configure the Service dn-s access to the People subtree.
#

# Try to put services that need to sync with LDAP, thus reading the whole direct
ory (or a large
# part) as near the top of this section as possible, as complex ACL processing a
gainst a large
# number of entries degrades performance substantially.

#
# Uniflow printing system.
#
access to dn.subtree="ou=People,dc=trow,dc=com"
       filter=(&(objectClass=AICPerson)(firstActivated=*)(!(deactivated=*)))
       attrs=entry,preferredUid,preferredEmail,organizationalStatus,gecos,consti
tuency,objectClass,telephoneNumber,AICDepartment
       by dn.exact="cn=uniflow,ou=Service,dc=trow,dc=com" read
       by * + break

#
# nss_ldap (the glibc library and pam)
#

# (objectclass could probably be just search, or we could take the objectclass
# filter out of /etc/ldap.conf and add the filter here and allow no access
# to objectclass.)
access to dn.subtree="ou=People,dc=trow,dc=com"
       attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,userPassword,logi
nShell,gecos,description,shadowLastChange,shadowMin,shadowMax,shadowWarning,shad
owInactive,shadowExpire,shadowFlag,description,objectclass,preferredUid,makeWWW,
useEmail,useDialup,firstActivated,deactivated
       by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read
       by * + break

#
# postfix (mail mta, really just some of it's various processes)
#

access to dn.subtree="ou=People,dc=trow,dc=com"
       attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,gecos,mailrouting
address,maillocaladdress,preferredemail,rejectMail
       by dn.exact="cn=postfix,ou=Service,dc=trow,dc=com" read
       by * + break