VPN-ээр дамжуулсан SQL Server яагаад одоо ч NTLM руу буцдаг вэ?

Kerberos-т зөв үйлчилгээний нэр, зөв бүртгэл дээрх SPN, клиентийн авч чадах тасалбар хэрэгтэй. Ямар нэгэн зүйлийг өөрчлөхөөс өмнө auth_scheme-г уншина уу.

Таны холболт ажиллаж, нэвтрэлт хүлээн авагдаж байхад бүгд Kerberos хүлээж байсан ч SQL Server NTLM ашиглаж байна. Энэ үр дүн VPN-ийн алдаа биш, учир нь туннель зөвхөн зам өгдөг; схемыг клиентийн хүссэн нэр, лавлахт бүртгэгдсэн үндсэн субъект болон клиентийн үнэхээр авч чадсан тасалбар тодорхойлсон. Гурван нөхцөл нэгэн зэрэг биелэх ёстой бөгөөд аль нь бууж өгснийг сесс өөрөө хэлнэ. Хэн нэгэн үйлчилгээний үндсэн нэрийг засахын өмнө үүнийг уншина уу.

Сесс таны үнэхээр авсан схемийг нэрлэнэ

Баталгаажуулалтын схем нь сервер эсвэл туннельд биш, холболтод хамаардаг тул шалгалтыг таны сонирхож буй сессийн дотор гүйцэтгэх ёстой. Доорх асуулгыг тайланг бүтээсэн ижил клиент, хэрэгсэл, бүртгэлээс гүйцэтгэж, үр дүнгийн хажууд зорилтот нэр болон тээврийг тэмдэглэнэ үү.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Өгөгдлийн сангийн хост дээрх локал SSMS цонхноос авсан мөр нь огт өөр холболтыг дүрсэлдэг тул асуулгыг клиентийн талаас гүйцэтгэх ёстой. Гаралтыг цагийн тэмдэгтэй хамт хадгална уу, учир нь үүнийг унших дараагийн хүн хэзээ авсныг асуух болно. Хэд хэдэн програм нэг төгсгөлийн цэгийг хуваалцаж байвал тус бүрээс дээж авна уу, учир нь хоёр програмын хоорондох өгөгдлийн эх сурвалжийн ялгаа ихэвчлэн бүх түүх байдаг.

Эхний нөхцөл: нэр SPN-тэй тохирч байна уу?

Kerberos нэрлэсэн үйлчилгээг баталгаажуулдаг тул клиент лавлахаас тодорхой нэг үндсэн субъектэд зориулсан тасалбар хүсдэг. TCP нийлүүлэгчийн хувьд баримтжуулсан хэлбэр нь MSSQLSvc/ бөгөөд дараа нь бүрэн мэргэшсэн хост нэр, анхдагч инстанцын хувьд порт орно. Нэрлэсэн инстанц MSSQLSvc/db01.corp.example:SQLPROD бүртгэдэг бөгөөд энд дагавар нь тооны оронд инстанцын нэр юм. Сонсогчид далд нэр, өөр газар шийдэгддэг CNAME эсвэл нүцгэн IP хаягаар хүрэх нь хүссэн нэрийг өөрчилдөг бөгөөд тохирох үндсэн субъектгүй хүсэлтэд буцаах тасалбар байхгүй.

Тиймээс нэг програм нэг сүлжээнд ажиллаад нөгөөд нь буцдаг: DNS хариулт, далд нэрийн бичлэг эсвэл hosts бичлэг клиентийн ашигласан нэрийг өөрчилсөн. Бүртгэлд хүрэхийн өмнө хүссэн нэрийг лавлахт байгаатай харьцуулна уу.

Хоёр дахь нөхцөл: SPN зөв бүртгэл дээр байна уу?

SPN нь SQL үйлчилгээг ажиллуулдаг бүртгэлд хамаарах ёстой, клиентийн бүртгэлд эсвэл санамсаргүйгээр компьютер объектод биш. SQL Server үйлчилгээний бүртгэлд тэдгээрийг бичих зөвшөөрөл байвал эхлэх үед өөрийн SPN-үүдийг бүртгэж чадна, энэ нь тохиромжтой бөгөөд үйлчилгээний бүртгэл солигдсоны дараа хуулбар хэрхэн үүсдэгийг ч тайлбарлана.

Лавлахаас хүлээж буй нэрийг асууж, дараа нь бүртгэл үнэхээр юу эзэмшиж байгааг жагсаана уу. Аль объект бичлэгийг барьж байгаа нь нэр ойд хаа нэгтээ байгаа эсэхээс илүү чухал. Зөрүү нь нэвтрэлт хэзээ ч асуудал байгаагүй гэсэн үг бөгөөд Microsoft-ын SPN гарын авлага форматууд болон домэйн администратор бичлэг үүсгэх ёстой тохиолдлуудыг баримтжуулдаг.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Өөр нэг бичлэг нэмэх нь аюулгүй туршилт биш. Хуулбар эсвэл зөрчилтэй бүртгэл ажиллаж байсан клиентүүдийг эвдэж болзошгүй тул өөрчлөлтийн өмнө эзэмшлийг шалгаж, дараа нь дахин шалгана уу.

Гурав дахь нөхцөл: клиент тасалбар авч чадах уу?

Клиент домэйны хянагч руу хүрч чадахгүй эсвэл ашиглах боломжтой итгэмжлэлийн контекстгүй бол зөв SPN нь утгагүй. Солилцоонд VPN-ээр дамжуулан KDC болон DNS хэрэгтэй бөгөөд зөвхөн SQL портыг чиглүүлдэг туннель яг энэ алхамд бүтэлгүйтдэг. Хүртээмжийг тэдний өмнөх галт ханын хаалтнаас биш, ижил машин болон ижил бүртгэлээс шалгах ёстой.

Тасалбарын кэшийг машин дээр болон програмыг ажиллуулж буй бүртгэлийн доор шалгана уу. Өргөмжлөгдсөн цонхноос авсан машины хэмжээний жагсаалт өөр хэрэглэгчээр ажиллаж буй үйлчилгээний талаар юу ч хэлэхгүй бөгөөд тухайн хэрэглэгчийн хоосон кэш нь тав тухгүй байдал биш, олдвор юм.

klist
klist -li 0x3e7

Дараа нь буцах зам юу хийж болохыг шийднэ үү. Бодлого Kerberos шаарддаг бол NTLM-ийг тодорхой татгалзах ёстой, учир нь чимээгүй буцалт нь тохиргооны алдааг шаардлагыг зөрчих ажилладаг холболт болгон хувиргадаг. NTLM зарим програмын хувьд хүлээн зөвшөөрөгдөх хэвээр байвал тэдгээрийг нэрлэж, NTLM сесс бүрийг осол гэж үзэхээ болино уу.

Эхлүүлэгчийг солих нь нэг хувьсагч, засвар биш

SSMS-ийг өөр итгэмжлэлээр эхлүүлэх нь санамсаргүй гадагшлах таних тэмдгийг эмчлэх боломжтой бөгөөд энэ нь асуудлын бодит ангилал юм. Энэ нь зорилтот нэр, бүртгэл эсвэл тасалбарын замын талаар юу ч нотлохгүй бөгөөд серверийн хүлээн авсныг өөрчлөхгүй.

Харьцуулалтыг хяналттай байлгана уу: ижил төгсгөлийн цэг, ижил нийлүүлэгч, мэдэгдэж буй гүйцэтгэлийн контекст, дараа нь схемийг нь шалгах шинэ холболт. Хүлээн авсан нэвтрэлт болон түүний өгөгдлийн сангийн эрхийг тус тусад нь баталгаажуулна уу, учир нь хандалт болон баталгаажуулалт өөр өөр шалтгаанаар бүтэлгүйтдэг.

Kerberos заавал байх ёстой үед эхний зам яагаад буцсаныг тэмдэглэж, нэг засвар хийж, асуулгыг ижил клиентээс дахин гүйцэтгэнэ үү. Эхлүүлэгч солигдсоны дараа амжилттай асуулга нь хандалтын нотолгоо бөгөөд баталгаажуулалтын шаардлага биелсэн гэсэн нотолгоо хараахан болохгүй.

Холбоотой нийтлэлүүд