Vì sao SQL Server qua VPN vẫn rơi về NTLM?

Kết nối của bạn hoạt động, đăng nhập được chấp nhận và SQL Server đang dùng NTLM trong khi mọi người chờ đợi Kerberos. Kết quả đó không phải lỗi VPN, vì đường hầm chỉ cung cấp một đường đi; lược đồ do tên mà máy khách yêu cầu, chủ thể được đăng ký trong thư mục và vé mà máy khách thực sự lấy được quyết định. Ba điều kiện phải cùng đúng một lúc, và chính phiên cho biết điều kiện nào đã nhường. Hãy đọc điều đó trước khi ai đó sửa tên chủ thể dịch vụ.

Phiên nêu tên lược đồ bạn thực sự nhận được

Lược đồ xác thực thuộc về một kết nối chứ không phải máy chủ hay đường hầm, nên việc kiểm tra phải chạy bên trong phiên mà bạn quan tâm. Chạy truy vấn dưới đây từ đúng máy khách, công cụ và tài khoản đã tạo báo cáo, và ghi tên đích cùng phương thức truyền bên cạnh kết quả.

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

Một dòng từ cửa sổ SSMS cục bộ trên máy chủ cơ sở dữ liệu mô tả một kết nối hoàn toàn khác, nên truy vấn phải chạy từ phía máy khách. Lưu kết quả với dấu thời gian, vì người tiếp theo đọc nó sẽ hỏi nó được lấy khi nào. Khi nhiều ứng dụng dùng chung một điểm cuối, hãy lấy mẫu từ từng ứng dụng, vì sự khác biệt về nguồn dữ liệu giữa hai ứng dụng thường là toàn bộ câu chuyện.

Điều kiện một: tên có khớp với SPN không?

Kerberos xác thực một dịch vụ có tên, nên máy khách yêu cầu thư mục cấp vé cho một chủ thể cụ thể. Với nhà cung cấp TCP, dạng được ghi nhận là MSSQLSvc/ theo sau là tên máy chủ đủ điều kiện và, với phiên bản mặc định, cổng. Phiên bản có tên đăng ký MSSQLSvc/db01.corp.example:SQLPROD, trong đó hậu tố là tên phiên bản thay vì một số. Tiếp cận trình lắng nghe qua bí danh, một CNAME được phân giải ở nơi khác hoặc địa chỉ IP trần sẽ thay đổi tên được yêu cầu, và một yêu cầu không có chủ thể khớp thì không có vé để trả lại.

Đó là lý do một ứng dụng hoạt động trên mạng này và rơi lại trên mạng khác: câu trả lời DNS, bản ghi bí danh hoặc mục hosts đã thay đổi tên mà máy khách dùng. So sánh tên được yêu cầu với những gì thư mục lưu giữ trước khi chạm vào đăng ký.

Điều kiện hai: SPN có trên đúng tài khoản không?

SPN phải thuộc về tài khoản chạy dịch vụ SQL, không phải tài khoản của máy khách và cũng không phải một đối tượng máy tính một cách tình cờ. SQL Server có thể đăng ký SPN của chính nó khi khởi động nếu tài khoản dịch vụ có quyền ghi chúng, điều này tiện lợi và cũng giải thích cách một bản trùng xuất hiện sau khi thay đổi tài khoản dịch vụ.

Hỏi thư mục về tên bạn mong đợi, sau đó liệt kê những gì tài khoản thực sự sở hữu. Đối tượng nào giữ mục nhập quan trọng hơn việc tên có tồn tại ở đâu đó trong rừng hay không. Sự không khớp nghĩa là đăng nhập chưa bao giờ là vấn đề, và hướng dẫn SPN của Microsoft ghi lại các dạng và các trường hợp quản trị viên miền phải tạo mục nhập.

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

Thêm một mục nhập khác không phải là thử nghiệm an toàn. Một bản trùng hoặc đăng ký xung đột có thể làm hỏng những máy khách đang hoạt động, nên hãy kiểm tra quyền sở hữu trước khi thay đổi và kiểm tra lại sau đó.

Điều kiện ba: máy khách có lấy được vé không?

Một SPN đúng là vô dụng nếu máy khách không thể tiếp cận bộ điều khiển miền hoặc không có ngữ cảnh thông tin xác thực dùng được. Việc trao đổi cần KDC và DNS qua VPN, và một đường hầm chỉ định tuyến cổng SQL sẽ thất bại đúng ở bước này. Khả năng tiếp cận phải được kiểm tra từ cùng máy và cùng tài khoản, không phải từ tường lửa phía trước chúng.

Kiểm tra bộ nhớ đệm vé trên máy và dưới tài khoản chạy ứng dụng. Một danh sách toàn máy từ cửa sổ nâng cao không nói gì về dịch vụ chạy dưới người dùng khác, và bộ nhớ đệm trống cho người dùng đó là một phát hiện chứ không phải bất tiện.

klist
klist -li 0x3e7

Sau đó quyết định việc rơi lại được phép làm gì. Nếu chính sách yêu cầu Kerberos, NTLM phải bị từ chối rõ ràng, vì một lần rơi lại âm thầm biến lỗi cấu hình thành kết nối hoạt động vi phạm yêu cầu. Nếu NTLM vẫn chấp nhận được cho một số ứng dụng, hãy nêu tên chúng và ngừng coi mọi phiên NTLM là sự cố.

Đổi trình khởi chạy là một biến số, không phải bản sửa

Khởi chạy SSMS dưới thông tin xác thực khác có thể chữa một danh tính gửi đi ngoài ý muốn, đây là một lớp vấn đề thực sự. Nó không chứng minh gì về tên đích, đăng ký hay đường đi của vé, và không thay đổi những gì máy chủ đã chấp nhận.

Giữ phép so sánh trong tầm kiểm soát: cùng điểm cuối, cùng nhà cung cấp, ngữ cảnh thực thi đã biết, sau đó là một kết nối mới mà bạn kiểm tra lược đồ. Xác nhận riêng đăng nhập được chấp nhận và quyền cơ sở dữ liệu của nó, vì truy cập và xác thực thất bại vì những lý do khác nhau.

Khi Kerberos là bắt buộc, hãy ghi lại vì sao đường đầu tiên rơi lại, áp dụng một bản sửa và chạy lại truy vấn từ cùng máy khách. Một truy vấn thành công sau khi đổi trình khởi chạy là bằng chứng về truy cập, và nó chưa phải bằng chứng rằng yêu cầu xác thực đã được đáp ứng.