Home / server / Questions / 601588
In Process
austinian
Asked: 2014-06-04 14:04:48 +0800 CST

LDAP over SSL with an EFI Fiery printer

  • 772

I've got a printer with a Fiery running 8e Release 2. I can authenticate users against AD using the LDAP configuration, but I can only get it to work if I don't use SSL/TLS, and only if I use SIMPLE authentication. Right now, it's authenticating using a fairly low-impact user, but it's also the only system on our network that's not using LDAPS.

I can get AD info fine over LDAPS using ldp.exe from my machine, our firewall, our mail filter, our linux boxes, etc. The only problem child is the Fiery.

I've added the LDAP server certificate as a trusted cert to the Fiery, but after I check the box for Secure Communication and change the port to 636, pressing Validate results in a dialog box coming up saying: LDAP Validation Failed Server Name invalid or server is unavailable.

I've tried changing the server name to use just the name, the FQDN, and the IP address, and changed it to another server, just to see if it was just this AD server that was fussy with the Fiery.

EDIT: removed LDP output, added packet capture analysis from wireshark: The conversation seems pretty normal to me, up to the point where the Fiery terminates the connection after the server sends back a handshake response. Maybe they messed up their TLS implementation? I'm trying support, but it's been fairly useless so far. The cert is a SHA-2 (sha256RSA) 2048-bit certificate. Also, it looks like the Fiery is specifying TLS 1.0. Looking at http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx, I'm not seeing SHA256 and TLS 1.0 combination being supported by SChannel. headdesk perhaps that's why, after the DC changes the cipher spec, the connection is terminated by the Fiery? TLS 1.1 and 1.2 are enabled on the DC.

Wireshark conversation: DC: 172.17.2.22, Fiery: 172.17.2.42

No.Time        Source            Port Destination  Port  Protocol Length Info
1  0.000000000 172.17.2.42      48633 172.17.2.22  ldaps TCP      74     48633 > ldaps [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3101761 TSecr=0 WS=4
2  0.000182000 Dell_5e:94:e3          Broadcast          ARP      60     Who has 172.17.2.42?  Tell 172.17.2.22
3  0.000369000 TyanComp_c9:0f:90      Dell_5e:94:e3      ARP      60     172.17.2.42 is at 00:e0:81:c9:0f:90
4  0.000370000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      74     ldaps > 48633 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=67970573 TSecr=3101761
5  0.000548000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=3101761 TSecr=67970573
6  0.001000000 172.17.2.42      48633 172.17.2.22  ldaps TLSv1    147    Client Hello
7  0.001326000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      1514   [TCP segment of a reassembled PDU]
8  0.001513000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      1514   [TCP segment of a reassembled PDU]
9  0.001515000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=1449 Win=8736 Len=0 TSval=3101761 TSecr=67970573
10 0.001516000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=2897 Win=11632 Len=0 TSval=3101761 TSecr=67970573
11 0.001732000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      1514   [TCP segment of a reassembled PDU]
12 0.001737000 172.17.2.22      ldaps 172.17.2.42  48633 TLSv1    1243   Server Hello, Certificate, Certificate Request, Server Hello Done
13 0.001738000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=4345 Win=14528 Len=0 TSval=3101761 TSecr=67970573
14 0.001739000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=5522 Win=17424 Len=0 TSval=3101761 TSecr=67970573
15 0.002906000 172.17.2.42      48633 172.17.2.22  ldaps TLSv1    78     Certificate
16 0.004155000 172.17.2.42      48633 172.17.2.22  ldaps TLSv1    333    Client Key Exchange
17 0.004338000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      66     ldaps > 48633 [ACK] Seq=5522 Ack=361 Win=66304 Len=0 TSval=67970573 TSecr=3101762
18 0.004338000 172.17.2.42      48633 172.17.2.22  ldaps TLSv1    72     Change Cipher Spec
19 0.005481000 172.17.2.42      48633 172.17.2.22  ldaps TLSv1    327    Encrypted Handshake Message
20 0.005645000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      66     ldaps > 48633 [ACK] Seq=5522 Ack=628 Win=66048 Len=0 TSval=67970574 TSecr=3101762
21 0.010247000 172.17.2.22      ldaps 172.17.2.42  48633 TLSv1    125    Change Cipher Spec, Encrypted Handshake Message
22 0.016451000 172.17.2.42      48633 172.17.2.22  ldaps TCP      66     48633 > ldaps [FIN, ACK] Seq=628 Ack=5581 Win=17424 Len=0 TSval=3101765 TSecr=67970574
23 0.016630000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      66     ldaps > 48633 [ACK] Seq=5581 Ack=629 Win=66048 Len=0 TSval=67970575 TSecr=3101765
24 0.016811000 172.17.2.22      ldaps 172.17.2.42  48633 TCP      60     ldaps > 48633 [RST, ACK] Seq=5581 Ack=629 Win=0 Len=0

EDIT: revisited this issue after the recent SCHANNEL patching and POODLE prompted changing our cipher management, and I'm still having this issue.

EDIT: addressing @DTK's answer: Root CA added already. Readded to test. DC FQDN being used, cert matches FQDN, resolves correctly in DNS. Client can access DC using LDAP just fine. Other clients reach LDAPS on same DC just fine. DC supports TLS 1.0, 1.1, and 1.2. Using Simple Auth. Public key is RSA 2048 bit signed with SHA256.

Here's the supported ciphers in cipher order for SCHANNEL from HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

active-directory

2 Answers

  1. You need to have all of the following for LDAPS to work:

    • Configure the client to trust the CA that issued the certificate (or if using a hierarchical PKI, the root CA)
    • Configure the client to access the Domain Controller server via FQDN
    • The FQDN of the Domain Controller server must resolve correctly in DNS
    • The FQDN of the Domain Controller server configured in the client must match the SubjectCN in the certificate used for TLS OR must match one of the entries in the SubjectAlternativeName in the certificate used for TLS
    • If the client device does not use Kerberos (and specifically an AD-compatible Kerberos), you must use Simple Auth
      • SASL will not work, and attempting to use it will ABEND with an unhelpful error message
    • The client and server must support a common set of TLS Protocol Versions (Preferably TLS 1.1 or later) and a common set of algorithms (Key Exchange, Authentication, Symmetric-key Cipher and Hash/MAC)
      • KEX : RSA, DHE, ECDHE
      • AuthN : RSA, DSA, ECDSA
      • Cipher : AES-CBC, AES-GCM (oh dear gods, not RC4, DES or 3DES)
      • Hash : SHA, SHA256/384/512 (please, please, not MD2 or MD5)
    • The client and server must support common key-lengths
      • RSA : 2048 bit or 4096 bit public-key-length
      • DSA : 2048 bit public-key-length (if supported ; many only support 1024 bit keys)
      • ECDSA/ECDHE : 283 bit or longer, based on https://www.rfc-editor.org/rfc/rfc4492
      • AES : 128 bit or longer
      • SHA* : 256 bit or larger bucket-size / digest-length
    • 1

  2. The Fiery shouldn't need to trust the LDAP server certificate directly. It should be trusting the CA or chain of CAs that signed the LDAP server certificate.

    Additionally, does the LDAP server certificate contain references to a CRL checking location or OSCP server? And if so, does the Fiery's network connectivity have access to that location(s)? The cert may be valid, but the Fiery might not be able to properly check that it hasn't been revoked.

    Another (uncommon) thing that might be going on is if the Fiery is choking on something like the key length of the certificate.

    • 0