Search results for "starttls" - openldap-technical

Trouble with delta-syncrepl MMR: delta-sync lost sync on X, switching to REFRESH

by Patrick Lists

Hi, I'm trying to create a 2-node delta-syncrepl Multi-Master setup with the help of the Admin Guide, man pages and tests/scripts/test063-delta-multimaster. I see the following problem repeat on the "slave" master aka ldap02 which initially syncs with ldap01 aka the "primary" master: Oct 28 04:12:14 ldap02 slapd[9998]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20131028012214.000002Z,cn=accesslog), switching to REFRESH I found ITS#7274 which mentions that some order should be changed (syncprov before olcServerID) but I have no idea how that applies to my setup. Being new to all this magic I came up empty. So here's my config. Hopefully it isn't too messed up :) I would appreciate it if someone could share a clue or 2 how to make this work. Comments on the config not related to the problem are also most welcome. OS: CentOS 6.4 x86_64 - clean install, all OpenLDAP dirs are empty OpenLDAP version: RE24 git rev f9e417a from around 10/23/2013. On the initial/"primary" master (note that the config is the same for the "slave" up to the comment): $ sudo /usr/local/sbin/slapadd -v -F $LDAP_ETC/slapd.d \ -l ./delta-syncrepl-MMR.ldif -n 0 $ cat ./delta-syncrepl-MMR.ldif # global configuration settings dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid olcLogFile: /var/log/openldap-2.4/slapd-2.4.log olcLogLevel: conns stats stats2 sync olcTLSCACertificateFile: /etc/pki/tls/certs/DS-CA.crt olcTLSCertificateFile: /etc/pki/tls/certs/slapd.crt olcTLSCertificateKeyFile: /etc/pki/tls/private/slapd.key.crt olcTLSCipherSuite: TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!RC4:@STRENGTH olcTLSVerifyClient: demand olcLocalSSF: 256 olcSecurity: ssf=256 olcPasswordCryptSaltFormat: $6$%s olcPasswordHash: {CRYPT} olcServerID: 1 ldap://ldap01 olcServerID: 2 ldap://ldap02 # load modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/local/lib64/openldap-2.4 olcModuleload: {0}syncprov.la olcModuleload: {1}accesslog.la olcModuleLoad: {2}back_mdb.la olcModuleLoad: {3}back_monitor.la olcModuleLoad: {4}memberof.la olcModuleLoad: {5}refint.la olcModuleLoad: {6}ppolicy.la # schema definitions dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema # include the schemas include: file:///etc/openldap-2.4/schema/core.ldif include: file:///etc/openldap-2.4/schema/corba.ldif include: file:///etc/openldap-2.4/schema/cosine.ldif include: file:///etc/openldap-2.4/schema/duaconf.ldif include: file:///etc/openldap-2.4/schema/dyngroup.ldif include: file:///etc/openldap-2.4/schema/inetorgperson.ldif include: file:///etc/openldap-2.4/schema/java.ldif include: file:///etc/openldap-2.4/schema/misc.ldif include: file:///etc/openldap-2.4/schema/nis.ldif include: file:///etc/openldap-2.4/schema/openldap.ldif include: file:///etc/openldap-2.4/schema/ppolicy.ldif include: file:///etc/openldap-2.4/schema/collective.ldif # global database parameters dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend # setup cn=config (password = 1234) dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: {CRYPT}$6$... olcSyncrepl: {0}rid=001 provider=ldap://ldap01 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=002 provider=ldap://ldap02 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE olcAccess: to * by dn.exact="cn=Manager,dc=test" write by * none olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # add the syncprov overlay to the cn=config database dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # setup monitoring dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig objectClass: olcMonitorConfig olcDatabase: monitor olcAccess: to dn.subtree=cn=Monitor by dn.exact="cn=config" write by dn.exact="cn=Manager,dc=test" write by * none # setup Accesslog database definitions dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap-2.4/accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="cn=Manager,dc=test" read olcRootDN: cn=Manager,dc=test olcDbIndex: objectClass,entryCSN,reqStart,reqEnd,reqResult,reqDN eq olcDbMode: 0600 # max size in bytes - 1GB = 1073741824 bytes olcDbMaxsize: 1073741824 # add the syncprov overlay to the cn=accesslog database dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # up to here ^^^ is also the config for the "slave" # main mdb database definition dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcSuffix: dc=test olcDbDirectory: /var/lib/ldap-2.4/test olcRootDN: cn=Manager,dc=test olcRootPW: {CRYPT}$6$... olcSyncrepl: {0}rid=003 provider=ldap://ldap01 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager_nopass.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=004 provider=ldap://ldap02 binddn="cn=Manager,test" bindmethod=sasl saslmech=external searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE olcDbIndex: cn pres,eq,sub olcDbIndex: gidNumber pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: memberUid pres,eq olcDbIndex: objectClass pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: uid pres,eq olcDbIndex: uidNumber pres,eq olcDbIndex: entryCSN,entryUUID eq olcDbMode: 0600 # max size in bytes - 1GB = 1073741824 bytes olcDbMaxSize: 5368709120 olcAccess: to attrs=userPassword by dn.exact="cn=Manager,dc=test" write by self write by anonymous auth by * none olcAccess: to * by dn.exact="cn=Manager,dc=test" write by self read by * read olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # add the syncprov overlay to the main mdb database dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckPoint: 20 10 # add the accesslog overlay to the main mdb database dn: olcOverlay={1}accesslog,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 04+00:00 # add memberof overlay to mdb database dn: olcOverlay={2}memberof,olcDatabase={3}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf # add refint overlay to mdb database dn: olcOverlay={3}refint,olcDatabase={3}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: refint olcRefintAttribute: member memberOf olcRefintNothing: cn=Manager,dc=test # add the ppolicy overlay to the main mdb database dn: olcOverlay={4}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=test olcPPolicyHashCleartext: TRUE $ sudo /usr/local/bin/ldapadd -v -f ./test-data.ldif x -D "cn=Manager,dc=test" -w $(cat ./ldap.secret) -d0 -ZZ # Organization dn: dc=test objectClass: dcObject objectClass: organization dc: test o: Test description: Test LDAP Root # add ppolicy ou dn: ou=policies,dc=test ou: policies objectClass: top objectClass: organizationalUnit # add password policy dn: cn=default,ou=policies,dc=test cn: default objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: person objectClass: top pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 600 pwdFailureCountInterval: 30 pwdGraceAuthNLimit: 5 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 0 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 5 pwdMustChange: FALSE pwdSafeModify: FALSE pwdCheckModule: check_password.so sn: dummy value ... Thanks! Regards, Patrick

