- 24
- กรกฎาคม
"Windows ปิดทาง RC4 ถาวร ก.ค. 2569: ระบบที่ล็อกอินผ่าน Active Directory อาจล่มโดยไม่รู้ตัว" — คำตอบสั้นที่สุดคือ อัปเดต Windows ตั้งแต่กรกฎาคม 2569 ได้ลบ registry ที่เคยใช้เลื่อนการบังคับใช้ออกไป ทำให้ Domain Controller ออกตั๋ว Kerberos เป็น AES เท่านั้น ระบบใดที่ยังยืนยันตัวตนผ่าน Active Directory ด้วย keytab เก่าที่มีแต่คีย์ RC4 — โดยเฉพาะแอปบน Linux/Java ที่ผูกกับ AD — จะล็อกอินไม่ผ่านทันที บทความนี้อธิบายไทม์ไลน์ 3 ระยะ วิธีตรวจว่าบัญชีใดกำลังจะพัง วิธีสร้าง keytab ใหม่ให้รองรับ AES และเชื่อมโยงกับการวางระบบ ความปลอดภัยของ ERP ก่อนที่ระบบจะล่มโดยไม่รู้ตัว
สรุปบรรทัดเดียว: หลังอัปเดต Windows ก.ค. 2569 Domain Controller จะไม่ออกตั๋ว Kerberos ด้วย RC4 อีกต่อไป (แก้ CVE-2026-20833) — ตรวจ Event ID 201–209 บน DC และสร้าง keytab ใหม่ให้มีคีย์ AES ก่อน ไม่เช่นนั้นแอปที่ผูก AD จะล็อกอินไม่ผ่าน
เกิดอะไรขึ้นกับ RC4 บน Kerberos
Kerberos คือหัวใจของการยืนยันตัวตนบน Active Directory ทุกครั้งที่ผู้ใช้หรือบริการขอเข้าใช้ทรัพยากรในโดเมน Domain Controller (DC) จะออก "ตั๋ว" (ticket) ที่เข้ารหัสด้วยกุญแจของบัญชีปลายทาง อัลกอริทึมที่ใช้เข้ารหัสตั๋วนี้มีหลายชนิด และหนึ่งในนั้นคือ RC4-HMAC ซึ่งเป็นของเก่าตั้งแต่ยุค Windows 2000 ปัญหาคือ RC4 อ่อนแอเชิงคริปโต — คีย์ผูกกับแฮช NTLM ของรหัสผ่านโดยตรง ทำให้เสี่ยงต่อการโจมตีแบบ Kerberoasting และการถอดรหัสตั๋วแบบออฟไลน์
ช่องโหว่ที่จุดชนวนการเปลี่ยนแปลงรอบนี้คือ CVE-2026-20833 — ช่องโหว่ประเภท Kerberos information disclosure ที่เกี่ยวข้องกับการที่ DC ยังยอมออกตั๋วบริการด้วย RC4 Microsoft จึงตัดสินใจ "เลิกใช้ RC4 อย่างถาวร" สำหรับการออกตั๋วบัญชีบริการ และทยอยบังคับใช้เป็นระยะ จนถึงจุดที่ผู้ดูแลระบบไม่สามารถย้อนกลับได้อีกต่อไป
สิ่งที่ทำให้เรื่องนี้อันตรายกว่าแพตช์ทั่วไปคือ มันไม่ใช่ช่องโหว่ที่ "แก้แล้วจบ" แต่เป็นการ ปิดความสามารถ ที่หลายระบบยังพึ่งพาอยู่โดยไม่รู้ตัว — โดยเฉพาะอุปกรณ์และแอปที่ไม่ใช่ Windows ซึ่งตั้งค่า Kerberos ไว้นานหลายปีและไม่เคยแตะอีกเลย
ไทม์ไลน์ 3 ระยะ: จากเตือนสู่บังคับถาวร
Microsoft ไม่ได้ปิด RC4 ในชั่วข้ามคืน แต่แบ่งการบังคับใช้ออกเป็น 3 ระยะเพื่อให้องค์กรมีเวลาปรับตัว ปัญหาคือหลายองค์กรมองข้ามสองระยะแรกเพราะ "ระบบยังใช้งานได้ปกติ" จนมาสะดุดที่ระยะสุดท้ายซึ่งย้อนกลับไม่ได้
| วันที่ | ระยะ | พฤติกรรมของ DC | ย้อนกลับได้? |
|---|---|---|---|
| 13 ม.ค. 2569 | ระยะที่ 1 — Audit | ยังออกตั๋ว RC4 ตามปกติ แต่เริ่มบันทึกคำเตือน (audit warning) ลง Event Log ทุกครั้งที่มีการใช้ RC4 | ได้ (ปรับพฤติกรรมได้เต็มที่) |
| 14 เม.ย. 2569 | ระยะที่ 2 — เปลี่ยนค่าเริ่มต้น | ค่าเริ่มต้นเปลี่ยนเป็น AES-SHA1 DC เลิกออก RC4 โดยปริยาย แต่ผู้ดูแลยังตั้ง registry ย้อนกลับมาใช้ RC4 ได้ | ยังได้ (ผ่าน registry) |
| ก.ค. 2569 | ระยะสุดท้าย — Enforcement | อัปเดต Windows ลบ registry subkey RC4DefaultDisablementPhase ทิ้ง เหลือเพียง Enforcement mode — DC ไม่ออกตั๋ว RC4 อีกต่อไป | ไม่ได้ |
คำเตือน: จุดที่หลายองค์กรพลาดคือระยะที่ 2 — เมื่อระบบยังทำงานได้เพราะมีคนไปตั้ง registry ย้อนกลับมาใช้ RC4 (เป็น "ปุ่มหน่วงเวลา") พอถึงระยะสุดท้าย ปุ่มนั้นถูกลบทิ้ง ระบบที่ "ยังใช้ RC4 อยู่ดี" จึงล่มทันทีในวันที่อัปเดต โดยไม่มีสัญญาณเตือนล่วงหน้าถ้าไม่ได้ดู Event Log
ใครจะพัง และอาการเป็นอย่างไร
ระบบ Windows ที่เข้าโดเมนปกติมักรองรับ AES อยู่แล้ว จึงไม่ค่อยได้รับผลกระทบ กลุ่มที่เสี่ยงสูงสุดคือ อุปกรณ์และบริการที่ไม่ใช่ Windows ซึ่งใช้ Kerberos keytab เก่าที่มีเฉพาะคีย์ RC4 หรือบัญชีบริการที่ตั้ง flag บังคับให้ใช้ RC4 ไว้
| ประเภทระบบ | อาการที่พบ | แนวทางแก้ |
|---|---|---|
| แอป Linux/Java ที่ทำ SSO กับ AD (Kerberos/SPNEGO) | ผู้ใช้ล็อกอินไม่ได้ ขึ้น KRB_AP_ERR_MODIFIED หรือ KDC has no support for encryption type | สร้าง keytab ใหม่ที่มีคีย์ AES256/AES128 |
| NAS / เครื่องพิมพ์ / อุปกรณ์เครือข่ายที่ join AD | เข้าแชร์ไฟล์หรือยืนยันตัวตนไม่ได้หลังอัปเดต DC | อัปเดตเฟิร์มแวร์ให้รองรับ AES แล้ว re-join โดเมน |
| บัญชีบริการที่ตั้ง "This account supports Kerberos AES" ไม่ครบ | ตั๋วบริการออกไม่สำเร็จ แอปฝั่ง back-end ล้มเป็นลูกโซ่ | ติ๊ก AES128/AES256 ใน msDS-SupportedEncryptionTypes แล้ว reset password |
| Trust ระหว่างโดเมน (cross-realm) ที่ตั้งเป็น RC4 | ผู้ใช้ต่างโดเมนเข้าถึงทรัพยากรข้ามโดเมนไม่ได้ | ปรับ trust ให้รองรับ AES ทั้งสองฝั่ง |
เทียบชนิดการเข้ารหัส: RC4-HMAC vs AES
เพื่อเข้าใจว่าทำไม AES ถึงจำเป็น มาดูความต่างของแต่ละ encryption type ที่ Kerberos ใช้ ตัวเลข etype ในวงเล็บคือรหัสที่จะเห็นใน log และเครื่องมือ klist
| คุณสมบัติ | RC4-HMAC (etype 23) | AES128 (17) / AES256 (18) |
|---|---|---|
| ความแข็งแรงเชิงคริปโต | อ่อน (อัลกอริทึม stream cipher ยุคเก่า) | แข็งแรง มาตรฐานปัจจุบัน |
| ที่มาของคีย์ | ผูกกับแฮช NTLM ของรหัสผ่านตรง ๆ | ผ่าน salt + PBKDF2 (แข็งกว่ามาก) |
| เสี่ยง Kerberoasting | สูง — ถอดออฟไลน์ได้ง่าย | ต่ำ |
| สถานะหลัง ก.ค. 2569 | DC ไม่ออกตั๋วให้แล้ว | ค่าเริ่มต้นและบังคับใช้ |
ตรวจก่อนพัง: ดู Event ID 201–209 บน Domain Controller
ข่าวดีคือ DC บันทึกทุกครั้งที่มีการใช้ RC4 ลง System event log อยู่แล้ว (source: Microsoft-Windows-Kerberos-Key-Distribution-Center) ทำให้ตรวจได้ล่วงหน้าว่าบัญชีใดจะพัง โดยดู Event ID ในช่วง 201–209 เหตุการณ์เหล่านี้จะระบุชื่อบัญชีที่ยังขอตั๋วด้วย RC4
วิธีดึงเหตุการณ์ด้วย PowerShell บน DC:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
Id = 201,202,203,204,205,206,207,208,209
} -MaxEvents 200 | Format-Table TimeCreated, Id, Message -AutoSizeให้รันบน DC ทุกตัว (เพราะ log ไม่รวมศูนย์) แล้วรวบรวมชื่อบัญชีที่ปรากฏ นั่นคือรายการที่ต้องแก้ก่อนถึงระยะ Enforcement การเฝ้าดู log แบบนี้เป็นหลักการเดียวกับที่เราแนะนำในบทความเรื่อง Disaster Recovery ที่ทุกองค์กรต้องมี — คือรู้ปัญหาก่อนระบบล่ม ไม่ใช่หลังจากล่มแล้ว
Checklist ก่อนอัปเดต: คำสั่งตรวจ keytab และ encryption type
| คำสั่ง | ตรวจอะไร |
|---|---|
klist -e -k -t /etc/krb5.keytab | ลิสต์ทุก entry ใน keytab พร้อม encryption type — ถ้าเห็นแต่ arcfour-hmac (RC4) คือกำลังจะพัง |
Get-ADUser svc_app -Properties msDS-SupportedEncryptionTypes | ดูว่าบัญชีบริการติ๊กรองรับ AES หรือยัง (ค่า 24 = AES128+AES256) |
klist -e (หลังล็อกอิน) | ดู etype ของตั๋วที่ได้จริง — ควรเป็น aes256-cts ไม่ใช่ arcfour |
kinit -k -t /etc/krb5.keytab HTTP/app.example.com | ทดสอบขอตั๋วด้วย keytab จริง — ถ้าได้ตั๋วแปลว่า keytab ใช้งานได้กับ enforcement mode |
สร้าง keytab ใหม่ให้รองรับ AES
เมื่อพบว่า keytab มีแต่คีย์ RC4 ทางแก้คือ regenerate ใหม่ให้มีคีย์ AES วิธีทำต่างกันตามฝั่ง
ฝั่ง Windows (ktpass): รันบน DC หรือเครื่องที่มี RSAT ตัวอย่างสำหรับบัญชีบริการ svc_app:
ktpass -princ HTTP/app.example.com@EXAMPLE.COM ^
-mapuser svc_app ^
-crypto AES256-SHA1 ^
-ptype KRB5_NT_PRINCIPAL ^
-pass * ^
-out app-aes.keytabคำสั่งนี้จะ reset รหัสผ่านบัญชีและสร้าง keytab ที่มีคีย์ AES256 นำ app-aes.keytab ไปแทนที่ไฟล์เดิมบนเซิร์ฟเวอร์ปลายทาง
ฝั่ง Linux (MIT ktutil): ถ้าต้องเพิ่ม entry AES เข้า keytab เดิม
ktutil
ktutil: addent -password -p HTTP/app.example.com@EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96
ktutil: addent -password -p HTTP/app.example.com@EXAMPLE.COM -k 1 -e aes128-cts-hmac-sha1-96
ktutil: wkt /etc/krb5.keytab
ktutil: quitจากนั้นทดสอบด้วย kinit -k -t /etc/krb5.keytab HTTP/app.example.com แล้ว klist -e เพื่อยืนยันว่าได้ตั๋วเป็น aes256-cts จริง
เคล็ดลับ: ควรใส่ทั้ง AES256 และ AES128 ลง keytab เพื่อความเข้ากันได้ และอย่าลืมว่าทุกครั้งที่ ktpass หรือ reset รหัสผ่าน จะทำให้ kvno (key version number) เพิ่มขึ้น — ต้องแจกจ่าย keytab เวอร์ชันใหม่ให้ทุกโหนดที่ใช้ principal เดียวกัน มิฉะนั้นจะเจอ KRB_AP_ERR_MODIFIED
ห้ามทำ: อย่า "แก้ปัญหา" ด้วยการตั้ง registry ย้อนกลับไปใช้ RC4 บน DC เพื่อยื้อเวลา หลังอัปเดต ก.ค. 2569 subkey นั้นถูกลบและไม่มีผลอีกแล้ว การพยายามฝืนจะทำให้ระบบเปิดช่องโหว่ CVE-2026-20833 กลับมาโดยไม่ได้ประโยชน์ ทางที่ถูกคือย้ายไป AES ให้ครบทุกจุด
เชื่อมโยงกับระบบ ERP ที่ผูกล็อกอินกับ AD
องค์กรจำนวนมากเชื่อมระบบ ERP เข้ากับ Active Directory เพื่อให้พนักงานใช้บัญชีเดียว (Single Sign-On) การเปลี่ยนแปลงรอบนี้จึงกระทบ ERP ที่รันบน Linux/Java และทำ Kerberos SSO โดยตรง หาก keytab ที่ ERP ใช้มีแต่คีย์ RC4 ผู้ใช้อาจล็อกอินเข้าระบบไม่ได้ในวันที่อัปเดต DC — กระทบทั้งการปิดงบ การอนุมัติเอกสาร และงานประจำวัน
สำหรับ Saeree ERP เราแนะนำให้ตรวจ keytab และ encryption type ของทุกจุดที่ผูกกับ AD ก่อนอัปเดต Windows เสมอ และหากองค์กรต้องการลดการพึ่งพา AD ในการยืนยันตัวตน Saeree ERP รองรับการ บริหารสิทธิ์ผู้ใช้ในระบบเองได้โดยผู้ดูแลขององค์กร — เพิ่มผู้ใช้ ตั้ง inactive หรือกำหนดช่วงเวลาใช้งาน (valid from–to) ได้เอง ทำให้มีทางเลือกในการควบคุมการเข้าถึง ไม่ผูกกับกลไกภายนอกทั้งหมด สอดคล้องกับแนวทางเสริมความปลอดภัยแบบ การยืนยันตัวตนสองชั้น (2FA) ที่เราใช้กับระบบจริง ดูภาพรวมทั้งหมดได้ที่หน้า เทคโนโลยีและความปลอดภัย
ประเด็นสำคัญคือ นี่ไม่ใช่ปัญหาของ ERP โดยตรง แต่เป็นการเปลี่ยนแปลงระดับโครงสร้างพื้นฐาน (Active Directory) ที่ระบบใด ๆ ก็ตามที่พึ่งพา AD ต้องเตรียมตัว การวางแผนล่วงหน้าและตรวจ Event Log จึงเป็นวิธีที่ปลอดภัยที่สุด
"การเลิกใช้ RC4 ไม่ใช่แพตช์ที่แก้แล้วจบ แต่เป็นการปิดประตูที่หลายระบบยังยืนอยู่ข้างหลังโดยไม่รู้ตัว องค์กรที่ตรวจ Event Log และย้ายไป AES ก่อน คือองค์กรที่จะไม่ตื่นมาเจอระบบล่มในเช้าวันจันทร์"
- ทีมความปลอดภัย Saeree ERP
แหล่งอ้างอิง
กังวลว่าระบบที่ผูก Active Directory จะได้รับผลกระทบ?
สนใจระบบ ERP สำหรับองค์กรของคุณ? ทีมงาน Saeree ERP ช่วยตรวจ keytab, encryption type และการเชื่อมต่อ AD ของระบบ ERP ก่อนอัปเดต Windows พร้อมวางแนวทางย้ายไป AES อย่างปลอดภัย
ปรึกษาผู้เชี่ยวชาญโทร 02-347-7730 | sale@grandlinux.com
