This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/332

OS RHEL 6.2  (x86_64)
 
Packages Installed:
{{{
389-admin-1.1.29-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-admin-console-doc-1.1.8-1.el6.noarch
389-adminutil-1.1.15-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
openldap-clients-2.4.23-20.el6.x86_64
}}}

{{{
/usr/lib64/dirsrv/slapd-<instance>/db2bak.pl -v -D "cn=Directory Manager" -w -
Bind Password:
Back up directory: /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_13_21
ldap_initialize( ldap://<FQDN>:389 )
ldap_bind: Confidentiality required (13)
        additional info: Operation requires a secure connection
}}}

For me the following simple fix proved to be a working solution (having said that I haven’t tried a restore yet):
With ldapmodify, ldap://<host> apparently kicks off a TLS connection whereas <host> on it’s own doesn’t. All very odd, anyhoo:
 
db2bak.pl : Line 125 add “ldap://” before the host name.

{{{
open(FOO, "| ldapmodify -x $vstr -h ldap://<host> -p 389 -D \"$rootdn\" -w \"$passwd\" -a" );
}}}

Rerunning with ldap:// added: 
{{{
/usr/lib64/dirsrv/slapd-<instance>/db2bak.pl -v -D "cn=Directory Manager" -w -
Bind Password:
Back up directory: /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_14_14
ldap_initialize( <DEFAULT> )
add objectclass:
        top
        extensibleObject
add cn:
        backup_2012_3_30_10_14_14
add nsArchiveDir:
        /var/lib/dirsrv/slapd-<instance>/bak/<instance>-2012_3_30_10_14_14
add nsDatabaseType:
        ldbm database
adding new entry "cn=backup_2012_3_30_10_14_14, cn=backup, cn=tasks, cn=config"
modify complete
}}}
 
Straight forward enough change to the template…