Bug 800787 - TLS connection to AD no longer works
TLS connection to AD no longer works
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Vcelak
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-07 04:14 EST by Martin Kosek
Modified: 2013-03-03 20:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-08 07:40:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Kosek 2012-03-07 04:14:07 EST
Description of problem:
My Python AD searches stopped working when I updated openldap from openldap-2.4.26-5.fc16.x86_64 to openldap-2.4.26-6.fc16.x86_64. Now, it always returns this error:

ldap.CONNECT_ERROR: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}

When I downgraded back to openldap-2.4.26-5.fc16.x86_64, the TLS connection worked OK again.

Version-Release number of selected component (if applicable):
openldap-2.4.26-6.fc16.x86_64

How reproducible:
I used this test script using python-ldap wrapper:

# cat /tmp/testtls.sh 
import ldap
ad_conn = ldap.initialize('ldap://dhcp201-112.englab.pnq.redhat.com')
ad_conn.set_option(ldap.OPT_DEBUG_LEVEL, 255)
ad_conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0)
ad_conn.set_option(ldap.OPT_X_TLS_CACERTFILE, '/home/mkosek/WinCert2.cer')
ad_conn.start_tls_s()

# python /tmp/testtls.sh
Traceback (most recent call last):
  File "/tmp/testtls.sh", line 6, in <module>
    ad_conn.start_tls_s()
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 526, in start_tls_s
    return self._ldap_call(self._l.start_tls_s)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 96, in _ldap_call
    result = func(*args,**kwargs)
ldap.CONNECT_ERROR: {'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}

Steps to Reproduce:
1. Prepare an LDAP server with support of TLS connection, prepare its certificate (I used Active Directory server)
2. Prepare the script below which will test the TLS connection with provided certificate and server address
3. Run the script
  
Actual results:
TLS connection failed with the TLS error above

Expected results:
TLS connection succeeds, no error is returned
Comment 1 Rich Megginson 2012-03-07 10:54:08 EST
The way openldap TLS initialization works in openldap-2.4.26-6 and later is this:

When you have an LDAP *ld or an ldap handle created by ldap.initialize, and you call ldap_set_option to set options in this handle, they are stored in the options area of the handle, but not in the TLS options area of the handle, until you call set_option(ldap.OPT_X_TLS_NEWCTX, 0).  This causes the creation of the new TLS context and writes the saved TLS option settings into the new TLS context.  If you then attempt to set another TLS option in the same ldap handle, the changes will again be stored in the ldap option area, but not in the TLS context.
Comment 2 Martin Kosek 2012-03-08 07:40:51 EST
Thanks for explanation Rich. When I changed the order of operations in our TLS initialization procedure this way:

ad_conn = ldap.initialize('ldap://dhcp201-112.englab.pnq.redhat.com')
ad_conn.set_option(ldap.OPT_X_TLS_CACERTFILE, '/home/mkosek/WinCert2.cer')
ad_conn.set_option(ldap.OPT_X_TLS_NEWCTX, 0)
ad_conn.start_tls_s()

it worked. Therefore I think we can close this bug as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.