VPN kết nối được nhưng SQL Server từ chối xác thực Windows

Đường hầm dựng lên, máy chủ trả lời ping, và đăng nhập cơ sở dữ liệu vẫn thất bại với lỗi xác thực. Sự kết hợp đó thường gặp trên các liên kết VPN và hiếm khi có nghĩa mạng bị hỏng, vì một trình lắng nghe truy cập được và một lần đăng nhập được chấp nhận là hai kết quả khác nhau. Danh tính làm hài lòng cổng kết nối không nhất thiết là danh tính mà máy khách cơ sở dữ liệu đưa ra. Xác định tài khoản nào đã đến chính là toàn bộ công việc.

Triệu chứng: máy chủ truy cập được, đăng nhập bị từ chối

Hết thời gian chờ cho bạn biết gói tin không bao giờ đến được trình lắng nghe. Lỗi xác thực cho bạn biết trình lắng nghe đã trả lời và từ chối thông tin đăng nhập. Hai thông báo đó đưa bạn đến những nhóm khác nhau, và trộn lẫn chúng tiêu tốn một ngày cho các quy tắc tường lửa vốn không bao giờ là vấn đề.

Khi lỗi là đăng nhập thất bại, hãy ngừng nhìn vào cổng. Câu hỏi còn lại là máy khách đã trình bày danh tính Windows nào, máy chủ có chấp nhận danh tính đó không, và nó có được phân giải thành người dùng cơ sở dữ liệu có quyền hay không.

Hai danh tính, một đường hầm

Tài khoản VPN xác thực tại cổng kết nối và trong hầu hết các triển khai dừng lại ở đó. Máy khách cơ sở dữ liệu trình bày riêng một token Windows, lấy từ tiến trình chạy nó, hoặc một đăng nhập SQL nếu chuỗi kết nối yêu cầu. Người dùng VPN cục bộ tại cổng kết nối không có quan hệ nào với miền lưu trữ SQL Server, và đường hầm không tạo ra quan hệ đó.

Kết nối máy cá nhân với VPN cũng không đưa nó vào miền. Đổi tên tài khoản cục bộ và khớp mật khẩu của nó với người dùng miền không phải là thủ tục gia nhập, và nó tạo ra một token mà bộ điều khiển miền sẽ không chấp nhận như người dùng đó.

Một số máy khách truy cập từ xa gốc của Windows có thể dùng lại thông tin đăng nhập VPN cho tài nguyên mạng khi hồ sơ của chúng được cấu hình như vậy. Hành vi đó thuộc về một máy khách và hồ sơ cụ thể, không phải các kết nối VPN nói chung, nên hãy xác minh cho máy khách đang dùng thay vì giả định.

Đọc chế độ mà máy khách yêu cầu

Chuỗi kết nối quyết định đường xác thực mà máy khách đi theo. Bảo mật tích hợp dùng token Windows; một cặp người dùng và mật khẩu chọn đăng nhập SQL. Đây là những chế độ riêng trong cấu hình máy chủ, và chỉ một trong số chúng có thể được bật cho một lần thử kết nối nhất định.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Chuyển sang đăng nhập SQL vì đăng nhập Windows thất bại là một cách lách che giấu câu hỏi danh tính, và nó thường vẫn đòi hỏi tạo đăng nhập và mật khẩu mới. Nếu triển khai yêu cầu xác thực Windows, hãy giữ chế độ và sửa đường danh tính. Đăng nhập SQL cũng cần quyền riêng, nên cách lách đó mua thêm một tài khoản để bảo trì.

Cũng xác nhận ứng dụng nào đang kết nối. Một dịch vụ chạy dưới tài khoản hệ thống, một tác vụ được lên lịch và một cửa sổ truy vấn tương tác có thể trình bày ba token khác nhau trên cùng một máy, và chỉ cái cuối cùng khớp với những gì người dùng thấy khi chạy whoami.

Hỏi máy chủ xem nó thực sự thấy gì

Máy chủ có thể cho bạn biết nó đã phân giải đăng nhập nào và kết nối đã xác thực ra sao. Chạy truy vấn bên trong phiên đang được điều tra, vì một kết nối thành công riêng của quản trị viên không chứng minh gì về máy khách đang thất bại.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Dòng đầu tiên phân biệt đăng nhập đã mở phiên với ngữ cảnh bảo mật đang có hiệu lực hiện tại, và hai thứ này khác nhau dưới mạo danh. Dòng thứ hai nêu tên lược đồ xác thực, nên KERBEROS, NTLM và SQL trở thành sự thật hữu hình thay vì phỏng đoán. Một kết nối báo NTLM ở nơi bạn mong đợi Kerberos là vấn đề phân giải tên hoặc SPN, không phải vấn đề mật khẩu.

Số lỗi thu hẹp thêm. Trạng thái 5 thường có nghĩa tên đăng nhập hoàn toàn không được phân giải, trạng thái 8 thường có nghĩa mật khẩu không khớp, và trạng thái 11 có nghĩa thông tin đăng nhập được chấp nhận nhưng truy cập máy chủ thất bại. Hãy hỏi quản trị viên trạng thái thay vì toàn bộ thông báo, vì chỉ thông báo thì cố ý mơ hồ.

Khi danh tính đến mà Kerberos vẫn thất bại

Nếu máy chủ thấy danh tính Windows dự kiến mà xác thực tích hợp vẫn thất bại, thì chính cuộc trao đổi là vấn đề. Kerberos cần tên gốc dịch vụ được đăng ký cho tài khoản dịch vụ SQL và một máy khách yêu cầu dịch vụ bằng tên khớp với nó. Kết nối bằng địa chỉ IP không thể khớp với SPN dựa trên tên, và một bí danh chỉ có thể khớp nếu nó cũng được đăng ký. Hãy kiểm tra trước hết tên mà máy khách đã nhập, vì một kết nối chạy được bằng tên máy chủ và thất bại bằng IP mô tả đúng vấn đề này.

Hãy đề nghị quản trị viên xem lại danh tính đã đăng ký và tài khoản dịch vụ thay vì tạo SPN trùng lặp bằng cách thử và sai. Đăng ký trùng lặp tạo ra những thất bại gián đoạn khó chẩn đoán hơn vấn đề ban đầu.

Sau khi xác thực hoạt động, đăng nhập vẫn cần một người dùng cơ sở dữ liệu và các quyền. Một lần đăng nhập VPN thành công, một lần đăng nhập Windows thành công và quyền đọc một bảng cụ thể là ba kết quả riêng biệt, và mỗi kết quả xứng đáng có kiểm tra riêng trước khi đóng phiếu.