11 years

Re: AW: Re: AW: Re: AW: StartTLS is not working

by Dat Duong

Hi Hauke, I've followed the mini tutorial and got stuck at the path for the server certificates in your tutorial. The path is not correct for slapd. Can you verify? TLSCertificateFile /usr/lib/ssl/certs/<fqdn>.cert.pem TLSCertificateKeyFile /usr/lib/ssl/private/<fqdn>.key.pem thanks ----- Original Message ---- From: Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de> To: Dat Duong <datduong2000(a)yahoo.com> Cc: openldap-technical <openldap-technical(a)openldap.org> Sent: Thursday, October 9, 2008 12:46:00 AM Subject: AW: Re: AW: Re: AW: StartTLS is not working Hi Dat, > I've added the below to /etc/openldap/ldap.conf on RHEL 5: > TLS_CACERT /etc/openldap/cacerts/ServerCA.chain.pem > TLS_REQCERT demand > > and still getting errors messages... below: > > TLS certificate verification: Error, self signed certificate The LDAP server does not send a server certificate but a self signed certificate. Are you sending the RootCA's certificate? Create a server certificate as described in the tutorial and let your LDAP server use this. I assume that you will have to read a bit more about certificates and openssl to understand all the steps of the mini tutorial. Rergards, Hauke ----- Original Message ---- From: Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de> To: openldap-software <openldap-software(a)openldap.org> Cc: Dat Duong <datduong2000(a)yahoo.com> Sent: Wednesday, October 8, 2008 2:09:11 AM Subject: AW: Re: AW: StartTLS is not working Hi Dat, glad to see that the first problem has been solved now. As Dieter already pointed out, we need to know how the certificates have been created. As a rough overview, you will need to run through following steps: 0. Understand the basic idea: At the end of this MiniHowto, you will have three certification authorities: UserCA: For user certificates (usually password protected) ServerCA: For server certificates (usually NOT password protected) RootCA: The CA that everyone has to trust in the end. This CA only exists to create and verify the UserCA and ServerCA. For your LDAP server, you create a server certificate with your ServerCA. The LDAP clients will accept the LDAP certificate as long as they trust the ServerCA. They will trust the ServerCA because they trust the RootCA. To make them do so, you will need the certificates of the ServerCA AND the RootCA on each client. Just to make sure: We are not talking about copying the LDAP certificate to the client. Instead, you will copy the CA certificates to the client. 1. Create directory structure and files containing random numbers (need to be root for this): # Make sure uuencode is installed. On Debian based # systems, type # # apt-get install sharutils # cd /usr/lib/ssl/ for i in RootCA ServerCA UserCA; do mkdir -p $i/newcerts; mkdir $i/certs; mkdir $i/crl; mkdir $i/private; touch $i/index.txt; echo 01 > $i/serial; chmod -R g-rwx,o-rwx $i; done for i in `find /usr/lib/ssl/ -name private` do cat /dev/urandom | uuencode -m bla | head -19 | sed "s/begin.*//g" | tail -18 | xargs | sed "s/ //g" > $i/.rand chmod 770 $i/.rand ls -l $i/.rand done At the end of this step, you will have three subdirectories in /usr/lib/ssl: RootCA: Contains the root CA's self-signed certificate and private key as well as the certificates created by the root CA. ServerCA: Contains the CA which is used to create server certificates. Again, the directory contains of the server CA's certificate and key as well as the certificates created by the server CA. UserCA: Contains the CA which is used to create user certificates. 2. openssl.cnf Adapt your openssl.cnf (should be in /usr/lib/ssl, too) to have proper entries for each of the CAs: HOME = /usr/lib/ssl [ RootCA ] dir = /usr/lib/ssl/RootCA certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/RootCA.cert.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/private/RootCA.key.pem RANDFILE = $dir/private/.rand policy = policy_match x509_extensions = ca_cert [ ServerCA ] dir = /usr/lib/ssl/ServerCA certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/ServerCA.cert.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/private/ServerCA.key.pem RANDFILE = $dir/private/.rand x509_extensions = usr_cert (Same with [ UserCA ]) There are more options to be set, but they depend on your environment. Have a look at the default_days, default_md, ... parameters. 1. Create a self signed certificate (RootCA): cd /usr/lib/ssl/RootCA # Create the private key first # You will be asked for a new pasword here. Make it a good one and remember it ;-) openssl genrsa -aes256 -out /usr/lib/ssl/RootCA/private/RootCA.key.pem -rand /usr/lib/ssl/RootCA/private/.rand 2048 chmod g-rwx,o-rwx /usr/lib/ssl/RootCA/private/RootCA.key.pem # Now create a certification request. Because the cert is self-signed, this # directly creates the RootCA's certificate. You will be asked for the # password you just created. # # All in one line: openssl req -new -x509 -days 1827 -key /usr/lib/ssl/RootCA/private/RootCA.key.pem -out /usr/lib/ssl/RootCA/RootCA.cert.pem # Copy the certificate to the certs directory and create a link named like # the cert's hash value cp RootCA.cert.pem certs/00.pem cd certs ln -s /usr/lib/ssl/RootCA/certs/00.pem `openssl x509 -hash -noout -in 00.pem`.0 Now you should have the cert (00.pem) and something like 1a2783e8.0 pointing to /usr/lib/ssl/RootCA/00.pem 2. Create the ServerCA cd /usr/lib/ssl/ServerCA # Create the private key for the ServerCA # You will be asked for a new password here. Do not make it the same as the RootCA's # password, but still - make it a good one. # openssl genrsa -aes256 -out /usr/lib/ssl/ServerCA/private/ServerCA.key.pem -rand /usr/lib/ssl/ServerCA/private/.rand 2048 chmod g-rwx,o-rwx /usr/lib/ssl/ServerCA/private/ServerCA.key.pem # Create the certification request. You will be asked for the # newly created password. # (All in one line) openssl req -new -days 1827 -key /usr/lib/ssl/ServerCA/private/ServerCA.key.pem -out /usr/lib/ssl/ServerCA/ServerCA.req.pem # Let the RootCA sign the request and create the certificate. # You will need the RootCA's password for this. # openssl ca -name RootCA -in /usr/lib/ssl/ServerCA/ServerCA.req.pem -out /usr/lib/ssl/ServerCA/ServerCA.cert.pem # Copy and link the certificate. # mv /usr/lib/ssl/RootCA/newcerts/01.pem /usr/lib/ssl/RootCA/certs/ cd /usr/lib/ssl/RootCA/certs/ ln -s 01.pem `openssl x509 -in 01.pem -hash -noout`.0 # And copy the part neccessary for browser integration into # another file (this is the part between BEGIN CERTIFICATE and END CERTIFICATE) # cd /usr/lib/ssl/ServerCA sed -n '/-----BEGIN CERTIFICATE-----/,$p' ServerCA.cert.pem > ServerCA.crt # Create the CACerts file used on the client side to verify a server cert mkdir /usr/lib/ssl/cacerts/ cat /usr/lib/ssl/RootCA/RootCA.cert.pem /usr/lib/ssl/ServerCA/ServerCA.cert.pem > /usr/lib/ssl/cacerts/ServerCA.chain.pem # The newly created file (ServerCA.chain.pem) is the CACertsFile which has to be copied # to every client. Create a /usr/lib/ssl/cacerts/ directory on the client side and copy # the file to that location. 3. Do the same with the User CA 4. Create your LDAP server certificate. As for the name in your cert, use the fqdn of the machine you are running the server on. cd /usr/lib/ssl/ServerCA # You will NOT need a password here # openssl genrsa -out <fqdn-of-your-server>.key.pem -rand ./private/.rand 2048 openssl req -new -key <fqdn-of-your-server>.key.pem -out <fqdn-of-your-server>.req.pem # But here, you will be asked for the ServerCA's password openssl ca -name ServerCA -in <fqdn-of-your-server>.req.pem -out <fqdn-of-your-server>.cert.pem Move and link the new certificate (in newcerts) as above. 5. Configure LDAP server and clients Make sure that your ldap server can read its own private key. If your ldap server is running as user openldap, make sure that this user owns the private key in /usr/lib/ssl/ServerCA/private/ Normal users should never be allowed to read the key! This would break the whole security mechanism. In your slapd.conf, you will have TLSCertificateFile /usr/lib/ssl/certs/<fqdn>.cert.pem TLSCertificateKeyFile /usr/lib/ssl/private/<fqdn>.key.pem And on client side ldap.conf: TLS_CACERT /usr/lib/ssl/cacerts/ServerCA.chain.pem TLS_REQCERT demand Hope this helps, Hauke p.s.: The description is strongly influenced by Frank Steidl's tutorial as it can be found at http://fra.nksteidl.de/Erinnerungen/OpenSSL.php ----- Ursprüngliche Mail ----- Von: "Dieter Kluenter" < dieter(a)dkluenter.de > An: openldap-technical(a)openldap.org Gesendet: Dienstag, 7. Oktober 2008 22:34:14 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: AW: StartTLS is not working Dat Duong < datduong2000(a)yahoo.com > writes: > Hi Hauke, > > I still can't get TLS to work. Here is the error message. > > TLS certificate verification: Error, self signed certificate > tls_write: want=7, written=7 > 0000: 15 03 01 00 02 02 30 ......0 > TLS trace: SSL3 alert write:fatal:unknown CA > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Please describe the parameters to create your certificate chain. I presume you have not signed your certificates with a known certificate authority. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E -- ------------------------------------ Fernuniversität in Hagen Lehrgebiet Kommunikationsnetze http://www.fernuni-hagen.de/kn Fon/Fax: +49 2331 987 -1142 / -353 ------------------------------------ -- ------------------------------------ Fernuniversität in Hagen Lehrgebiet Kommunikationsnetze http://www.fernuni-hagen.de/kn Fon/Fax: +49 2331 987 -1142 / -353 ------------------------------------

