Re: [389-users] glue entry problem
by David Hall
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
6 years, 2 months
Sync from RDBMS to LDAP
by Fong, Trevor
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
6 years, 2 months
Re: [389-users] SSL
by Andy Spooner
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
6 years, 2 months
Allow Directory Manager to bypass Password Policy
by John Trump
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.
6 years, 2 months
Re: [389-users] SSL
by Andy Spooner
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
6 years, 2 months
Re: [389-users] SSL
by Andy Spooner
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
6 years, 2 months
Re: [389-users] SSL
by Rich Megginson
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
>
6 years, 2 months
initialization issue
by Elizabeth Jones
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
6 years, 2 months
MMR Replication
by John Trump
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?
6 years, 2 months
[389][Active Directory] Replication issue
by Moisés Barba Pérez
Hello,
Unfortunately in our organization we have a replication agreement
between 389 DS and an Active Directory.
For some reason, some Active Directory admin has run a script which has
change the "givenname" and "sn" attrs (now they are in base64) and that
change have been replicated to the 389 DS (1).
The issue is: This changes coming from replication aren't shown in the
server logs with the AD agreement, I saw them in the access file and audit
file but from another 389 DS (2) server with multimaster replication
agreement not in the server with the AD agreement ¿Is this normal? We are
using 1.2.5 version.
AD <=====> 389 DS (1) <=====> 389 DS (2)
Regards,
Moses.
6 years, 2 months
