ฉันมีเครื่องพิมพ์ที่ใช้ Fiery ที่ใช้ 8e Release 2 ได้ ฉันสามารถตรวจสอบผู้ใช้กับ AD โดยใช้การกำหนดค่า LDAP แต่ฉันจะทำให้ใช้งานได้ก็ต่อเมื่อฉันไม่ได้ใช้ SSL/TLS และเฉพาะในกรณีที่ฉันใช้การตรวจสอบสิทธิ์แบบง่ายเท่านั้น . ขณะนี้ กำลังตรวจสอบสิทธิ์โดยใช้ผู้ใช้ที่มีผลกระทบค่อนข้างต่ำ แต่ก็เป็นระบบเดียวในเครือข่ายของเราที่ไม่ได้ใช้ LDAPS

ฉันสามารถรับข้อมูล AD ได้ดีบน LDAPS โดยใช้ ldp.exe จากเครื่องของฉัน ไฟร์วอลล์ ตัวกรองเมล กล่อง linux ของเรา ฯลฯ ปัญหาลูกเดียวคือ Fiery

ฉันได้เพิ่มใบรับรองเซิร์ฟเวอร์ LDAP เป็นใบรับรองที่เชื่อถือได้ใน Fiery แล้ว แต่หลังจากที่ฉันทำเครื่องหมายในช่องสำหรับการสื่อสารที่ปลอดภัยและเปลี่ยนพอร์ตเป็น 636 แล้ว การกดตรวจสอบผลลัพธ์ในกล่องโต้ตอบจะปรากฏขึ้นโดยระบุว่า: LDAP Validation Failed Server Name ไม่ถูกต้อง หรือ เซิร์ฟเวอร์ไม่พร้อมใช้งาน

ฉันได้ลองเปลี่ยนชื่อเซิร์ฟเวอร์เพื่อใช้เพียงชื่อ FQDN และที่อยู่ IP และเปลี่ยนเป็นเซิร์ฟเวอร์อื่นเพื่อดูว่าเป็นเพียงเซิร์ฟเวอร์ AD นี้ที่จู้จี้จุกจิกกับ Fiery หรือไม่

แก้ไข: ลบเอาต์พุต LDP เพิ่มการวิเคราะห์การดักจับแพ็กเก็ตจาก wireshark: การสนทนาดูเหมือนปกติสำหรับฉัน จนถึงจุดที่ Fiery ยุติการเชื่อมต่อหลังจากที่เซิร์ฟเวอร์ส่งการตอบกลับการจับมือกันกลับ บางทีพวกเขาอาจทำให้การใช้งาน TLS ผิดพลาด? ฉันกำลังพยายามสนับสนุน แต่มันก็ค่อนข้างไร้ประโยชน์จนถึงตอนนี้ ใบรับรองเป็นใบรับรอง SHA-2 (sha256RSA) 2048 บิต นอกจากนี้ ดูเหมือนว่า Fiery กำลังระบุ TLS 1.0 เมื่อดูที่http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspxฉันไม่เห็น SHA256 และ TLS 1.0 รองรับ SChannel headdeskอาจเป็นเพราะเหตุนี้ หลังจากที่ DC เปลี่ยนข้อมูลจำเพาะของตัวเลข การเชื่อมต่อจึงสิ้นสุดลงโดย Fiery? TLS 1.1 และ 1.2 เปิดใช้งานบน DC

บทสนทนาของ Wireshark: DC: 172.17.2.22, คะนอง: 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

แก้ไข: กลับมาที่ปัญหานี้อีกครั้งหลังจากการแพตช์ SCHANNEL ล่าสุดและ POODLE แจ้งเตือนให้เปลี่ยนการจัดการการเข้ารหัสของเรา และฉันยังคงประสบปัญหานี้อยู่

แก้ไข: ระบุคำตอบของ @ DTK: เพิ่ม Root CA แล้ว อ่านเพื่อทดสอบ กำลังใช้ DC FQDN ใบรับรองตรงกับ FQDN แก้ไขอย่างถูกต้องใน DNS ลูกค้าสามารถเข้าถึง DC โดยใช้ LDAP ได้ดี ลูกค้ารายอื่นเข้าถึง LDAPS บน DC เดียวกันได้ DC รองรับ TLS 1.0, 1.1 และ 1.2 การใช้การตรวจสอบสิทธิ์อย่างง่าย คีย์สาธารณะคือ RSA 2048 บิตที่ลงนามด้วย SHA256

