Score:1

Apache HTTP พร้อม Kerberos ไม่ทำงานกับเนวิเกเตอร์ที่ใช้ Chromium บนเครื่องนอกโดเมน

ธง gb

นี่คือการกำหนดค่าโมดูล Apache HTTP Kerberos ใน /etc/apache2/sites-available/my.server.tld.conf:

# ...
<สถานที่ />
  Authname "การรับรองความถูกต้อง SSO"
  AuthType Kerberos
  KrbAuthRealms MY.DOMAIN.TLD
  KrbServiceName HTTP/[email protected]
  Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
  Krbวิธีการเจรจาต่อรอง
  KrbMethodK5Passwd เปิด
  ต้องการผู้ใช้ที่ถูกต้อง
</สถานที่>
# ...

และการกำหนดค่า Kerberos ใน /etc/krb5.conf:

[libdefaults]
  default_realm = MY.DOMAIN.TLD

# ...

[อาณาจักร]
  MY.DOMAIN.TLD = {
    kdc = my.ad.server.1.tld
    kdc = my.ad.server.2.tld
    admin_server = my.ad.server.1.tld
  }

# ...

[domain_realm]
  friendly.domain.tld = MY.DOMAIN.TLD
  .friendly.domain.tld = MY.DOMAIN.TLD

# ...

เว็บเซิร์ฟเวอร์ Apache HTTP ได้รับการติดตั้งบน Debian GNU/Linux 10

ไฟล์คีย์แท็บถูกสร้างขึ้นเมื่อ my.ad.server.1.tldซึ่งเป็น Windows Server โดยตัว ktpass สั่งการ.
ด้วยการกำหนดค่านี้ ทุกอย่างทำงานได้ดีทั้งบน Edge และ Firefox บนเครื่อง Windows ใน MY.DOMAIN.TLD โดเมน.

ปัญหาของฉันมาจากไคลเอนต์ที่ใช้ Microsoft Edge (อันใหม่ที่มีเครื่องมือ Chromium) หรือ Google Chrome บนเครื่อง Windows นอกโดเมน

ในการเชื่อมต่อครั้งแรกกับ my.server.tldเบราว์เซอร์ได้รับ WWW-รับรองความถูกต้อง: เจรจาต่อรอง และ WWW-รับรองความถูกต้อง: Basic realm="SSO Authentication" ส่วนหัว

ด้วย Microsoft Edge ซึ่งแตกต่างจาก Firefox คือกล่องโต้ตอบการรับรองความถูกต้องที่ปรากฏขึ้น WWW-รับรองความถูกต้อง: เจรจาต่อรอง ไม่ใช่จากเบราว์เซอร์ แต่เป็นกล่องโต้ตอบการรับรองความถูกต้องของ Windows และใช้งานไม่ได้ ไม่ว่าเราจะพิมพ์อะไรก็ตาม

หลังจากพยายามเข้าสู่ระบบครั้งแรกไม่สำเร็จ เบราว์เซอร์ก็ส่งคำขอครั้งที่สอง และคราวนี้เขาได้รับเพียง WWW-รับรองความถูกต้อง: Basic realm="SSO Authentication" หัวข้อ. กล่องโต้ตอบการรับรองความถูกต้องของเบราว์เซอร์ปรากฏขึ้นและใช้งานได้ การนำทางเพิ่มเติมภายใน my.server.tld จากนั้นจะสร้างกล่องโต้ตอบการรับรองความถูกต้องของ Windows จำนวนมากในพื้นหลังตัวอย่างเช่น หากมีรูปภาพบนเพจ เพจนั้นจะแสดงกล่องโต้ตอบการตรวจสอบสิทธิ์สำหรับรูปภาพนั้น

ฉันสังเกตเห็นว่าหากเครื่อง Windows เชื่อมต่อกับเครือข่ายภายในของ MY.DOMAIN.TLD และเราระบุโดเมนอย่างชัดเจนในกล่องโต้ตอบการรับรองความถูกต้องของ Windows ซึ่งก็ใช้งานได้ดีเช่นกัน (เช่น [email protected] เป็นชื่อผู้ใช้)

