[Fedora-directory-users] Re: Hosed sync with AD

[Daniel Shackelford]

------------------------------

> I don't have any insight off the top of my head beyond what you've 
> already tried.
> You could take a packet trace with ethereal or the like and see if 
> there's anything
> interesting in the SSL handshake.


>> Is FDS dependent on specific versions of libssl3.so or ?...  The thing 
>> that confuses me the most is that it all seems to be working fine in 
>> every other case.  I am still not sure there isn't a problem with my 
>> Win2003 domain controller...
>  
>

> FDS should be used with the version of NSS that it was built against.
> There will be some minor functionality differences between NSS releases
> and bug fixes, but I wouldn't expect much sensitivity to NSS version
> as far as basic functionality like this goes.
> 
> Bottom line is that if you can use the 'ldapsearch' command (the Mozilla
> version that ships with FDS), pointed at the same cert database that the
> server is using, to connect to your AD, then FDS's Winsync code should
> be able to connect too : the code paths are essentially identical.

Well, I think I found the problem...

Here is the output of ssltap that captured a request to the DC:
--> [
alloclen = 54 bytes
(54 bytes of 54)
 [Wed Feb  1 12:39:36 2006] [ssl2]  ClientHelloV2 {
           version = {0x03, 0x01}
           cipher-specs-length = 27 (0x1b)
           sid-length = 0 (0x00)
           challenge-length = 16 (0x10)
           cipher-suites = {
                (0x000004) SSL3/RSA/RC4-128/MD5
                (0x00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
                (0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
                (0x00fefe) SSL3/RSA-FIPS/DES-CBC/SHA
                (0x000009) SSL3/RSA/DES56-CBC/SHA
                (0x000064) TLS/RSA-EXPORT1024/RC4-56/SHA
                (0x000062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
                (0x000003) SSL3/RSA/RC4-40/MD5
                (0x000006) SSL3/RSA/RC2CBC40/MD5
                }
           session-id = { }
           challenge = { 0xc930 0x4121 0xe11d 0x443a 0x77b4 0xaef1 
0x13b0 0xc017 }
}
]
<-- [
(2896 bytes, making 2896 of 4836)
]
<-- [
(1945 bytes, making 4836 of 4836)
SSLRecord { [Wed Feb  1 12:39:36 2006]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 4836 (0x12e4)
   handshake {
      type = 2 (server_hello)
      length = 70 (0x000046)
         ServerHello {
            server_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {..}
            }
            cipher_suite = (0x0004) SSL3/RSA/RC4-128/MD5
         }
      type = 11 (certificate)
      length = 1423 (0x00058f)
         CertificateChain {
            chainlength = 1420 (0x058c)
            Certificate {
               size = 1417 (0x0589)
               data = { saved in file 'cert.001' }
            }
         }
      type = 13 (certificate_request)
      length = 3327 (0x000cff)
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(7 bytes of 2)
SSLRecord { [Wed Feb  1 12:39:36 2006]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 2 (0x2)
   fatal: unknown CA
}
]

Looking through this looks like it is the FDS server that is saying that 
the CA is unknown, but it it refering to the response from the DC, or 
it's own certificate store?  Looking at the dump of extended data from 
ssltap, the response from the DC indicates it is using a cert not signed 
by itself (a CA), but by another server that is not a DC, and in fact a 
non-critical server.  The validity of that CA and all it's certificates 
expired at the time that FDS stopped synconizing.  Why our Windows Admin 
is using CAs around the network willi-nillie is a mystery to me.  I will 
get rid of that cert, and make sure that it is offering up a cert that 
is signed by a third party CA (like CACert.org)

Thank you Dave.  It looks like you were right about this being a stumper 
as long as we are looking for the problem on FDS.

-- 
Daniel Shackelford
Systems Administrator
Technology Services
Spring Arbor University
517 750-6648

"For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many"
Mark 10:45