16 years, 1 month

OpenLDAP 2.4.23 multi-master replication of the cn=config tree error: could not put entry file in place

by Cyril Grosjean

I've a sandbox environment with 2 CentOS 6.2 servers running the genuine openldap-servers rpms, that is OpenLDAP 2.4.23 . I've setup a multi-master replication between the servers, so that both my data DIT (dc=....,dc=.... ) and the cn=config should be replicated. Actually, the replication of data works fine, as expected in either way, but the replication of the configuration tree fails: each time I update the configuration on the second node, I get this error in my LDAP client (Apache Directory Studio): could not put entry file in place I've tried to run the second master in debug (-d -1) mode, and it seems like there's a write access error when the slapd daemon (on the 2nd master) tries to update/modify/replace the /etc/openldap/slapd.d/cn=config.ldif file: <= acl_access_allowed: granted to database root ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" null_callback : error code 0x50 slap_graduate_commit_csn: removing 0x7fd19412f090 20120510163105.003156Z#000000#001#000000 syncrepl_updateCookie: rid=001 be_modify failed (80) ldap_msgfree The OpenLDAP error log shows the following error: May 10 19:12:39 sashimi slapd[24866]: slapd starting May 10 19:12:40 sashimi slapd[24866]: ldif_write_entry: cannot create file for "olcDatabase={0}config,cn=config": Permission denied May 10 19:12:40 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:40 sashimi slapd[24866]: syncrepl_entry: rid=001 be_modify failed (80) May 10 19:12:40 sashimi slapd[24866]: do_syncrepl: rid=001 rc -1 quitting May 10 19:12:50 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:12:50 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:50 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:00 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:00 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:00 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:10 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:10 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:10 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) Of course, I don't have any right access problems at the file system level, I don't have any file system ACLs, I don't use SELinux and I've checked that I can update or create any file under /etc/openldap/slapd.d, when logged in as the ldap user (who's the account used to run slapd). So, this error looks like a bug to me. Already fixed ? To setup the replication of both data and configuration, I've copied the full /etc/openldap directory from one server to the other, with the same file system rights. I've just changed the server certificate files since I use TLS to replicate both the data and the configuration. So, I don't have any TLS problem since the data tree replication works fine. Here's my replication configuration for the cn=config database: dn: olcDatabase={0}config,cn=config ... .... olcSyncRepl: rid=001 provider=ldap://......:389 binddn="cn=config" bindmethod=simple credentials="......" searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcSyncRepl: rid=002 provider=ldap://.....:389 binddn="cn=config" bindmethod=simple credentials="....... " searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcMirrorMode: TRUE I actually use the same setup than for the data replication, excepted that I have rid=003 and rid=004 of course for data replication, and the BIND DN and passwords are different too. -- Cyril