ด้วยความคิดทั้งหมดข้างต้น ตอนนี้ฉันสงสัยว่า...

  • เป็นไปได้จริงหรือไม่ที่จะทำงานร่วมกับกล่องโต้ตอบการพิสูจน์ตัวจริงของ Windows แบบรวมบนเครื่อง Windows
  • มีวิธี "บังคับ" โดเมนที่จะใช้สำหรับการรับรองความถูกต้องหรือไม่ เพื่อลบล้างความจำเป็นในการระบุอย่างชัดเจนเช่น [email protected] สำหรับเครื่องนอก MY.DOMAIN.TLD โดเมน?

ฉันพยายามเพิ่มแล้ว default_domain = my.domain.tld ภายในการกำหนดค่า Kerberos realm หรือเพื่อรับ Kerberos TGT ด้วย กินิต บนเซิร์ฟเวอร์ Debian GNU/Linux 10 ไม่สำเร็จ

อ่านบันทึกของ Apache HTTP ด้วย การติดตาม LogLevel8 ในทุกสถานการณ์ ดูเหมือนว่าตราบใดที่กล่องโต้ตอบการรับรองความถูกต้องของ Windows ปรากฏขึ้น โทเค็น NTLM จะถูกส่งกลับ ซึ่งทำให้ทำงานไม่ถูกต้อง

เมื่อมันใช้งานได้

ทุกที่ที่มี Firefox
หรือ
ด้วยคอมพิวเตอร์ภายในโดเมน เครือข่ายภายใน (Edge หรือ Chrome)
หรือ
กับคอมพิวเตอร์นอกโดเมน เครือข่ายภายนอก และการใช้งาน [email protected] (ขอบหรือ Chrome):

mod_authz_core.c(820): AH01626: ผลการอนุญาตของ Require valid-user : ปฏิเสธ (ยังไม่มีผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์)
mod_authz_core.c(820): AH01626: ผลการอนุญาตของ <RequireAny>: ถูกปฏิเสธ (ยังไม่มีผู้ใช้ที่ผ่านการรับรองความถูกต้อง)
src/mod_auth_kerb.c(1963): kerb_authenticate_user ป้อนด้วยผู้ใช้ (NULL) และ auth_type Kerberos
src/mod_auth_kerb.c(1296): กำลังรับเครดิตสำหรับ HTTP/my.server.tld
src/mod_auth_kerb.c(1719): ตรวจสอบข้อมูลลูกค้าโดยใช้ KRB5 GSS-API
src/mod_auth_kerb.c(1735): ลูกค้าไม่ได้มอบสิทธิ์ให้เรา
src/mod_auth_kerb.c(1754): โทเค็น GSS-API ที่มีความยาว 180 ไบต์จะถูกส่งกลับ
mod_authz_core.c(820): AH01626: ผลการอนุญาตของ Require valid-user : อนุญาต
mod_authz_core.c(820): AH01626: ผลการอนุญาตของ <RequireAny>: อนุญาต

เมื่อมันไม่ได้ผล

ด้วยคอมพิวเตอร์นอกโดเมน เครือข่ายภายนอก (Edge หรือ Chrome):

mod_authz_core.c(820): AH01626: ผลการอนุญาตของ Require valid-user : ปฏิเสธ (ยังไม่มีผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์)
mod_authz_core.c(820): AH01626: ผลการอนุญาตของ <RequireAny>: ถูกปฏิเสธ (ยังไม่มีผู้ใช้ที่ผ่านการรับรองความถูกต้อง)
src/mod_auth_kerb.c(1963): kerb_authenticate_user ป้อนด้วยผู้ใช้ (NULL) และ auth_type Kerberos
src/mod_auth_kerb.c(1296): กำลังรับเครดิตสำหรับ HTTP/my.server.tld
src/mod_auth_kerb.c(1719): ตรวจสอบข้อมูลลูกค้าโดยใช้ KRB5 GSS-API
src/mod_auth_kerb.c(1735): ลูกค้าไม่ได้มอบสิทธิ์ให้เรา
src/mod_auth_kerb.c(1763): คำเตือน: โทเค็นที่ได้รับดูเหมือนว่าจะเป็น NTLM ซึ่งโมดูล Kerberos ไม่รองรับ ตรวจสอบการกำหนดค่า IE ของคุณ
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() ล้มเหลว: มีการร้องขอกลไกที่ไม่รองรับ (, ข้อผิดพลาดที่ไม่รู้จัก)

