openldap-software

openldap-software@openldap.org

2719 discussions

Re: syncrepl 2.4 issue from 2.3 master
by FRLinux 21 Sep '09

21 Sep '09

On Fri, Sep 18, 2009 at 11:31 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > 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. Hello, quick one about this, i read this page: http://www.openldap.org/doc/admin24/slapdconfig.html#syncrepl The part I am wondering about is this: "by default the TLS parameters from a ldap.conf(5) configuration file will be used. TLS settings may be specified here, in which case any ldap.conf(5) settings will be completely ignored" So i do have a valid /etc/ldap.conf which contains references to TLS cert and stuff, why do i need more settings in slapd.conf? Reason I am asking is when i add this, in the syncrepl section, it fails saying unknown directive: [starttls=yes|critical] [tls_cacert=<file>] For info, this is my ldap.conf: BASE dc=example, dc=com URI ldaps://masterldap.example.com:636/ TLS_CACERT /etc/ldap/cert/cacert.pem TLS_REQCERT demand Cheers, Steph

1 0

Re: slapd consumer deletes entries
by Tony Smith 20 Sep '09

20 Sep '09

On 9/20/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Saturday, September 19, 2009 9:29 PM +0100 Tony Smith > <tony.smith.124(a)googlemail.com> wrote: > > > > > ah, sorry, I spoke too soon. The deletions still appear regardless > > those above options. It must be something else... > > > > I would suggest that you slapcat the master and slapadd the replica, so > that the replica is fully in sync with a known correct database. I tried this, the deletions continue but your suggestion led me to try to reload the provider as well; after that the problem seems to be gone. thanks again for your patience and help, Tony

1 0

Re: syncrepl 2.4 issue from 2.3 master
by FRLinux 20 Sep '09

20 Sep '09

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

2 1

Re: slapd consumer deletes entries
by Tony Smith 20 Sep '09

20 Sep '09

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

2 2

Re: slapd consumer deletes entries
by Tony Smith 19 Sep '09

19 Sep '09

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

2 2

2.3.43, and a variety of problems.
by Brandon Hume 18 Sep '09

18 Sep '09

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?

6 8

syncrepl 2.4 issue from 2.3 master
by FRLinux 18 Sep '09

18 Sep '09

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

2 1

Re: Using different encryption on localhost and networked connections
by Michael Ströder 18 Sep '09

18 Sep '09

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.

2 1

Re: forcing encryption for external server access while allowing unencrypted localhost connections
by Robert Henjes 18 Sep '09

18 Sep '09

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

3 2

Using different encryption on localhost and networked connections
by Robert Henjes 18 Sep '09

18 Sep '09

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

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software