12 years, 6 months

Re: data import very slow for data migration

by anil beniwal

Hi I didn't get it. Can you please elaborate it a bit. It would be great help for me. On Wed, Dec 26, 2012 at 2:37 AM, Dieter Klünter <dieter(a)dkluenter.de> wrote: > Am Tue, 25 Dec 2012 21:27:39 +0530 > schrieb anil beniwal <beni.anil(a)gmail.com>: > > > Hi > > > > We are having 4 million users to migrate, all data exported from > > oracle to multiple ldif files. > > Imported 1 million till now, took almost 28 hours. and openldap-data > > dir of about 28G. > > openldap version 2.4.33 bdb version 5.1.29 RHEL 6.3 RAM 8G 4 cpu , > > system is a VM. > > > > Currently running slapadd output > > + /apps/openldap/sbin/slapadd -q -c -w -f > > /apps/openldap/etc/openldap/slapd.conf -l /root/User9.ldif > > bdb_monitor_db_open: monitoring disabled; configure monitor database > > to enable > > . 2.27% eta 21h31m elapsed 29m57s > > spd 1.6 k/s str2entry: invalid value for attributeType > > postalAddress #0 (syntax 1.3.6.1.4.1.1466.115.121.1.41) > > slapadd: could not parse entry (line=394416) > > * 2.81% eta 19h59m elapsed 34m40s spd > > 10.1 k/s > > 1. There are too many errors like above. > > > Its seems to be taking weeks go import whole data. > > It takes about 2 - 4 hours in order to slapadd 4 mio.entires, depending > on file system and disk type. > > > > is there any tool or any other approach which we can use to make it > > fast,Or we are going with wrong configuration. > > Or we have to switch to ODS or RHDS > > There is no necessity for other tools, just modify the ldif file. > > [...] > > DB_CONFIG > > > > set_cachesize 0 4294967295 0 > > increase cachesize to at least 4GB that is > set_cachesize 4 0 1 > > [...] > > checkpoint 128 15 > > I would set checkpointing to 0 15 > [...] > > > concurrency 100 > > index entryCSN eq > > index entryUUID eq > > index > > > mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type > > eq > > index givenName,sn,city,question,behavValue,cn,extName sub > > index displayName approx > > # Replication Configuration > > overlay syncprov > > syncprov-checkpoint 100 10 > > syncprov-sessionlog 100 > > > > serverid 1 > > > > syncrepl rid=111 > > provider=ldap://s01.com > > binddn="cn=Manager,dc=example,dc=com" > > bindmethod=simple > > starttls=yes > > tls_reqcert=allow > > schemachecking=off > > credentials=G00gle# > > searchbase="dc=example,dc=com" > > type=refreshAndPersist > > retry="5 5 300 +" > > interval=00:00:00:10 > > > > syncrepl rid=222 > > provider=ldap://m04.com > > binddn="cn=Manager,dc=example,dc=com" > > bindmethod=simple > > starttls=yes > > tls_reqcert=allow > > schemachecking=off > > credentials=G00gle# > > searchbase="dc=example,dc=com" > > type=refreshAndPersist > > retry="5 5 300 +" > > interval=00:00:00:10 > > > > ###### > > > > mirrormode TRUE > > > > directory /apps/openldap/var/openldap-data > > > > overlay unique > > unique_attributes mail > > > > overlay ppolicy > > ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" > > ppolicy_use_lockout > > Please not that overlay declarations follow all database declarations, > modify slapd.conf accordingly. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://dkluenter.de > GPG Key ID:DA147B05 > 53°37'09,95"N > 10°08'02,42"E > > -- Thanks&Regards Anil Beniwal +919891695048

