389-users April 2014

389-users@lists.fedoraproject.org

39 participants
45 discussions

glue entry problem
by Elizabeth Jones 23 Apr '14

23 Apr '14

I have all kinds of borkage in my ldap today. I created a new ou in one of my data centers, ou=cdc,ou=service accts,ou=staff,ou=people,dc=mycompany,dc=com under this I added 2 users. About 5 minutes later I got an alarm from my monitoring system saying that replication had failed, and I discovered that replication from this data center to my second data center had failed, and more specifically this ou -- [22/Apr/2014:15:28:03 -0500] - Retry count exceeded in add [22/Apr/2014:15:28:03 -0500] NSMMReplicationPlugin - conn=437731 op=4 csn=5356cc22000000010000: Can't created glue entry ou=CDC,ou=Service Accts,ou=People,dc=mycompany,dc=com uniqueid=dde5bb01-ca5811e3-af3cad6b-9c050417, error 51 So I thought there was something wrong in the new ou I'd created so I went back and deleted the two children, then tried to delete the ou. But my ldap thinks that the children still exist and won't let me delete the ou -- [22/Apr/2014:15:45:17 -0500] entryrdn-index - _entryrdn_delete_key: Failed to remove ou=cdc; has children [22/Apr/2014:15:45:17 -0500] - database index operation failed BAD 1031, err=-1 Unknown error: -1 Any thoughts on how to proceed with this? I'm afraid to do anything else on the first server now that I've managed to get it into this state. thanks - EJ

3 7

Re: [389-users] glue entry problem
by David Hall 23 Apr '14

23 Apr '14

Hi, Please remove me from this list. Thank you, David On 23 Apr 2014, at 15:14, Elizabeth Jones <bajones(a)panix.com> wrote: > >> >> You mentioned 2 servers ldap1 and ldap2. Are they both masters? You put >> "local consumer" to ldap2. Does that mean ldap2 is a read only replica? > > We have two data centers and each data center has an ldap1 and ldap2. All > 4 are masters, but we only ever send updates to DCA-ldap1. That then > pushes to DCA-ldap2 and to DCB-ldap1. DCB-ldap1 pushes to DCB-ldap2, so > the ldap2's are really functioning as consumers all the time. > >> >> It looks to me ldap1 got broken and ldap2 is still healthy. You may >> want to make ldap1 in sync with ldap2 and start from there. If ldap2 is >> a master, you could re-initialize ldap1 from ldap2. >> >> If ldap2 is a read only replica, you could export the contents with >> db2ldif -r -n <your_backend> command line utility on ldap2 and import >> the exported ldif file to ldap1. >> >> Or if you don't mind losing the replication information such as >> tombstones and state info, you could export the contents without "-r" by >> db2ldif on ldap2 and import the ldif file to ldap1, then re-initialize >> ldap2 on ldap1. >> >> Hope you could choose one of the 3 ways and it fixes the problem. > > I will give this a shot. When we tried to initialize these last week the > initialization emptied out the receiving ldap and I believe that was a bug > that is fixed in 1.3. I recovered by using a backup but I don't want to > try initializing again until we can upgrade to 1.3. Can I still do the > ldif on ldap2, since it is actually a master rather than a read only > replica? > > Thanks, > EJ > > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users

2 1

Sync from RDBMS to LDAP
by Fong, Trevor 22 Apr '14

22 Apr '14

Hi Everyone, We are in the process of migrating from an old OpenLDAP service to 389-DS. We currently synchronise users and attributes from an Oracle DB to OpenLDAP service using an aging set of custom scripts and DB triggers. We would like to do something similar for 389-DS but using a commercial-off-the-shelf solution. I was wondering what the good people on this list use or would recommend? Thanks in advance, Trev --------------------------------------------------------- Trevor Fong - Senior Programmer Analyst Identity and Access Management Group University of British Columbia - Information Technology 6356 Agricultural Road, Vancouver, BC, V6T 1Z2, Canada Ph: (604) 827-5247