นี่คือการเข้ารหัสที่รองรับในลำดับการเข้ารหัสสำหรับ SCHANNEL จาก 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

answer

คุณต้องมีสิ่งต่อไปนี้ทั้งหมดเพื่อให้ LDAPS ทำงานได้:

  • กำหนดค่าไคลเอนต์ให้เชื่อถือ CA ที่ออกใบรับรอง (หรือถ้าใช้ PKI แบบลำดับชั้น ให้ไปที่ root CA)
  • กำหนดค่าไคลเอนต์เพื่อเข้าถึงเซิร์ฟเวอร์ Domain Controller ผ่าน FQDN
  • FQDN ของเซิร์ฟเวอร์ Domain Controller ต้องแก้ไขอย่างถูกต้องใน DNS
  • FQDN ของเซิร์ฟเวอร์ Domain Controller ที่กำหนดค่าในไคลเอ็นต์ต้องตรงกับ SubjectCN ในใบรับรองที่ใช้สำหรับ TLS หรือต้องตรงกับรายการใดรายการหนึ่งใน SubjectAlternativeName ในใบรับรองที่ใช้สำหรับ TLS
  • หากอุปกรณ์ไคลเอ็นต์ไม่ได้ใช้ Kerberos (และเฉพาะ Kerberos ที่เข้ากันได้กับ AD) คุณต้องใช้ Simple Auth
    • SASL จะไม่ทำงาน และการพยายามใช้งานจะ ABEND พร้อมข้อความแสดงข้อผิดพลาดที่ไม่ช่วยเหลือ
  • ไคลเอนต์และเซิร์ฟเวอร์ต้องรองรับชุดทั่วไปของ TLS Protocol Versions (ควรเป็น TLS 1.1 หรือใหม่กว่า) และชุดอัลกอริธึมทั่วไป (Key Exchange, Authentication, Symmetric-key Cipher และ Hash/MAC)
    • KEX: RSA และ ECDHE
    • รับรองความถูกต้อง: RSA, DSA, ECDSA
    • รหัส : AES-CBC, AES-GCM (โอ้ พระเจ้า ไม่ใช่ RC4, DES หรือ 3DES)
    • แฮช : SHA, SHA256/384/512 (ได้โปรด ไม่ใช่ MD2 หรือ MD5)
  • ไคลเอนต์และเซิร์ฟเวอร์ต้องรองรับความยาวคีย์ทั่วไป
    • RSA : ความยาวคีย์สาธารณะ 2048 บิตหรือ 4096 บิต
    • DSA : ความยาวคีย์สาธารณะ 2048 บิต (หากรองรับ หลายรุ่นรองรับเฉพาะคีย์ 1024 บิตเท่านั้น)
    • ECDSA/ECDHE : 283 บิตขึ้นไป ตามhttps://www.rfc-editor.org/rfc/rfc4492
    • AES : 128 บิตขึ้นไป
    • SHA* : ขนาดถัง 256 บิตหรือใหญ่กว่า / ไดเจสต์-ความยาว

Fiery ไม่จำเป็นต้องเชื่อถือใบรับรองเซิร์ฟเวอร์ LDAP โดยตรง ควรเชื่อถือ CA หรือสายโซ่ของ CA ที่ลงนามในใบรับรองเซิร์ฟเวอร์ LDAP

นอกจากนี้ ใบรับรองเซิร์ฟเวอร์ LDAP มีการอ้างอิงถึงตำแหน่งการตรวจสอบ CRL หรือเซิร์ฟเวอร์ OSCP หรือไม่ และถ้าเป็นเช่นนั้น การเชื่อมต่อเครือข่ายของ Fiery สามารถเข้าถึงตำแหน่งนั้นได้หรือไม่ ใบรับรองอาจใช้ได้ แต่ Fiery อาจไม่สามารถตรวจสอบได้อย่างถูกต้องว่ายังไม่ได้เพิกถอน

อีกสิ่ง (ไม่ปกติ) ที่อาจเกิดขึ้นคือถ้า Fiery สำลักบางอย่างเช่นความยาวของคีย์ของใบรับรอง