11 years, 10 months

Syncrepl: consumer ignores bindmethod=sasl

by Tim Dijkstra

Hi All, I'm trying to get syncrepl to work with TLS, and SASL External. I think I configured everything correctly; I explicitly state it should use bindmethod=sasl, but in the logs I see it is using simple nonetheless. Replication subsequently fails because lack of access rights. Using ldapsearch with identical setting in .ldaprc works... I'm at a loss. Anybody knows what is going on? Excerpt from slapd.conf of consumer: syncrepl rid=13 provider=ldaps://example.org:636 type=refreshAndPersist interval=00:00:30:00 searchbase="ou=People,dc=example,dc=org" scope=sub bindmethod=sasl saslmech=EXTERNAL schemachecking=off authcid=cn=kelderlied,ou=hosts,o=example authzid=cn=kelderlied,ou=hosts,o=example tls_cacert=/etc/ldap/trusted/ca.drs.p-cacert_root_3.pem tls_cert /etc/ssl/CA/kelderlied.crt tls_key /etc/ssl/CA/kelderlied.key tls_reqcert=demand starttls=critical When Syncrepl from the consumer is started in the logs of the provider I see: > ACCEPT from IP=A.B.C.D:55428 (IP=0.0.0.0:636) > TLS established tls_ssf=128 ssf=128 > BIND dn="" method=128 > conn=1099 op=0 RESULT tag=97 err=0 text= > SRCH BASE..... So, TLS is successful (I have TLS_REQ = demand on the provider), but bind simple is requested Here I do a search by hand with identical settings in my .ldaprc that succeeds > ldapsearch -H ldaps://example.org:636 -Y EXTERNAL -b "ou=people,dc=example,dc=org" "(objectClass=*)" > In the logs: > ACCEPT from IP=A.B.C.D:55434 (IP=0.0.0.0:636) > TLS established tls_ssf=128 ssf=128 > BIND dn="" method=163 > BIND authcid="cn=kelderlied,ou=hosts,o=example" authzid="cn=kelderlied,ou=hosts,o=example" > BIND dn="cn=libnss,dc=example,dc=org" mech=EXTERNAL sasl_ssf=0 ssf=128 > RESULT tag=97 err=0 text= > Any help is appreciated... Tim

