Re: syncrepl 2.4 issue from 2.3 master
by FRLinux
On Fri, Sep 18, 2009 at 11:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> You will need to upgrade your release to fix an issue with the change in
> time formats between 2.3 and 2.4. I would advise using 2.4.18. This will
> require you to build it yourself with a later BDB version, as the Debian
> 2.4.11 build is compiled against a version of BDB that is not supported with
> OpenLDAP 2.4.12 and later.
Hello Quanah,
I guess you recommend BDB 4.8 at the minute?
> Read the 2.4 Admin guide to start, the TLS options for syncrepl are now part
> of the syncrepl stanza. You will want to configure it there.
Right, thanks for that, back to the basics :)
Cheers,
Steph
14 years
Re: slapd consumer deletes entries
by Tony Smith
On 9/19/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Saturday, September 19, 2009 9:07 AM +0100 Tony Smith
> <tony.smith.124(a)googlemail.com> wrote:
>
>
>
> >
> > > thank you Quanah, very much appreciated! I copied the config from some
> > > howto and didn't really understand how each option works.
> > >
> >
> > Update: the deletion still happens after I commented out the attrs
> > line, or changed it to attrs="*,+". I tried to comment out other
> > options as well, and it seems that after leaving out these options the
> > problem is gone:
> >
>
> Hi Tony,
>
> Did you reload your replica after fixing the syncrepl stanza? If you
> hadn't, it meant that all of your entries in the replica continued to be
> broken, which is why deletions continued.
>
>
> > #filter="(objectClass=*)"
> > #scope=sub
> > #schemachecking=off
> >
> > I don't really understand the impact of each; I post it here in case
> > it might be helpful for someone else.
> >
>
> Those are already the default values. Commenting them out would have had
> no effect. See above.
Hi Quanah,
yes I did resync after each change by running:
/opt/openldap-2.3.43/lib/slapd -u openldap -g openldap -d 1 -c rid=001,csn=0
I re-checked again:
- stop slapd on consumer
- resync using the above command (Ctrl-C to stop when the resync seems
done, no more messages)
- add an entry on provider
- uncomment these options
- start slapd on consumer
and the deletions re-appear again.
Regards,
Tony
14 years
Re: slapd consumer deletes entries
by Tony Smith
On 9/18/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Friday, September 18, 2009 7:37 PM +0100 Tony Smith
> <tony.smith.124(a)googlemail.com> wrote:
>
>
> > Hello,
> >
>
> Hi Tony,
>
> This is due to a common mistake of using "attrs=*", which removes the
> operational attributes that syncrepl uses to track changes. I really wish I
> knew where people got this from, because 99.999999% of the time you do not
> want to use this value. You should not specify the attrs= line at all in a
> syncrepl configuration unless you really really need to limit replication in
> some way. If you want to keep the attrs line, change it to attrs="*,+" so
> that all attributes are replicated.
thank you Quanah, very much appreciated! I copied the config from some
howto and didn't really understand how each option works.
Regards,
Tony
14 years
2.3.43, and a variety of problems.
by Brandon Hume
I don't know whether 2.3.43 is new enough to NOT be told to go to hell,
but it's the latest of the 2.3.x series and I can't get migrated to 2.4
until I get slurpd gone... and oddly enough, I think turning off slurpd
caused some of my problems.
This morning our two slaves and master server began experiencing bad
sync lag... the slaves were close to two or more hours behind the
master. I discovered that a large automated job had touched over thirty
thousand entries and altered the values of a lot of attributes (it was a
course enrollment update, as it happens).
I *suspect* that the huge number of updates overflowed the syncprov
session log and the slaves moved from small updates to whole-entry
updates. My syncprov session log was set to 500... which I think was
hideously undersized.
Am I correct in my assumption?
Stemming from that, I've noticed that trying to use LDAP to alter
anything in the cn=config tree - whether it happens to be to change the
session log size, or to add a new index - causes slapd to freeze. Not a
true hang, as it continues to accept connections, but all operations are
deferred and pending, even though slapd's CPU usage remains low. I can
kill and restart slapd and I'm okay. Also, altering cn=config by
editing the on-disk ldif files while slapd is dead causes no problem.
And a third thing: does ~3h to add 250k entries to a new database, using
'slapcat -q' sound ridiculously long?
14 years
syncrepl 2.4 issue from 2.3 master
by FRLinux
Hello, My master is a freebsd 7.2 server running 2.3.38 at the moment.
I am trying to get the replication going to a 2.4 server. Using the
same configuration file, it is able to replicate to another 2.3 server
without a hitch so I am guessing I am doing something foolish. I
understand ACLs have changed between the 2 versions but cannot see my
mistake. This is the configuration from my 2.3 master:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/courier.schema
include /usr/local/etc/openldap/schema/ISPEnv2.schema
include /usr/local/etc/openldap/schema/amavis.schema
include /usr/local/etc/openldap/schema/samba.schema
include /usr/local/etc/openldap/schema/freeradius.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
referral ldaps://masterldap.example.com
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
moduleload back_bdb
# moduleload back_ldap
# moduleload back_ldbm
# moduleload back_passwd
# moduleload back_shell
backend bdb
# security restrictions
access to attrs=userPassword,sambaNTPassword,sambaLMPassword
by dn.base="cn=Administrator,dc=example,dc=com" write
by dn.base="cn=ldaprep,dc=example,dc=com" read
by dn.base="cn=samba,ou=specialusers,dc=example,dc=com" write
by anonymous auth
by self write
#following sections seperated so that we can specify other groups
later that can manage specific services
#who can alter users?
access to dn.one="ou=people,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
#who can make users?
access to dn.base="ou=people,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
#ensure users don't screw up things they shouldn't be allowed play with.
access to attrs=objectClass,uid,uidNumber,gidNumber,homeDirectory,loginShell,shadowLastChange,shadowMin,shadowMax,shadowWarning,shadowInactive,shadowExpire,shadowFlag,quota
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
#ensure mail users dont screw up their own settings
access to attrs=mail,mailbox,defaultdelivery,amavisVirusLover,amavisBannedFilesLover,amavisSpamLover,amavisBypassVirusChecks,amavisBypassSpamChecks,amavisSpamQuarantineTo
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
#manage mail settings
access to dn.base="ou=aliases,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.one="ou=aliases,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=mailscripts,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=domains,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.one="ou=domains,dc=example,dc=com"
by dn.base="cn=Administrator,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="" by * read
#control of who gets to make acls and who can alter acls not specified above
access to dn.children="ou=acldomain,dc=example,dc=com"
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by dn.base="cn=Administrator,dc=example,dc=com" write
by * read
access to *
by dn.base="cn=Administrator,dc=example,dc=com" write
by self write
by users read
by anonymous read
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Administrator,dc=example,dc=com"
rootpw {MD5}xxxxxxxxxxxxxxxxx
password-hash {CRYPT}
password-crypt-salt-format "$1$%.8s"
directory /var/db/openldap-data
TLSCACertificateFile /usr/local/etc/openldap/cert/cacert.pem
TLSCertificateFile /usr/local/etc/openldap/cert/servercrt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/cert/serverkey.pem
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
directory /var/db/openldap-data
# Indices to maintain
index cn eq
index objectClass eq,pres
index uid,uidNumber,gidNumber,memberUid eq,pres
index mail eq
index entryUUID eq
Now onto my LDAP slave, this is a Debian 5.0 install running their
packaged LDAP Server (2.4.11), here is my configuration:
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/courier.schema
include /etc/ldap/schema/ISPEnv2.schema
include /etc/ldap/schema/amavis.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/freeradius.schema
include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
database bdb
suffix "dc=example,dc=com"
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=example,dc=com" write
by anonymous auth
by self write
by * none
#ACLs
access to attrs=userPassword
by dn.base="cn=admin,dc=example,dc=com" write
by anonymous auth
by self write
access to dn.one="ou=people,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=people,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to attrs=objectClass,uid,uidNumber,gidNumber,homeDirectory,loginShell,shadowLastChange,shadowMin,shadowMax,shadowWarning,shadowInactive,shadowExpire,shadowFlag,quota
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to attrs=mail,mailbox,defaultdelivery,amavisVirusLover,amavisBannedFilesLover,amavisSpamLover,amavisBypassVirusChecks,amavisBypassSpamChecks,amavisSpamQuarantineTo
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=aliases,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.one="ou=aliases,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=mailscripts,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.one="ou=mailscripts,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="ou=domains,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.one="ou=domains,dc=example,dc=com"
by dn.base="cn=admin,dc=example,dc=com" write
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by * read
access to dn.base="" by * read
access to dn.children="ou=acldomain,dc=example,dc=com"
by group.base="cn=sysadmins,ou=acldomain,dc=example,dc=com" write
by dn.base="cn=admin,dc=example,dc=com" write
by * read
access to *
by dn.base="cn=admin,dc=example,dc=com" write
by self write
by users read
by anonymous read
rootdn "cn=admin,dc=example,dc=com"
rootpw {MD5}xxxxxxxxxxxxxxxx
password-hash {CRYPT}
password-crypt-salt-format "$1$%.8s"
TLSCACertificateFile /etc/ldap/cert/cacert.pem
# Indices to maintain
#index objectClass eq
index cn eq
index uid,uidNumber,gidNumber,memberUid eq,pres
index mail eq
index entryUUID eq
syncrepl rid=124 \
provider=ldaps://masterldap.example.org:636 \
type=refreshAndPersist \
searchbase="dc=example,dc=com" \
scope=sub \
filter="(objectClass=*)" \
attrs="*" \
schemachecking=off \
bindmethod=simple \
binddn="cn=ldaprep,dc=example,dc=com" \
credentials=xxxxxxxx
Even with this, i get (this is the end of a slapd -d 500)
Config: ** successfully added syncrepl "ldaps://masterldap.example.com:636"
=> ldap_bv2dn(cn=Subschema,0)
<= ldap_bv2dn(cn=Subschema)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=subschema)=0
main: TLS init def ctx failed: 1
slapd stopped.
connections_destroy: nothing to destroy.
Lists suggest that cacert might not be right, i checked mine and did
not find any problem with it (and yes, it works will all my 2.3
slaves):
# openssl x509 -text -in /etc/ldap/cert/cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e8:01:da:01:ac:05:15:ad
Signature Algorithm: md5WithRSAEncryption
Issuer: C=IE, ST=Dublin, L=Dublin, O=ORGANISATION,
CN=masterldap.example.org
Validity
Not Before: May 31 15:57:37 2006 GMT
Not After : May 30 15:57:37 2011 GMT
Subject: C=IE, ST=Dublin, L=Dublin, O=ORGANISATION,
CN=masterldap.example.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
[snip]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
[snip]
X509v3 Authority Key Identifier:
[snip]
DirName:/C=IE/ST=Dublin/L=Dublin/O=ORGANISATION/CN=masterldap.example.org
serial:E8:01:DA:01:AC:05:15:AD
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
[snip]
-----BEGIN CERTIFICATE-----
[snip]
-----END CERTIFICATE-----
Any help appreciated.
Cheers,
Steph
14 years
Re: Using different encryption on localhost and networked connections
by Michael Ströder
Robert,
please stay on the openldap-software list. Cc:-ed it again.
Robert Henjes wrote:
> That's right. Concluding your recommendations and comments:
>
> * ldaps is best choice for a public reachable LDAP server, when secure
> transmission is required
IMHO yes. StartTLS is ok too if the number of client configurations is rather
low (e.g. services configured by admins) since then problems are sorted out
during integration testing. If you have many LDAP clients with normal
end-users there's not much you can do.
> * client certificates are not recommended for use, when a client (not
> always interactive) service has to verify its authentity / authorization
> to access the ldap service in general.
Yes.
> Alternative solutions:
> - Using a bind user with shared password
I'd recommend to give each service (e.g. Linux boxes with pam_ldap etc.) a
different bind-DN and password. Then if one services is compromised it does
not affect the others. It also provides better monitoring.
Because normally such services use simple bind you can store the userPassword
value in hashed form in OpenLDAP.
> - Limiting client IP addresses by system network services or ACLs
> - ... any other mechanisms?
ACLs with IP addresses are not an option if you want to keep network
configuration independent of the directory configuration. If you are
responsible for both that might work.
>>> Possible solution: The server only responds to unencrypted requests on the
>>> local interface. How can I achieve this?
>> Start slapd with appropriate parameters for command-line option -h for LDAP on
>> localhost and LDAPS for remote connections.
> Tried this, but all instances (different ports) had at least TLS
> encryption with the enabled TLS feature.
What about this?
slapd -h "ldap://127.0.0.1 ldaps://0.0.0.0"
Ciao, Michael.
14 years
Re: forcing encryption for external server access while allowing unencrypted localhost connections
by Robert Henjes
Sorry for reopening / reasking the following issue.
I tried to scan through all posts, but this answer seemed to be the
closest one to my problem. (We're using OpenLDAP 2.4 on Debian Lenny)
Link:
http://www.openldap.org/lists/openldap-software/200409/msg00535.html
> If you're willing to concede that 127.0.0.0/8 will never appear outside of
> your loopback interface, you can synthesize this by checking peer IPs.
>
> # 127.0.0.1 is allowed, regardless of ssf. world at large needs ssf check
> access to dn.<dnstyle1>=<what1>
> by peername.ip=127.0.0.1 <access1>
> by * none break
> # We're not coming via loopback; ssf must be checked.
> access to dn.<dnstyle1>=<what1>
> by ssf=128 <access2>
> by * none
Situation:
For deployment we want to use TLS client certificates, as far as possible, using TLS encryption all the way long.
Problem:
Apache Directory Studio, as well as JXplorer do not support (TLS) client certificate verification, what is agreed not to be a topic of openldap. But anyway...
My proposed solution:
* All clients, which support client certificate verification, should directly connect using TLS to the LDAP server.
* All clients, esp. the management tools, should establish a ssh-tunnel to the server and connect through localhost entity.
* (optional) specific clients should be able to connect via specific access rules (but this is a future topic ;) )
Implementation:
This is not clear to me, how the previous posts are related to my problem, and how to configure the OpenLDAP server.
I tried several scenarios with varying results, but no one was perfect yet.
Here a snippet of my current slapd.conf:
---------------
# the "ssl tls=1" is not necessary due to the special
# access rule in the remainder of this configuration
TLSCACertificateFile /etc/ssl/CA/cacert.pem
TLSCertificateKeyFile /etc/ssl/private/privkey.pem
TLSCertificateFile /etc/ssl/certs/pubkey.pem
TLSVerifyClient demand # for highest security
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attrs=userPassword,shadowLastChange
by peername.ip=127.0.0.1 write
by ssf=128 dn="cn=admin,dc=example,dc=com" write
by ssf=128 anonymous auth
by ssf=128 self write
by * none
# Security considerations (TESTING!!!!)
# http://www.openldap.org/lists/openldap-software/200409/msg00535.html
# access from 127.0.0.1 without encryption
access to dn.subtree="dc=example,dc=com"
by peername.ip=127.0.0.1 write
by * none break
# worldwide access requires tls encryption
access to dn.subtree="dc=example,dc=com"
by ssf=128 write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=example,dc=com" write
by * read
---------------
Questions:
1) Turing off the option "ssl tls=1" means, a client can contact the server without encryption. If a password is transmitted, it will be rejected, but it is still transmitted unsecure.
Due you have any recommendations according this issue?
Possible solution: The server only responds to unencrypted requests on the local interface. How can I achieve this?
2) With the above presented solution, I can not change my own password as the desired user (Invalid credentials (49)), only as admin(root). Why?
3) What would be the appropriate way to achieve my goal?
* Locking the dc=example,dc=com base from all unencrypted access from "worldwide" hosts. (admin should still have full access, but encryption has to be enforced)
* Allowing access to the complete ldap tree without encryption from localhost
Thank you very much, any help or further link is appreciated. I spent almost one week now reading and completing the stuff, but sometimes it works, but a "whole" is left, otherwise only parts of the ldap server are accessible as desired.
Best regards,
Robert
--
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany
henjes(a)informatik.uni-wuerzburg.de
Tel: +49 931 31-86652
Fax: +49 931 888-6632
14 years
Using different encryption on localhost and networked connections
by Robert Henjes
Sorry for reopening / reasking the following issue.
I tried to scan through all posts, but this answer seemed to be the
closest one to my problem. (We're using OpenLDAP 2.4 on Debian Lenny)
Link:
http://www.openldap.org/lists/openldap-software/200409/msg00535.html
> If you're willing to concede that 127.0.0.0/8 will never appear outside of
> your loopback interface, you can synthesize this by checking peer IPs.
>
> # 127.0.0.1 is allowed, regardless of ssf. world at large needs ssf check
> access to dn.<dnstyle1>=<what1>
> by peername.ip=127.0.0.1 <access1>
> by * none break
> # We're not coming via loopback; ssf must be checked.
> access to dn.<dnstyle1>=<what1>
> by ssf=128 <access2>
> by * none
Situation:
For deployment we want to use TLS client certificates, as far as possible, using TLS encryption all the way long.
Problem:
Various LDAP client software and services do not support (TLS) client certificate verification.
My proposed solution:
* All clients, which support client certificate verification, should directly connect using TLS to the LDAP server.
* All clients, esp. the management tools, should establish a ssh-tunnel to the server and connect through localhost entity.
* (optional) specific clients should be able to connect via specific access rules (but this is a future topic ;) )
Implementation:
This is not clear to me, how the previous posts are related to my problem, and how to configure the OpenLDAP server.
I tried several scenarios with varying results, but no one was perfect yet.
Here a snippet of my current slapd.conf:
---------------
# the "ssl tls=1" is not necessary due to the special
# access rule in the remainder of this configuration
TLSCACertificateFile /etc/ssl/CA/cacert.pem
TLSCertificateKeyFile /etc/ssl/private/privkey.pem
TLSCertificateFile /etc/ssl/certs/pubkey.pem
TLSVerifyClient demand # for highest security
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attrs=userPassword,shadowLastChange
by peername.ip=127.0.0.1 write
by ssf=128 dn="cn=admin,dc=example,dc=com" write
by ssf=128 anonymous auth
by ssf=128 self write
by * none
# Security considerations (TESTING!!!!)
# http://www.openldap.org/lists/openldap-software/200409/msg00535.html
# access from 127.0.0.1 without encryption
access to dn.subtree="dc=example,dc=com"
by peername.ip=127.0.0.1 write
by * none break
# worldwide access requires tls encryption
access to dn.subtree="dc=example,dc=com"
by ssf=128 write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=example,dc=com" write
by * read
---------------
Questions:
1) Turing off the option "ssl tls=1" means, a client can contact the server without encryption. If a password is transmitted, it will be rejected, but it is still transmitted unsecure.
Due you have any recommendations according this issue?
Possible solution: The server only responds to unencrypted requests on the local interface. How can I achieve this?
2) With the above presented solution, I can not change my own password as the desired user (Invalid credentials (49)), only as admin(root). Why?
3) What would be the appropriate way to achieve my goal?
* Locking the dc=example,dc=com base from all unencrypted access from "worldwide" hosts. (admin should still have full access, but encryption has to be enforced)
* Allowing access to the complete ldap tree without encryption from localhost
Thank you very much, any help or further link is appreciated. I spent almost one week now reading and completing the stuff, but sometimes it works, but a "whole" is left, otherwise only parts of the ldap server are accessible as desired.
Best regards,
Robert
P.S.: Though "googling" for several days now, I'm interested in any Link to a good website discussing the access rules besides the openldap documentation and presenting various use cases.
--
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany
henjes(a)informatik.uni-wuerzburg.de
Tel: +49 931 31-86652
Fax: +49 931 888-6632
14 years
LDAP Caching
by Marten Lehmann
Hello,
does openldap implement sort of caching? Or does it completely rely on
the underlying database like bdb (default)? I'm noticing an intensive
i/o load while the complete slapcat export of our ldap data is only
about 34MB big so everything besides writing/updating should fit into
the memory.
Regards
Marten
14 years
Truncating replication log
by Marten Lehmann
Hello,
I haven't used replication yet, but slapd is writing files like
log.0000000001, log.0000000002 and so on so I guess these are files for
replication. How can I disable this? Or how can I at least truncate
them? Is there a way to completely rebuild and shrink the ldap db-files
so that after that they are probably better organized and faster to work
with?
Kind regards
Marten
14 years