1 0

Re: [389-users] SSL
by Andy Spooner 18 Apr '14

18 Apr '14

Problem solved. Copied a CA certificate to /etc/pki/CA/certs and updated /etc/openldap/ldap.conf the location of the CA by adding line TLS_CACERT /etc/openldap/certs/<ca cert> From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 01:43 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL Further information using ldapsearch that substantiates the log file. [root@xxx ~]# ldapsearch -x -ZZ serverxxx.com ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 01:40 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL I have done a system check and the SSL certificate has a problem. Error log: [18/Apr/2014:01:33:53 +0100] conn=40 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [18/Apr/2014:01:33:53 +0100] conn=40 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [18/Apr/2014:01:33:53 +0100] conn=40 op=-1 fd=70 closed - Peer does not recognize and trust the CA that issued your certificate. From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 00:40 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL Hi Justin, Thanks for the prompt advice. Replication is now working between Master and a single consumer. Thanks for your help. I will continue to do a full test. Best regards From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Justin Edmands Sent: 17 April 2014 20:55 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] SSL I am having an issue with securing Directory Server communication using SSL which I need guidance on how to solve. I am setting up a master and slave which will use SSL to secure communication between the two servers and to all other clients. I used openssl to create a CA cert and sign the Manager server certificate as follows: - CA cert created by openssl req -config openssl.cnf -new -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 3650 - Manager server csr signed - openssl ca -config openssl.cnf -policy policy_anything -out certs/xxx.crt -infiles xxx.csr - Checked both certs using before installing on Manager - Both certs were installed using root. - Enabled encryption via the console and restarted dirsrv. Note coms remain of port 389 after the reboot. E.g. xxx.com:389 - o certutil -L -d . output show that both a CA cert and server cert are installed as follows: server-cert u,u,u xxxx-ca.crt CT,, - I checked that the server is listening on port 636. Logs also confirmed that the Manager is listening on port 636 - I tested that the Manager can receive connection on port 636, by connecting using telnet from another server – telnet <server name> 636. The connect was also visible on netstat output. - I can’t see any errors in /var/log/dirsrv/slpad-<server>/errors Can you help so that I can setup secure communication correctly? Kind regards Andy 1 - Do you have a replication agreement setup? 1a - In your replication agreement did you specify the Replication Manager account with correct password? (mine is cn=Replication Manager,cn=config)? 2 - Did you make sure you specify the "Supplier" as coming from port 389 and the "Consumer" using port 636? 2a - Did you select the following for the Connection: "Use TLS/SSL (TLS/SSL Encryption with LDAPS)" "Simple (Bind DN/Password)" Bind as: cn=Replication Manager(or whatever you have),cn=config Password: (password) Note: To check for Replication Manager account, browse to Directory Tab. Click config. Replication Manager will appear. Edit password here. This needs to exist on both directory servers. 3. Did you assign them different unique IDs when creating the client certificates? Note the "m" option. certutil -S -n "Server-Cert-dirsrv2-hq" -s "cn=dirsrv2.example.com,cn=Directory Server" -c "CA certificate" -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt

1 0

Allow Directory Manager to bypass Password Policy
by John Trump 18 Apr '14

18 Apr '14

Is it possible to allow the Directory Manager to bypass the password policy when resetting user passwords? I want to be able to set a users password to a default password. Currently if this password is in the users password history I can not reuse the password.

2 2

Re: [389-users] SSL
by Andy Spooner 17 Apr '14

17 Apr '14

Further information using ldapsearch that substantiates the log file. [root@xxx ~]# ldapsearch -x -ZZ serverxxx.com ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 01:40 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL I have done a system check and the SSL certificate has a problem. Error log: [18/Apr/2014:01:33:53 +0100] conn=40 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [18/Apr/2014:01:33:53 +0100] conn=40 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [18/Apr/2014:01:33:53 +0100] conn=40 op=-1 fd=70 closed - Peer does not recognize and trust the CA that issued your certificate. From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 00:40 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL Hi Justin, Thanks for the prompt advice. Replication is now working between Master and a single consumer. Thanks for your help. I will continue to do a full test. Best regards From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Justin Edmands Sent: 17 April 2014 20:55 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] SSL I am having an issue with securing Directory Server communication using SSL which I need guidance on how to solve. I am setting up a master and slave which will use SSL to secure communication between the two servers and to all other clients. I used openssl to create a CA cert and sign the Manager server certificate as follows: - CA cert created by openssl req -config openssl.cnf -new -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 3650 - Manager server csr signed - openssl ca -config openssl.cnf -policy policy_anything -out certs/xxx.crt -infiles xxx.csr - Checked both certs using before installing on Manager - Both certs were installed using root. - Enabled encryption via the console and restarted dirsrv. Note coms remain of port 389 after the reboot. E.g. xxx.com:389 - o certutil -L -d . output show that both a CA cert and server cert are installed as follows: server-cert u,u,u xxxx-ca.crt CT,, - I checked that the server is listening on port 636. Logs also confirmed that the Manager is listening on port 636 - I tested that the Manager can receive connection on port 636, by connecting using telnet from another server – telnet <server name> 636. The connect was also visible on netstat output. - I can’t see any errors in /var/log/dirsrv/slpad-<server>/errors Can you help so that I can setup secure communication correctly? Kind regards Andy 1 - Do you have a replication agreement setup? 1a - In your replication agreement did you specify the Replication Manager account with correct password? (mine is cn=Replication Manager,cn=config)? 2 - Did you make sure you specify the "Supplier" as coming from port 389 and the "Consumer" using port 636? 2a - Did you select the following for the Connection: "Use TLS/SSL (TLS/SSL Encryption with LDAPS)" "Simple (Bind DN/Password)" Bind as: cn=Replication Manager(or whatever you have),cn=config Password: (password) Note: To check for Replication Manager account, browse to Directory Tab. Click config. Replication Manager will appear. Edit password here. This needs to exist on both directory servers. 3. Did you assign them different unique IDs when creating the client certificates? Note the "m" option. certutil -S -n "Server-Cert-dirsrv2-hq" -s "cn=dirsrv2.example.com,cn=Directory Server" -c "CA certificate" -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt

1 0

Re: [389-users] SSL
by Andy Spooner 17 Apr '14

17 Apr '14

I have done a system check and the SSL certificate has a problem. Error log: [18/Apr/2014:01:33:53 +0100] conn=40 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [18/Apr/2014:01:33:53 +0100] conn=40 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [18/Apr/2014:01:33:53 +0100] conn=40 op=-1 fd=70 closed - Peer does not recognize and trust the CA that issued your certificate. From: Andy [mailto:racingyacht1@gmail.com] Sent: 18 April 2014 00:40 To: 'General discussion list for the 389 Directory server project.' Subject: RE: [389-users] SSL Hi Justin, Thanks for the prompt advice. Replication is now working between Master and a single consumer. Thanks for your help. I will continue to do a full test. Best regards From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Justin Edmands Sent: 17 April 2014 20:55 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] SSL I am having an issue with securing Directory Server communication using SSL which I need guidance on how to solve. I am setting up a master and slave which will use SSL to secure communication between the two servers and to all other clients. I used openssl to create a CA cert and sign the Manager server certificate as follows: - CA cert created by openssl req -config openssl.cnf -new -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 3650 - Manager server csr signed - openssl ca -config openssl.cnf -policy policy_anything -out certs/xxx.crt -infiles xxx.csr - Checked both certs using before installing on Manager - Both certs were installed using root. - Enabled encryption via the console and restarted dirsrv. Note coms remain of port 389 after the reboot. E.g. xxx.com:389 - o certutil -L -d . output show that both a CA cert and server cert are installed as follows: server-cert u,u,u xxxx-ca.crt CT,, - I checked that the server is listening on port 636. Logs also confirmed that the Manager is listening on port 636 - I tested that the Manager can receive connection on port 636, by connecting using telnet from another server – telnet <server name> 636. The connect was also visible on netstat output. - I can’t see any errors in /var/log/dirsrv/slpad-<server>/errors Can you help so that I can setup secure communication correctly? Kind regards Andy 1 - Do you have a replication agreement setup? 1a - In your replication agreement did you specify the Replication Manager account with correct password? (mine is cn=Replication Manager,cn=config)? 2 - Did you make sure you specify the "Supplier" as coming from port 389 and the "Consumer" using port 636? 2a - Did you select the following for the Connection: "Use TLS/SSL (TLS/SSL Encryption with LDAPS)" "Simple (Bind DN/Password)" Bind as: cn=Replication Manager(or whatever you have),cn=config Password: (password) Note: To check for Replication Manager account, browse to Directory Tab. Click config. Replication Manager will appear. Edit password here. This needs to exist on both directory servers. 3. Did you assign them different unique IDs when creating the client certificates? Note the "m" option. certutil -S -n "Server-Cert-dirsrv2-hq" -s "cn=dirsrv2.example.com,cn=Directory Server" -c "CA certificate" -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt

1 0

Re: [389-users] SSL
by Rich Megginson 17 Apr '14

17 Apr '14

Replying to list. On 04/17/2014 12:22 PM, Andy wrote: > > I am having an issue with securing Directory Server communication > using SSL which I need guidance on how to solve. I am setting up a > master and slave which will use SSL to secure communication between > the two servers and to all other clients. > > I used openssl to create a CA cert and sign the Manager server > certificate as follows: > > -CA cert created by *openssl req -config openssl.cnf -new -x509 > -extensions v3_ca -keyout private/ca.key****-out certs/ca.crt -days > 3650*** > > -Manager server csr signed - *openssl ca -config openssl.cnf -policy > policy_anything -out certs/**xxx.crt -infiles****xxx.csr* > > -Checked both certs using before installing on Manager > > -Both certs were installed using root. > > -Enabled encryption via the console and restarted dirsrv. Note coms > remain of port 389 after the reboot. E.g. xxx.com:389 > > - > > ocertutil -L -d . output show that both a CA cert and server cert are > installed as follows: > > server-cert u,u,u > > xxxx-ca.crt CT,, > > -I checked that the server is listening on port 636. Logs also > confirmed that the Manager is listening on port 636 > > -I tested that the Manager can receive connection on port 636, by > connecting using telnet from another server -- telnet <server name> > 636. The connect was also visible on netstat output. > > -I can't see any errors in /var/log/dirsrv/slpad-<server>/errors > > Can you help so that I can setup secure communication correctly? > > Kind regards > > Andy >

3 2

initialization issue
by Elizabeth Jones 17 Apr '14

17 Apr '14

We upgraded our servers to 389-ds-base-1.2.11.25-1.el6.x86_64 a couple of months ago, and earlier this evening I tried to initialize a corrupted replica but it did not initialize successfully. I was using the 389-console gui, not sure if that makes any difference. My logs showed that the initialization had been successful, but my replica had no data in it. Everything had been erased, as expected, but nothing was imported. I've done this type of initialize many times in the past and this has never happened. Does anyone have any thoughts on why my replica did not initialize? thanks, EJ

2 3

MMR Replication
by John Trump 16 Apr '14

16 Apr '14

I am trying to configure MMR replication and am receiving the following error in the error log: slapi_ldap_bind - Error: could not send bind request for id [cn=repman,cn=config] mech [SIMPLE]: error -1 (Can't contact LDAP server) -5992 (function not implemented.) 115 (Operation now in progress) I am running ssl and I can successfully perform an ldapsearch from each server to the other using ldaps Any suggestions?

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users April 2014