12 years, 10 months

回复： mirror mode question

by Eileen(=^ω^=)

Hi Michael and Dieter, Thanks for your kindly replies. In my case, I didn't use any SASL or TLS but "simple" method with operation mode of user/password authenticated. However, I need the rootpw hashed (not cleartext) and the 2 servers (master & slave) synchronized. Could you pls advise how i should modify the syncrepl part? or could you pls provide a sample of the slapd.conf file configuration? Best regards, Eileen ------------------ 原始邮件 ------------------ 发件人: "Michael Ströder";<michael(a)stroeder.com>; 发送时间: 2014年3月5日(星期三) 下午4:09 收件人: "Dieter Klünter"<dieter(a)dkluenter.de>; "openldap-technical"<openldap-technical(a)openldap.org>; 主题: Re: mirror mode & sasl question Dieter Klünter wrote: > Am Wed, 5 Mar 2014 14:38:04 +0800 > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>: >> This is Eileen from China SINAP. I am a beginner for openldap soft. I >> encountered a problem in my study on two LDAP services replication. >> I have 2 LDAP services, one name LDPA1, the other is LDAP2 . I want >> to make them synchronously in mirror mode. But when I set LDAP >> services rootpw both in hash, the 2 LDAP serivces can’t be >> synchronous. My question is >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If I >> must use sasl method, can I put the sasl service in the same ldap >> service? If bindmethod=sasl then what is the saslmech should be? >> 2. If I change to sasl method, do I need change my database >> record? > > In order to use sasl, passwords must be cleartext and you should > configure an apropriate authz-regexp, see man slapd.conf(5) > You may use any sasl mechanism that you sasl framework provides. > [...] To be more precise: In order to use password-based SASL mechs the passwords have to be stored in clear-text. Well, if working with SASL and TLS (LDAPS, StartTLS) one should consider using client certs and SASL/EXTERNAL for replication. Ciao, Michael.

10 years, 8 months

答复: 回复： mirror mode question

by 田格瑄

Hi Michael and Dieter, I see the below mail, can I understand only the mirror mode replication can’t use the HASH password in rootpw, other Synchronous replication mode(example: syncrepl proxy) can use the HASH password? Thanks and regards tiangexuan ------------------ 原始邮件 ------------------ 发件人: "Michael Ströder";<michael(a)stroeder.com <mailto:michael@stroeder.com> >; 发送时间: 2014年3月5日(星期三) 下午4:09 收件人: "Dieter Klünter"<dieter(a)dkluenter.de <mailto:dieter@dkluenter.de> >; "openldap-technical"<openldap-technical(a)openldap.org <mailto:openldap-technical@openldap.org> >; 主题: Re: mirror mode & sasl question Dieter Klünter wrote: > Am Wed, 5 Mar 2014 14:38:04 +0800 > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com <mailto:123784635@qq.com> >: >> This is Eileen from China SINAP. I am a beginner for openldap soft. I >> encountered a problem in my study on two LDAP services replication. >> I have 2 LDAP services, one name LDPA1, the other is LDAP2 . I want >> to make them synchronously in mirror mode. But when I set LDAP >> services rootpw both in hash, the 2 LDAP serivces can’t be >> synchronous. My question is >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If I >> must use sasl method, can I put the sasl service in the same ldap >> service? If bindmethod=sasl then what is the saslmech should be? >> 2. If I change to sasl method, do I need change my database >> record? > > In order to use sasl, passwords must be cleartext and you should > configure an apropriate authz-regexp, see man slapd.conf(5) > You may use any sasl mechanism that you sasl framework provides. > [...] To be more precise: In order to use password-based SASL mechs the passwords have to be stored in clear-text. Well, if working with SASL and TLS (LDAPS, StartTLS) one should consider using client certs and SASL/EXTERNAL for replication. Ciao, Michael.

10 years, 7 months

Re: Error 53 applying syncrepl LDIF

by Quanah Gibson-Mount

