Bug 754992

[root@decepticons slapd-LAB-ENG-PNQ-REDHAT-COM]# certutil -L -d .

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

LAB.ENG.PNQ.REDHAT.COM IPA CA                                CT,,C
CN=self-signed-CAcert                                        CT,,C
Server-Cert                                                  u,u,u
[root@decepticons slapd-LAB-ENG-PNQ-REDHAT-COM]# 


[root@decepticons ~]# ipa-replica-manage connect --winsync --passsync=password --cacert=/root/kashyap/test-ca.crt dhcp201-112.englab.pnq.redhat.com --binddn "cn=Administrator,cn=Users,dc=englab,dc=pnq,dc=redhat,dc=com" --bindpw Secret123 -v -p Secret123
Added CA certificate /root/kashyap/test-ca.crt to certificate database for decepticons.lab.eng.pnq.redhat.com
INFO:root:AD Suffix is: DC=englab,DC=pnq,DC=redhat,DC=com
The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com
Windows PassSync entry exists, not resetting password
INFO:root:Added new sync agreement, waiting for it to become ready . . .
INFO:root:Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 20111118175748Z: end: 20111118175748Z
INFO:root:Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
Update succeeded
Connected 'decepticons.lab.eng.pnq.redhat.com' to 'dhcp201-112.englab.pnq.redhat.com'
[root@decepticons ~]#



[root@decepticons slapd-LAB-ENG-PNQ-REDHAT-COM]# ldapsearch -x -h decepticons.lab.eng.pnq.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=mapping tree,cn=config" 
# extended LDIF
#
# LDAPv3
# base <cn=mapping tree,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# mapping tree, config
dn: cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
cn: mapping tree

# dc\3Dlab\2Cdc\3Deng\2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom, mapping tree, conf
 ig
dn: cn=dc\3Dlab\2Cdc\3Deng\2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=mapping tree
 ,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com
cn: "dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com"
nsslapd-state: backend
nsslapd-backend: userRoot
nsslapd-referral: ldap://sideswipe.lab.eng.pnq.redhat.com:389/dc%3Dlab%2Cdc%3D
 eng%2Cdc%3Dpnq%2Cdc%3Dredhat%2Cdc%3Dcom

# replica, dc\3Dlab\2Cdc\3Deng\2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom, mapping t
 ree, config
dn: cn=replica,cn=dc\3Dlab\2Cdc\3Deng\2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=m
 apping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 3
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN: krbprincipalname=ldap/sideswipe.lab.eng.pnq.redhat.com@LAB
 .ENG.PNQ.REDHAT.COM,cn=services,cn=accounts,dc=lab,dc=eng,dc=pnq,dc=redhat,dc
 =com
nsState:: AwAAAAAAAAC5nMZOAAAAAAAAAAAAAAAAFwAAAAAAAAAEAAAAAAAAAA==
nsDS5ReplicaName: f46ae881-112311e1-bdfaa144-3581a2fd
nsds5ReplicaChangeCount: 47563
nsds5replicareapactive: 0

# meTodhcp201-112.englab.pnq.redhat.com, replica, dc\3Dlab\2Cdc\3Deng\2Cdc\3D
 pnq\2Cdc\3Dredhat\2Cdc\3Dcom, mapping tree, config
dn: cn=meTodhcp201-112.englab.pnq.redhat.com,cn=replica,cn=dc\3Dlab\2Cdc\3Deng
 \2Cdc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: cn=Users,DC=englab,DC=pnq,DC=redhat,DC=com
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=lab,dc=eng,dc=pnq,dc=red
 hat,dc=com
nsDS5ReplicaUpdateSchedule: 0000-2359 0123456
cn: meTodhcp201-112.englab.pnq.redhat.com
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to dhcp201-112.englab.pnq.redhat.com
nsDS5ReplicaRoot: dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com
nsDS5ReplicaHost: dhcp201-112.englab.pnq.redhat.com
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=Administrator,cn=Users,dc=englab,dc=pnq,dc=redhat,dc=co
 m
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: lab.eng.pnq.redhat.com
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krbl
 astsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials: {DES}MdU5bxh5HKD/KVqD0jfUqg==
nsds7DirsyncCookie:: TVNEUwMAAABOSyWnG6bMAQAAAAAAAAAAKAAAAImmAAAAAAAAAAAAAAAAA
 ACJpgAAAAAAAKKzNQJqRVJFhXBlBt3uXvwBAAAAAAAAAAEAAAAAAAAAorM1AmpFUkWFcGUG3e5e/I
 mmAAAAAAAA
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20111118175817Z
nsds5replicaLastUpdateEnd: 20111118175817Z
nsds5replicaChangesSentSinceStartup:: MzoyLzAg
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd
 ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20111118175750Z
nsds5replicaLastInitEnd: 20111118175751Z
nsds5replicaLastInitStatus: 0 Total update succeeded

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 4

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2129

I can't reproduce this against my AD server.

I created bogus CA and tried to use that:

# ipa-replica-manage connect --winsync --cacert=/tmp/test-ca.crt --binddn=cn=administrator,cn=users,dc=example,dc=com --bindpw Password1 win2003.example.com -v --passsync Password1
Added CA certificate /tmp/test-ca.crt to certificate database for rawhide.example.com
ipa: INFO: Failed to connect to AD server win2003.example.com
ipa: INFO: The error was: {'info': 'TLS error -8179:Unknown code ___f 13', 'desc': 'Connect error'}
Failed to setup winsync replication

-8179 is "Certificate is signed by an unknown issuer" which is what I would expect.

I just tried again, works for me. Can you provide additional reproduction steps?

I was provided a machine that demonstrates this issue. This was extremely helpful.

I switched to using ldapsearch -ZZ to diagnose the problem and this led me to two problems:

1. The CA cert was in /etc/openldap/cacerts. openldap automatically loads these certs which is why the AD CA was trusted even though the incorrect one was passed on the cli.
2. /etc/openldap/ldap.conf had TLS_REQCERT set to allow. This means that a bad server cert is accepted even if untrusted.

I renamed ldap.conf to ldap.conf.old and confirmed that neither ldapsearch nor ipa-replica-manage work any more:

# cd /etc/openldap
# mv ldap.conf ldap.conf.old
# ipa-replica-manage connect --winsync --passsync=password --cacert=/root/kashyap/test-ca.crt dhcp201-112.englab.pnq.redhat.com --binddn "cn=Administrator,cn=Users,dc=englab,dc=pnq,dc=redhat,dc=com" --bindpw Secret123 -v -p Secret123
Added CA certificate /root/kashyap/test-ca.crt to certificate database for decepticons.lab.eng.pnq.redhat.com
INFO:root:Failed to connect to AD server dhcp201-112.englab.pnq.redhat.com
INFO:root:The error was: {'info': 'TLS error -8179:Unknown code ___f 13', 'desc': 'Connect error'}
Failed to setup winsync replication

I restored the system to its previous state.