I'm running OpenLDAP 2.3.21 on Ubuntu Linux. Following Aaron's advice, I ACL'd out the supportedSASLMechanisms attribute, which is allowing OS X clients to auth against the server as expected.
However, I've noticed that all of the OS X clients need to connect twice before they can establish a successful TLS session. This is only when using OS X's native LDAP functionality. Queries from the same clients using 'ldapsearch' work just fine. Below is a snippet from the debug log showing the connect-fail-reconnect (with the longer hex dumps snipped). Is there any other debugging I can do to figure out why the first connection is rejected by slapd? Thanks! -Ben connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=0 TLS: can't accept. connection_read(11): TLS accept failure error=-1 id=0, closing connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 connection_get(11) connection_get(11): got connid=1 connection_read(11): checking for input on id=1 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 0000: 80 8c 01 03 01 00 63 00 00 00 20 ......c... tls_read: want=131, got=131 0000: 00 00 39 00 00 38 00 00 35 00 00 16 00 00 13 00 ..9..8..5....... <snip> ... TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A tls_write: want=972, written=972 0000: 16 03 01 00 4a 02 00 00 46 03 01 44 72 40 ca 89 [EMAIL PROTECTED] <snip> TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(11) connection_get(11): got connid=1 connection_read(11): checking for input on id=1 tls_read: want=5, got=5 0000: 16 03 01 00 86 ..... tls_read: want=134, got=134 0000: 10 00 00 82 00 80 5e f6 e2 0d c3 de 8a f0 f9 ce ......^......... <snip> .. ... TLS trace: SSL_accept:SSLv3 read client key exchange A tls_read: want=5, got=5 0000: 14 03 01 00 01 ..... tls_read: want=1, got=1 0000: 01 . tls_read: want=5, got=5 0000: 16 03 01 00 30 ....0 tls_read: want=48, got=48 0000: fd 7f 0f 49 98 2f b3 b2 2a 97 79 25 de 75 0c 01 ...I./..*.y%.u.. 0010: bc 19 d3 6f fa 0e 33 f3 78 b2 51 da d8 0f 5b 77 ...o..3.x.Q...[w 0020: 65 fe ec 0d de ff 2e 09 c5 a1 bd 72 76 04 15 7c e..........rv..| TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A tls_write: want=59, written=59 0000: 14 03 01 00 01 01 16 03 01 00 30 35 96 a4 f2 1b ..........05.... 0010: fc a3 65 68 ce ab fc d8 c3 54 fd 9f c1 82 88 e4 ..eh.....T...... 0020: 8b b0 af 5b 48 20 c3 d6 35 03 62 c3 ec bb 36 c7 ...[H ..5.b...6. 0030: 05 94 8e c8 39 ad 25 25 a8 65 84 ....9.%%.e. TLS trace: SSL_accept:SSLv3 flush data connection_read(11): unable to get TLS client DN, error=49 id=1 connection_get(11) connection_get(11): got connid=1 connection_read(11): checking for input on id=1 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 20 .... tls_read: want=32, got=32 0000: 54 03 eb 2e 8f 52 b9 18 7d fb 48 fd 8c 6e 72 9d T....R..}.H..nr. 0010: 0e 01 2d 64 22 53 b0 b5 b3 0e 44 c5 d6 e6 90 f0 ..-d"S....D..... tls_read: want=5, got=5 0000: 17 03 01 00 30 ....0 tls_read: want=48, got=48 0000: a4 b7 7a dd d1 b8 08 f2 8c 52 dd 56 f2 43 17 dc ..z......R.V.C.. 0010: 32 8d 0f 8c 37 1d fd 18 4e a5 db 87 4c 2f 7e 5b 2...7...N...L/~[ 0020: 26 0e 5a 85 90 1e ce b1 b7 3a 70 9f cb fa 14 4f &.Z......:p....O ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_get_next tls_read: want=5 error=Resource temporarily unavailable ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable) do_bind