ส่วนที่น่ารำคาญของทั้งหมดนี้คือมันทำงานได้อย่างสมบูรณ์บน Firefox แต่ไม่ใช่เบราว์เซอร์ที่มีเครื่องยนต์ Chromium ล่าสุด เป็นเพราะกลับไปใช้การรับรองความถูกต้อง NTLM แทนแบบพื้นฐานหรือไม่

Score:1
ธง jp

ฉันอาจคิดผิด แต่สำหรับฉัน เนวิเกเตอร์จะส่งเฉพาะข้อมูลรับรอง Kerberos ไปยังไซต์ที่เชื่อถือได้เท่านั้น ดังนั้น สำหรับคอมพิวเตอร์ในโดเมน ระบบนำทางจะถือว่าเว็บเซิร์ฟเวอร์ของคุณเป็นไซต์ "อินทราเน็ต" (= เชื่อถือได้ = สามารถส่งข้อมูลประจำตัวได้)แต่สำหรับคนอื่น ๆ คำขอข้อมูลประจำตัวที่สร้างโดยเว็บเซิร์ฟเวอร์ของคุณจะถูกยกเลิก ดังนั้น บางทีการเพิ่ม FQDN ของเว็บเซิร์ฟเวอร์ของคุณในไซต์ที่เชื่อถือได้ของคอมพิวเตอร์ภายนอก มันจะทำเคล็ดลับได้หรือไม่

gb flag
ขอขอบคุณสำหรับเวลาของคุณ. เป็นความจริงที่ว่า `WWW-Authenticate: Negotiate` จะไม่ถูกส่งหากเว็บไซต์ไม่น่าเชื่อถือ อย่างไรก็ตาม การเพิ่ม `my.server.tld` ใน `network.negotiate-auth.trusted-uris` ใน Firefox (ตัวอย่าง) นั้น ไม่ช่วย แต่ฉันคิดว่าฉันพบปัญหาแล้ว... Kerberos ต้องการให้ไคลเอนต์เข้าถึงเซิร์ฟเวอร์ DC ซึ่งไม่ใช่กรณีของฉัน เมื่อสิ่งนี้เกิดขึ้น Firefox จะกลับไปใช้ Basic และใช้งานได้ แต่ Edge จะกลับไปใช้ NTLM และเราไม่ได้กำหนดค่า NTLM
cn flag
@kagmole: `Kerberos ต้องการให้ไคลเอนต์เข้าถึงเซิร์ฟเวอร์ DC ซึ่งไม่ใช่กรณีของฉัน' โทเค็น Kerberos ต้องสร้างโดย DC ดังนั้นจึงไม่มี Kerberos อะไรที่จะส่งจากไคลเอนต์ และมันจะไม่ตก กลับไปที่ NTLM นั่นเป็นเพียงโทเค็น หากบัญชีผู้ใช้ที่เข้าสู่ระบบอยู่ในโดเมน อาจพยายามส่งโทเค็น Kerberos แต่ถ้าไม่ใช่โดเมนเดียวกันหรือเป็นโดเมนที่เชื่อถือได้ ก็จะล้มเหลว
gb flag
@GregAskew ขอบคุณสำหรับข้อมูลเชิงลึกของคุณ ดังนั้นหากฉันเข้าใจถูกต้อง `KrbMethodK5Passwd` ยังคงเป็น "การตรวจสอบสิทธิ์ Kerberos" แต่ทำด้วยโทเค็น `Authorization Basic` หรือไม่
gb flag
@เลวร้ายที่สุดที่คุณพูดถูก ตอนนี้ฉันได้เพิ่ม `https://*.server.tld` ในอินทราเน็ตที่เชื่อถือได้ในตัวเลือกอินเทอร์เน็ต และใช้ได้กับ Google Chrome และ Microsoft Edge

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา