Bug 1353564

(In reply to mreynolds from comment #0)
> Description of problem:
> 
> ldapjdk 4.18 does not support IPv6 addresses.  In particular the LDAP URL
> parsing does not comply with RFC 2732:
> 
> ldap://[::1]:389

Per discussions with Nathan Kinder, this is a layered product change (DS) that is a safe and simple fix which will be verified by the CS and DS teams.

ldapjdk-4.18-19.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1835df9b39

ldapjdk-4.18-19.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f6bc9b601

ldapjdk-4.18-19.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3f6bc9b601

ldapjdk-4.18-19.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1835df9b39

ldapjdk-4.18-19.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

ldapjdk-4.18-19.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Hi Mark,

I have followed the steps you have mentioned above but when I am creating an agreement and specifying "[::1]" in consumer hostname it does not accept that value and I can not proceed after that.

Is there any other way of doing this step ?

I have the following installed on my system:

389-ds-console-1.2.12-1.el7dsrv.noarch 
idm-console-framework.noarch-1.1.16-2.el7dsrv
ldapjdk.noarch-4.18-15.el7

Thanks for the info Viktor!

Packages used to verify this fix:

[root@pki3 ~]# rpm -qa | grep ldapjdk
ldapjdk-4.18-15.el7.noarch

[root@pki3 ~]# rpm -qa | grep idm-console-framework
idm-console-framework-1.1.16-2.el7dsrv.noarch

[root@pki3 ~]# rpm -qa | grep 389-ds-console
389-ds-console-doc-1.2.13-1.el7dsrv.noarch
389-ds-console-1.2.13-1.el7dsrv.noarch

Following are steps performed to verify the fix:

Part 1:

[1]  Install 389-ds-base, 389-console, 389-ds-console, idm-console-framework
[2]  Install Directory Server and Admin Server:  setup-ds-admin.pl
[3]  Launch the console:   389-console
[4]  Open up the navigation tree and open the Directory Server console
[5]  Goto the "Configuration tab, open "data" -> "o=netscaperoot"
[6]  Click on the "Referrals" tab,
[7]  "Enter a new referral" -> use  "ldap://[::1]:389/dc%3dexample,dc%3dcom"
[8]  Click "add", and then save

Part 2:

test that ldapjdk can use the IPv6 address

[1]  Create a new instance of Directory Server in the console (use port 5555).  We'll call this Server B
[2]  Configure Server B for replication.  Make it a consumer.
[3]  On Server A setup replication (single master)
[4] Before creating an agreement make sure to ldapadd the following entries in consumer

dn: cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: replica
nsds5replicaroot: dc=example,dc=com
nsds5replicaid: 1      
nsds5replicatype: 3
nsds5flags: 1
nsds5beginreplicarefresh: start
nsds5ReplicaBindDN: cn=replication manager,cn=config
EOF


dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM                 
userPassword: Secret123
passwordExpirationTime: 20380119031407Z
EOF
[5]  Create an agreement, but for the consumer hostname specify: "[::1]" and port "5555"
[6]  Initialize the agreement.
[7]  Make an update on Server A and make sure that update is replicated to Server B


After replication is configured, a record "testuser" created on master is seen on the replica as well


[root@pki3 ~]# ldapsearch -x -D "cn=Directory Manager" -h pki3.example.com -p 5555 -w Secret123 -b "dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain

# Directory Administrators, example.com
dn: cn=Directory Administrators,dc=example,dc=com
uniqueMember: cn=Directory Manager
cn: Directory Administrators
objectClass: top
objectClass: groupofuniquenames

# Groups, example.com
dn: ou=Groups,dc=example,dc=com
ou: Groups
objectClass: top
objectClass: organizationalunit

# People, example.com
dn: ou=People,dc=example,dc=com
ou: People
objectClass: top
objectClass: organizationalunit

# Special Users, example.com
dn: ou=Special Users,dc=example,dc=com
description: Special Administrative Accounts
ou: Special Users
objectClass: top
objectClass: organizationalUnit

# Accounting Managers, Groups, example.com
dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com
uniqueMember: cn=Directory Manager
description: People who can manage accounting entries
ou: groups
cn: Accounting Managers
objectClass: top
objectClass: groupOfUniqueNames

# HR Managers, Groups, example.com
dn: cn=HR Managers,ou=Groups,dc=example,dc=com
uniqueMember: cn=Directory Manager
description: People who can manage HR entries
ou: groups
cn: HR Managers
objectClass: top
objectClass: groupOfUniqueNames

# QA Managers, Groups, example.com
dn: cn=QA Managers,ou=Groups,dc=example,dc=com
uniqueMember: cn=Directory Manager
description: People who can manage QA entries
ou: groups
cn: QA Managers
objectClass: top
objectClass: groupOfUniqueNames

# PD Managers, Groups, example.com
dn: cn=PD Managers,ou=Groups,dc=example,dc=com
uniqueMember: cn=Directory Manager
description: People who can manage engineer entries
ou: groups
cn: PD Managers
objectClass: top
objectClass: groupOfUniqueNames

# testuser, repl keep alive 3333, example.com
dn: uid=testuser,cn=repl keep alive 3333,dc=example,dc=com
uid: testuser
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: user
cn: testuser
userPassword:: e1NTSEF9dUZOOVUrcXMzNlIvSnFacW8vU3owN090SU91U1JMcUVNSG5uVXc9PQ=
 =

# search result
search: 2
result: 0 Success

# numResponses: 11
# numEntries: 10

[root@pki3 ~]# ldapsearch -x -D "cn=Directory Manager" -h pki3.example.com -p 389 -w Secret123 -b "dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example

# Directory Administrators, example.com
dn: cn=Directory Administrators,dc=example,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: Directory Administrators
uniqueMember: cn=Directory Manager

# Groups, example.com
dn: ou=Groups,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: Groups

# People, example.com
dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalunit
ou: People

# Special Users, example.com
dn: ou=Special Users,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Special Users
description: Special Administrative Accounts

# Accounting Managers, Groups, example.com
dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: Accounting Managers
ou: groups
description: People who can manage accounting entries
uniqueMember: cn=Directory Manager

# HR Managers, Groups, example.com
dn: cn=HR Managers,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: HR Managers
ou: groups
description: People who can manage HR entries
uniqueMember: cn=Directory Manager

# QA Managers, Groups, example.com
dn: cn=QA Managers,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: QA Managers
ou: groups
description: People who can manage QA entries
uniqueMember: cn=Directory Manager

# PD Managers, Groups, example.com
dn: cn=PD Managers,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: PD Managers
ou: groups
description: People who can manage engineer entries
uniqueMember: cn=Directory Manager

# testuser, repl keep alive 3333, example.com
dn: uid=testuser,cn=repl keep alive 3333,dc=example,dc=com
uid: testuser
givenName: test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: user
cn: testuser
userPassword:: e1NTSEF9dUZOOVUrcXMzNlIvSnFacW8vU3owN090SU91U1JMcUVNSG5uVXc9PQ=
 =

# search result
search: 2
result: 0 Success

# numResponses: 11
# numEntries: 10

As I'm able to see user entry (testuser) in the consumer after enabling replication marking this bug as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2563.html