--On Friday, January 29, 2010 1:56 PM -0700 Hung Luu <hung.n.luu(a)gmail.com> wrote: > Hello all, > > In a syncrepl setup, I understand that the syncrepl specification is > defined on the consumer server. I understand this to mean that I should > apply my LDIF (that adds the olcSyncrepl attribute to my config and hdb > backends) on the consumer server. However, ldapadd was only successful in > configuring my config backend for syncrepl, which is defined first in the > LDIF, and failed with LDAP error 53 when attempting to add the > olcSyncrepl attribute to my hdb backend; additional error info: "shadow > context; no update referral." > > Is this because the olcSyncrepl attribute added to my config backend > already established my consumer server as a replica and hence subsequent > writes to the consumer server will not be accepted? > > Ideally, I wanted to add the syncrepl configuration in my slapd.conf and > then convert it to cn=config; however, this doesn't appear to work with > 2.4.21 because the slaptest added a uri="" to the olcSyncrepl attribute > that running slapd complained of an invalid URL for olcSyncrepl. This is > not an issue in 2.4.20. > > Anyway, what's the right way for me to configure syncrepl on my 2.4.21 > consumer server for both the config and hdb backends? It works for me with 2.4.21: dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=100 provider=${ldap_master_url} bindmethod=si mple timeout=0 network-timeout=0 binddn=uid=zmreplica,cn=admins,cn=zimbra c redentials=${ldap_replication_password} starttls=critical filter="(objectclass=*)" searchbase="" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=access log scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdat a=accesslog tls_cacertdir=/opt/zimbra/conf/ca is the LDIF I use to ldapmodify my entry. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

14 years, 9 months

nss_initgroups_ignoreusers

by Lynn York

Hello, I seem to be having an issue with nss_initgroups_ignoreusers. I have the following line in my /etc/ldap.conf file but it still seems to search ldap for the users. Can anyone shed some light on this issue for me? Also, I am running nss_ldap version >= 2.53. I have supplied a snippet of the sldap log. [ /etc/ldap.conf ] nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,postm aster,anonymous,apache [end ] [ log snippet ] Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=140 fd=48 ACCEPT from IP=127.0.0.1:59736 (IP=0.0.0.0:389) Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=69 op=27 SRCH base="ou=Internal,dc=mgmt,dc=test,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=postmaster))" Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=69 op=27 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=139 op=0 STARTTLS Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=139 op=0 RESULT oid= err=0 text= Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=69 op=27 SEARCH RESULT tag=101 err=0 nentries=0 text= Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=69 op=28 SRCH base="ou=Internal,dc=mgmt, dc=test,dc=com " scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=postmaster))" Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=69 op=28 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Oct 24 12:15:33 ldap-proxy slapd[10000]: conn=139 fd=62 TLS established tls_ssf=256 ssf=256 [ end snippet ] Thanks

16 years

Re: How to make ldap evaluate clear text password vs DES stored password

by Dan White

>in message "Re: How to make ldap evaluate clear text password vs DES stored password", >Dan White <dwhite(a)cafedemocracy.org> wrote: >> On 09/20/18?08:43?+0900, yokoyamy(a)jacic.or.jp wrote: >> >LDAP’s userPassowrd stored in the RDB has been already DES hashed by >> >original app. On the other hand, input password from ldapseach command >> >line is CREARTEXT. >> >> If the hashed/encrypted password is supported by your local crypt(3) >> library, you can prepend the userPassword value with {CRYPT} as specified >> in slapd-config(5) and section 14.4.2 of the Admin Guide. >> >> Else, if you have a pam module which supports authentication of your hash, >> take a look at Pass-Through authentication (section 14.5). On 09/20/18 23:27 +0900, yokoyamy(a)jacic.or.jp wrote: >My CentOS can make cleartext into DES . > >hete is a part of my previous slapd.conf > > olcPasswordHash: {CRYPT} >olcSizeLimit: 5000 >olcPasswordCryptSaltFormat: "_%s" > >unfortunately,it didn't work for my issue. > >i think my slapd uses DES when i try to store new userPasword. slapd will not really be concerned about the format of your hash, as long as your underlyding crypt(3) supports it. slapd will pass the cleartext password received from the client to crypt. You will need to consult your cyrpt(3) manpage for what is supported, and for what format it expects to receive ($id$rounds=yyy$salt$encrypts). >i think unless i fetch userPasdword from RDB through slapd, >i will not be able to find SALT in userPassword. If your RDB has a pam authentication module, then that may be a more appropriate route. In that case you would not need to make any of your RDB password hashes directly available to slapd. slapd would pass the cleartext password, from the client, down to the pam module by way of pass-through authentication and saslauthd. Also, you should be taking appropriate security measures to protect the cleartext password over the wire (ldaps/STARTTLS).

6 years, 1 month

openldap-technical search results for query "starttls"