Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Cách khắc phục thông báo lỗi "Không thể tạo ngữ cảnh SSPI"

Hỗ trợ cho Windows Server 2003 đã kết thúc vào ngày 14 tháng 7 năm 2015

Microsoft đã kết thúc hỗ trợ cho Windows Server 2003 vào ngày 14 tháng 7 năm 2015. Thay đổi này đã ảnh hưởng đến các bản cập nhật phần mềm và tùy chọn bảo mật của bạn. Tìm hiểu ý nghĩa của điều này với bạn và cách thực hiện để luôn được bảo vệ.

TÓM TẮT
Bài viết từng bước này mô tả cách khắc phục sự cố cho các nguồn điển hình nhất của thông báo lỗi "Không thể tạo ngữ cảnh SSPI". Bạn có thể nhận được thông báo lỗi này trong các điều kiện sau:
  • Bạn đang kết nối với SQL Server.
  • Bạn đang sử dụng tính năng Bảo mật Tích hợp.
  • Kerberos được sử dụng để thực hiện uỷ nhiệm bảo mật.

Hiểu thuật ngữ Kerberos và Tên Cơ bản của Dịch vụ

Trình điều khiển SQL Server trên máy khách sử dụng tính năng bảo mật tích hợp để sử dụng mã thông báo bảo mật Windows của tài khoản người dùng để kết nối thành công với máy tính đang chạy SQL Server. Mã thông báo bảo mật Windows được uỷ nhiệm từ máy khách sang máy tính đang chạy SQL Server. Trình điều khiển SQL Server thực hiện quá trình uỷ nhiệm này khi mã thông báo bảo mật của người dùng được uỷ nhiệm từ một máy tính sang máy tính khác bằng cách sử dụng một trong những cấu hình sau:
  • NTLM qua Đường ống được Đặt tên (không sử dụng Giao diện Security Support Provider [SSPI])
  • NTLM qua khe cắm TCP/IP với SSPI
  • Kerberos qua khe cắm TCP/IP với SSPI
Giao diện Security Support Provider (SSPI) là một nhóm API trong Windows cho phép uỷ nhiệm và xác thực tương hỗ qua bất kỳ lớp truyền tải dữ liệu chung nào, chẳng hạn như khe cắm TCP/IP. Do đó, SSPI cho phép máy tính đang chạy hệ điều hành Windows uỷ nhiệm an toàn mã thông báo bảo mật của người dùng từ một máy tính sang máy tính khác qua bất kỳ lớp truyền tải nào có thể truyền các byte dữ liệu chưa qua xử lý.

Lỗi "Không thể tạo ngữ cảnh SSPI" xuất hiện khi SSPI sử dụng Kerberos để uỷ nhiệm qua TCP/IP và Kerberos không thể hoàn thành các thao tác cần thiết để uỷ nhiệm thành công mã thông báo bảo mật của người dùng cho máy tính đích đang chạy SQL Server.

Lý do Giao diện Security Support Provider chọn NTLM hoặc Kerberos

Kerberos sử dụng mã nhận dạng có tên "Tên Cơ bản của Dịch vụ" (SPN). Coi SPN là một miền hoặc mã nhận dạng duy nhất của nhóm của phiên bản nào đó trong tài nguyên máy chủ mạng. Bạn có thể có một SPN cho một dịch vụ Web, một dịch vụ SQL hoặc một dịch vụ SMTP. Bạn cũng có thể có nhiều phiên bản dịch vụ Web trên cùng một máy tính thực có SPN duy nhất.

Một SPN cho SQL Server bao gồm các phần tử sau:
  • ServiceClass: Phần tử này xác định hạng dịch vụ chung. Phần tử này luôn là MSSQLSvc dành cho SQL Server.
  • Host: Phần tử này là DNS tên miền đủ điều kiện của máy tính đang chạy SQL Server.
  • Port: Phần tử này là số cổng mà dịch vụ đang kết nối.
Ví dụ: SPN thông thường cho máy tính đang chạy SQL Server là:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Định dạng của SPN cho phiên bản mặc định và định dạng của SPN cho phiên bản có tên không khác nhau. Số cổng là phần tử liên kết SPN với một phiên bản cụ thể.

Khi Trình điều khiển SQL Server trên máy khách sử dụng tính năng bảo mật tích hợp để kết nối với SQL Server, mã trình điều khiển trên máy khách cố xử lý DNS đủ điều kiện của máy tính đang chạy SQL Server bằng cách sử dụng API kết nối mạng WinSock. Để thực hiện thao tác này, mã trình điều khiển gọi các API WinSock gethostbyname và gethostbyaddr. Ngay cả khi địa chỉ IP hoặc tên máy chủ được truyền ở dạng tên máy tính đang chạy SQL Server, trình điều khiển SQL Server cố xử lý DNS đủ điều kiện của máy tính nếu máy tính đang sử dụng tính năng bảo mật tích hợp.

Khi trình điều khiển SQL Server trên máy khách xử lý DNS đủ điều kiện của máy tính đang chạy SQL Server thì DNS tương ứng được sử dụng để tạo SPN cho máy tính này. Do đó, mọi sự cố liên quan đến việc địa chỉ IP hay tên máy chủ được xử lý thành DNS đủ điều kiện bởi WinSock có thể khiến trình điều khiển SQL Server tạo một SPN không hợp lệ cho máy tính đang chạy SQL Server.

Ví dụ: SPN không hợp lệ mà trình điều khiển SQL Server phía máy khách có thể tạo ở dạng DNS đủ điều kiện được xử lý là:
  • MSSQLSvc/SQLSERVER1:1433
  • MSSQLSvc/123.123.123.123:1433
  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
  • MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Khi trình điều khiển SQL Server tạo SPN không hợp lệ, quá trình xác thực vẫn hoạt động vì giao diện SSPI cố tìm kiếm SPN trong dịch vụ thư mục Active Directory và không tìm thấy SPN. Nếu giao diện SSPI không tìm thấy SPN, quá trình xác thực Kerberos không được thực hiện. Khi đó, lớp SSPI chuyển thành chế độ xác thực NTLM và quá trình đăng nhập sử dụng xác thực NTLM và thường thành công. Nếu trình điều khiển SQL Server tạo SPN hợp lệ nhưng không được gán cho vùng chứa thích hợp, trình điều khiển này cố sử dụng SPN nhưng không thể, dẫn đến thông báo lỗi "Không thể tạo ngữ cảnh SSPI". Nếu tài khoản khởi động SQL Server là tài khoản hệ thống cục bộ thì vùng chứa thích hợp là tên máy tính. Đối với bất kỳ tài khoản khác nào, vùng chứa thích hợp là tài khoản khởi động SQL Server. Vì quá trình xác thực sẽ cố sử dụng SPN đầu tiên mà nó tìm thấy nên hãy đảm bảo rằng không có SPN nào được gán cho vùng chứa không thích hợp. Nói cách khác, mỗi SPN phải được gán cho một và chỉ một vùng chứa.

Yếu tố chính giúp cho quá trình xác thực Kerberos thành công là chức năng DNS hợp lệ trên mạng. Bạn có thể kiểm tra chức năng này trên máy khách và máy chủ bằng cách sử dụng tiện ích dòng lệnh Ping. Trên máy khách, hãy chạy lệnh sau để lấy địa chỉ IP của máy chủ đang chạy SQL Server (nơi mà tên máy tính đang chạy SQL Server là SQLServer1):
ping sqlserver1
Để biết liệu tiện ích dòng lệnh Ping có xử lý DNS đủ điều kiện của SQLServer1 hay không, hãy chạy lệnh sau:
ping -a IPAddress
Ví dụ:
C:\>ping SQLSERVER1Ping SQLSERVER1 [123.123.123.123] với 32 byte dữ liệu:	Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128	Thống kê ping cho 123.123.123.123: Gói tin: Đã gửi = 4, Đã nhận = 4, Đã mất = 0 (0% mất), Thời gian của quá trình hồi đáp xấp xỉ tính bằng mili giây: Tối thiểu = 0ms, Tối đa = 0ms, Trung bình = 0ms
C:\>ping -a 123.123.123.123	Ping SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] với 32 byte dữ liệu:	Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Trả lời từ 123.123.123.123: bytes=32 time<10ms TTL=128 Thống kê ping cho 123.123.123.123: Gói tin: Đã gửi = 4, Đã nhận = 4, Đã mất = 0 (0% mất), Thời gian của quá trình hồi đáp xấp xỉ tính bằng mili giây: Tối thiểu = 0ms, Tối đa = 0ms, Trung bình = 0msC:\>
Khi lệnh ping -a IPAddress xử lý thành DNS đúng, đủ điều kiện của máy tính đang chạy SQL Server thì giải pháp phía máy chủ cũng thành công.

Tạo Tên Cơ bản của Dịch vụ SQL Server

Đây là một trong những phần quan trọng trong tương tác Kerberos và SQL Server. Với SQL Server, bạn có thể chạy dịch vụ SQL Server ở một trong những điều kiện sau: tài khoản LocalSystem, tài khoản người dùng cục bộ hay tài khoản người dùng trong miền. Khi phiên bản dịch vụ SQL Server khởi động, nó cố đăng ký SPN riêng của mình trong Active Directory bằng cách sử dụng lệnh gọi API DsWriteAccountSpn. Nếu lệnh gọi không thành công, cảnh báo sau được ghi trong Trình xem Sự kiện:

Nguồn: MSSQLServer EventID: Mô tả 19011: Thông tin SuperSocket: (SpnRegister) : Lỗi 8344.

Để biết thêm thông tin về chức năng DsWriteAccountSpn, hãy truy nhập Web site sau của Microsoft:

Simplified explanation

Nếu bạn chạy dịch vụ SQL Server trong tài khoản LocalSystem thì SPN được tự động đăng ký và Kerberos tương tác thành công với máy tính đang chạy SQL Server. Tuy nhiên, nếu bạn chạy dịch vụ SQL Server trong tài khoản miền hoặc trong tài khoản cục bộ thì nỗ lực tạo SPN sẽ không thành công trong hầu hết các trường hợp vì tài khoản miền và tài khoản cục bộ không có quyền đặt SPN riêng của chúng. Khi quá trình tạo SPN không thành công, điều này nghĩa là không có SPN nào được thiết lập cho máy tính đang chạy SQL Server. Nếu bạn kiểm tra bằng tài khoản quản trị viên trong miền làm tài khoản dịch vụ SQL Server thì SPN được tạo thành công vì uỷ nhiệm cấp quản trị viên trong miền mà bạn phải có để tạo SPN đang có sẵn.

Vì bạn có thể không sử dụng tài khoản quản trị viên trong miền để chạy dịch vụ SQL Server (để ngăn rủi ro về bảo mật) nên máy tính đang chạy SQL Server không thể tạo SPN riêng của nó. Do đó, bạn phải tạo thủ công SPN cho máy tính đang chạy SQL Server nếu bạn muốn sử dụng Kerberos khi bạn kết nối với máy tính đang chạy SQL Server. Điều này đúng nếu bạn đang chạy SQL Server trong tài khoản người dùng trong miền hoặc trong tài khoản người dùng cục bộ. SPN mà bạn tạo phải được gán cho tài khoản dịch vụ của dịch vụ SQL Server trên máy tính cụ thể đó. Không thể gán SPN cho vùng chứa máy tính trừ khi máy tính đang chạy SQL Server khởi động bằng hệ thống cục bộ. Phải có một và duy nhất một SPN và SPN này phải được gán cho vùng chứa thích hợp. Thường thì đây là tài khoản dịch vụ hiện tại của SQL Server. Tuy nhiên, đây là tài khoản máy tính có hệ thống cục bộ.

Kiểm tra miền

Kiểm tra xem miền mà bạn đăng nhập có thể giao tiếp với miền có máy tính đang chạy SQL Server hay không. Cũng phải có giải pháp tên hợp lý trong miền.
  1. Bạn phải đảm bảo rằng bạn có thể đăng nhập thành công vào Windows bằng cách sử dụng cùng tài khoản miền và mật khẩu làm tài khoản khởi động của dịch vụ SQL Server. Ví dụ: lỗi SSPI có thể xảy ra ở một trong các trường hợp sau:
    • Tài khoản miền bị khoá.
    • Mật khẩu của tài khoản được thay đổi. Tuy nhiên, bạn không bao giờ khởi động lại dịch vụ SQL Server sau khi mật khẩu được thay đổi.
  2. Nếu miền đăng nhập của bạn khác với miền của máy tính đang chạy SQL Server, hãy kiểm tra mối quan hệ tin cậy giữa các miền.
  3. Kiểm tra xem miền chứa máy chủ và tài khoản miền mà bạn sử dụng để kết nối có cùng một nhóm hay không. Điều này là bắt buộc để SSPI hoạt động.
  4. Sử dụng tuỳ chọn Tài khoản được Tin cậy để Uỷ nhiệm trong Người dùng và Máy tính của Active Directory khi bạn khởi động SQL Server.

    Chú ý Quyền 'Tài khoản được Tin cậy để Uỷ nhiệm' chỉ bắt buộc khi bạn đang uỷ nhiệm uỷ quyền từ máy chủ SQL đích sang máy chủ SQL từ xa, chẳng hạn như trong tình huống xác thực kép, giống như các truy vấn đã phân phối (truy vấn máy chủ được liên kết) sử dụng xác thực Windows.
  5. Sử dụng tiện ích Thao tác Tên Cơ bản của Dịch vụ cho Tài khoản (SetSPN.exe) trong Bộ Tài nguyên Windows 2000. Tài khoản quản trị viên miền Windows 2000 hoặc tài khoản quản trị viên miền Windows 2003 có thể sử dụng tiện ích này để kiểm soát SPN được gán cho dịch vụ và tài khoản. Trong trường hợp SQL Server, phải có một và duy nhất một SPN. Trong hầu hết các trường hợp, SPN phải được gán cho vùng chứa thích hợp, tài khoản dịch vụ SQL Server và tài khoản máy tính khi SQL Server khởi động bằng tài khoản hệ thống cục bộ. Nếu bạn khởi động SQL Server khi đã đăng nhập bằng tài khoản LocalSystem thì SPN được tự động thiết lập. Tuy nhiên, nếu bạn sử dụng tài khoản miền để khởi động SQL Server hoặc bất cứ khi nào bạn thay đổi tài khoản được sử dụng để khởi động SQL Server, bạn phải chạy SetSPN.exe để gỡ bỏ các SPN hết hạn, sau đó phải thêm một SPN hợp lệ. Để biết thêm thông tin, hãy xem chủ đề "Uỷ nhiệm Tài khoản Bảo mật" trong Sách dành cho SQL Server Trực tuyến. Để làm việc này, hãy truy nhập Web site sau của Microsoft:Để biết thêm thông tin về Bộ Tài nguyên Windows 2000, hãy truy nhập Web site sau của Microsoft:
  6. Kiểm tra xem giải pháp tên có đang đúng hay không. Phương pháp giải pháp tên có thể bao gồm các tệp DNS, WINS, HOSTS và LMHOSTS. Để biết thêm thông tin về sự cố giải pháp tên và cách khắc phục sự cố, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    169790 Cách khắc phục sự cố cơ bản của TCP/IP
  7. Để biết thêm thông tin về cách khắc phục sự cố truy nhập và tường lửa với Active Directory, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    291382 Câu hỏi thường gặp về Windows 2000 DNS và Windows Server 2003 DNS
    224196 Hạn chế lưu lượng sao chép trong Active Directory và lưu lượng RPC của máy khách tới một cổng cụ thể

Cách đặt cấu hình dịch vụ SQL Server để tạo các SPN động cho phiên bản SQL Server

Để đặt cấu hình dịch vụ SQL Server để tạo các SPN động, bạn phải sửa đổi thiết đặt kiểm soát truy nhập của tài khoản trong dịch vụ thư mục Active Directory. Bạn phải cấp quyền "Đọc servicePrincipalName" và "Ghi servicePrincipalName" cho tài khoản dịch vụ SQL Server.

Cảnh báo Nếu bạn sử dụng phần đính vào Sửa Giao diện Dịch vụ Active Directory (ADSI), tiện ích LDP hay bất kỳ máy khách LDAP phiên bản 3 nào khác và bạn sửa đổi không đúng các thuộc tính cho đối tượng của Active Directory thì bạn có thể gây ra sự cố nghiêm trọng. Các sự cố này có thể yêu cầu bạn cài đặ lại Microsoft Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server hay cả Windows và Exchange. Chúng tôi không thể đảm bảo có thể giải quyết các sự cố gây ra do việc sửa đổi không đúng các thuộc tính đối tượng của Active Directory. Bạn sẽ tự chịu rủi ro khi sửa đổi các thuộc tính này.

Chú ý Để cấp các quyền thích hợp và quyền của người dùng cho tài khoản khởi động SQL Server, bạn phải được đăng nhập với tư cách là quản trị viên miền hoặc phải yêu cầu quản trị viên miền thực hiện tác vụ này.

Để đặt cấu hình dịch vụ SQL Server để tạo các SPN động, hãy làm theo các bước sau:
  1. Bấm Bắt đầu, bấm Chạy, nhập Adsiedit.msc, rồi bấm OK.
  2. Trong phần đính vào Sửa ADSI, mở rộng Miền [DomainName], mở rộng DC= RootDomainName, mở rộng CN=Users, bấm chuột phải vào CN= AccountName, rồi bấm Thuộc tính.

    Chú ý
    • DomainName là trình giữ chỗ cho tên miền.
    • RootDomainName là trình giữ chỗ cho tên miền gốc.
    • AccountName là trình giữ chỗ cho tài khoản mà bạn chỉ định để khởi động dịch vụ SQL Server.
    • Nếu bạn chỉ định tài khoản Hệ thống Cục bộ để khởi động dịch vụ SQL Server, AccountName là trình giữ chỗ cho tài khoản mà bạn sử dụng để đăng nhập vào Microsoft Windows.
    • Nếu bạn chỉ định tài khoản người dùng trong miền để khởi động dịch vụ SQL Server, AccountName là trình giữ chỗ cho tài khoản người dùng trong miền.
  3. Trong hộp thoại CN= AccountName Thuộc tính, bấm vào tab Bảo mật.
  4. Trên tab Bảo mật, bấm Nâng cao.
  5. Trong hộp thoại Thiết đặt Bảo mật Nâng cao, đảm bảo rằng SELF được liệt kê trong mục Các mục quyền.

    Nếu SELF không được liệt kê, bấm Thêm, rồi thêm SELF.
  6. Trong Các mục quyền, bấm SELF, rồi bấm Sửa.
  7. Trong hộp thoại Mục Quyền, bấm vào tab Thuộc tính.
  8. Trên tab Thuộc tính, bấm vào Chỉ đối tượng này trong danh sách Áp dụng vào, sau đó đảm bảo rằng chọn các hộp kiểm cho các quyền sau trong mục Quyền:
    • Đọc servicePrincipalName
    • Ghi servicePrincipalName
  9. Bấm OK ba lần, sau đó thoát khỏi phần đính vào Sửa ADSI.
Để được trợ giúp quy trình này, hãy liên hệ với bộ phận hỗ trợ sản phẩm Active Directory và đề cập đến bài viết này trong Cơ sở Kiến thức Microsoft.

Kiểm tra môi trường máy chủ

Kiểm tra một số thiết đặt cơ bản trên máy tính cài đặt SQL Server:
  1. Kerberos không được hỗ trợ trên máy tính chạy Windows 2000 đang chạy chức năng Tạo cụm cho Windows trừ khi bạn đã áp dụng Gói Dịch vụ 3 (hoặc phiên bản mới hơn) cho Windows 2000. Do đó, mọi nỗ lực sử dụng xác thực SSPI trên phiên bản SQL Server được tạo cụm có thể không thành công. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    235529 Hỗ trợ Kerberos trên các cụm máy chủ chạy Windows 2000
  2. Kiểm tra xem máy chủ có đang chạy Windows 2000 Gói Dịch vụ 1 (SP1) hay không. Để biết thêm thông tin về hỗ trợ Kerberos trên máy chủ chạy Windows 2000, bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    267588 Thông báo lỗi "Không thể tạo ngữ cảnh SSPI" hiển thị khi bạn kết nối với SQL Server 2000
  3. Trong một cụm, nếu tài khoản mà bạn sử dụng để khởi động SQL Server, SQL Server Agent hay các thay đổi dịch vụ tìm kiếm toàn văn bản, chẳng hạn như mật khẩu mới, hãy làm theo các bước được cung cấp ở bài viết sau trong Cơ sở Kiến thức Microsoft:
    239885 Cách thay đổi tài khoản dịch vụ cho máy tính được tạo cụm đang chạy SQL Server
  4. Kiểm tra xem tài khoản mà bạn sử dụng để khởi động SQL Server có các quyền thích hợp hay không. Nếu bạn đang sử dụng tài khoản không phải là thành viên của nhóm Quản trị viên Cục bộ, hãy xem chủ đề "Thiết lập Tài khoản Dịch vụ Windows" trong Sách dành cho SQL Trực tuyến để biết danh sách quyền chi tiết mà tài khoản này phải có:

Kiểm tra môi trường máy khách

Kiểm tra các mục sau của máy khách:
  1. Đảm bảo rằng NTLM Security Support Provider được cài đặt đúng và được kích hoạt trên máy khách. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    269541 Thông báo lỗi khi bạn kết nối với SQL Server nếu thiếu khoá đăng ký Windows NT LM Security Support Provider: "không thể tạo ngữ cảnh SSPI"
  2. Xác định xem bạn có đang sử dụng uỷ nhiệm được lưu trong bộ nhớ cache hay không. Nếu bạn được đăng nhập vào máy khách bằng uỷ nhiệm được lưu trong bộ nhớ cache, hãy đăng xuất khỏi máy tính rồi đăng nhập lại khi kết nối với bộ điều khiển miền để ngăn sử dụng uỷ nhiệm được lưu trong bộ nhớ cache. Để biết thêm thông tin về cách xác định xem bạn có đang sử dụng uỷ nhiệm được lưu trong bộ nhớ cache hay không, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    242536 Người dùng không được cảnh báo khi đăng nhập bằng uỷ nhiệm của miền được lưu trong bộ nhớ cache
  3. Kiểm tra xem ngày trên máy khách và máy chủ có hợp lệ không. Nếu ngày cách quá xa, uỷ nhiệm của bạn có thể được xem là không hợp lệ.
  4. SSPI sử dụng một tệp có tên là Security.dll. Nếu bất kỳ ứng dụng nào khác cài đặt tệp có tên này thì tệp đó có thể sử dụng tệp SSPI thực thay vào đó. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    253577 Lỗi: 80004005 - MS ODBC Trình điều khiển SQL Server không thể khởi động gói SSPI
  5. Nếu hệ điều hành trên máy khách là Microsoft Windows 98, bạn phải cài đặt Máy khách cho cấu phần Mạng Microsoft trên máy khách. Để biết thêm thông tin, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
    267550 LỖI: "Xác nhận không thành công" khi bạn kết nối với SQL Server qua TCP/IP

Kiểm tra tiện ích mạng máy khách

Tiện ích Mạng Máy khách (CNU) được cung cấp cùng với Cấu phần Truy nhập Dữ liệu Microsoft (MDAC) và được sử dụng để đặt cấu hình kết nối với máy tính đang chạy SQL Server. Bạn có thể sử dụng tiện ích MDAC Cliconfg.exe CNU để đặt cấu hình kết nối:
  1. Trên tab Chung, các giao thức đường dẫn được xác định thay đổi theo phiên bản MDAC. Với các phiên bản MDAC trước, bạn có thể chọn giao thức "mặc định". Trên các phiên bản MDAC mới nhất, bạn có thể kích hoạt một hoặc nhiều giao thức bằng phiên bản MDAC ở đầu danh sách khi bạn kết nối với SQL Server. Vì SSPI chỉ áp dụng cho TCP/IP nên bạn có thể sử dụng một giao thức khác như Đường ống được Đặt tên để tránh bị lỗi.
  2. Kiểm tra tab Bí danh trong CNU để xác minh xem bí danh có được xác định cho máy chủ mà bạn đang cố kết nối không. Nếu bí danh máy chủ đã được xác định, hãy kiểm tra thiết đặt đối với cách đặt cấu hình máy tính này để kết nối với SQL Server. Bạn có thể xác minh điều này bằng cách xoá bí danh máy chủ để xem hoạt động có thay đổi hay không.
  3. Nếu bí danh máy chủ không được xác định trên CNU, hãy thêm bí danh cho máy chủ mà bạn đang kết nối. Khi thực hiện tác vụ này, bạn cũng xác định rõ giao thức và xác định địa chỉ IP và cổng theo cách tuỳ chọn.

Thông tin thu thập để mở trường hợp Hỗ trợ Sản phẩm của Microsoft (PSS)

Nếu bạn không thể biết nguyên nhân của sự cố bằng cách sử dụng các bước khắc phục sự cố trong bài viết này, hãy thu thập thông tin sau và mở trường hợp Hỗ trợ Sản phẩm của Microsoft (PSS):

Để biết danh sách đầy đủ số điện thoại Dịch vụ Hỗ trợ Sản phẩm của Microsoft và thông tin về chi phí hỗ trợ, hãy truy nhập Web site sau của Microsoft:
  1. Tạo một báo cáo sqldiag từ SQL Server. Để biết thêm thông tin, hãy xem chủ đề "Tiện ích sqldiag" trong Sách dành cho SQL Server Trực tuyến.
  2. Chụp ảnh chụp màn hình lỗi trên máy khách.
  3. Trên nút không thể kết nối với SQL Server, nhập lệnh sau từ dấu nhắc lệnh:
    net start > started.txt
    Lệnh này tạo một tệp có tên Started.txt trong thư mục mà bạn muốn chạy lệnh.
  4. Lưu các giá trị cho khoá đăng ký trong khoá đăng ký sau trên máy khách của bạn:
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. Trong môi trường cụm, lấy giá trị của khoá đăng ký sau cho từng nút của cụm:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. Trong môi trường cụm, xem khoá đăng ký sau có tồn tại trên từng nút máy chủ cụm không:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Chụp lại kết quả nếu bạn kết nối với SQL Server bằng cách sử dụng tên Quy ước Đặt tên Phổ biến (UNC) (hoặc Tên Mạng SQL trên một cụm) từ máy khách.
  8. Chụp lại kết quả nếu bạn ping tên máy tính (hoặc Tên Mạng SQL trên một cụm) từ máy khách.
  9. Lưu tên của tài khoản người dùng mà bạn sử dụng để khởi động từng dịch vụ SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. Chuyên gia hỗ trợ phải biết liệu SQL Server có được đặt cấu hình cho Xác thực Hỗn hợp hay Chỉ Xác thực Windows.
  11. Xem bạn có thể kết nối với máy tính đang chạy SQL Server không từ cùng một máy khách bằng cách sử dụng Xác thực SQL Server.
  12. Xem bạn có thể kết nối bằng cách sử dụng giao thức Đường ống được Đặt tên không.

Cách thiết lập thủ công Tên Cơ bản của Dịch vụ cho SQL Server

Để biết thêm thông tin về cách thiết lập thủ công Tên Cơ bản của Dịch vụ cho SQL Server, hãy bấm vào số bài viết sau để xem bài viết trong Cơ sở Kiến thức Microsoft:
319723 Cách sử dụng xác thực Kerberos trong SQL Server
Security Support Provider Interface (SSPI) là giao diện cho bảo mật Microsoft Windows NT được sử dụng để xác thực Kerberos và hỗ trợ lược đồ xác thực của NTLM Security Support Provider. Quá trình xác thực diễn ra ở cấp hệ điều hành khi bạn đăng nhập vào miền Windows. Xác thực Kerberos chỉ khả dụng trên máy tính chạy Windows 2000 được kích hoạt Kerberos và đang sử dụng Active Directory.

SSPI chỉ được sử dụng cho kết nối được tạo bằng cách sử dụng chức năng Xác thực Windows. (Xác thực Windows cũng được biết đến là Kết nối Tin cậy hay Bảo mật Tích hợp). SSPI không được sử dụng bởi giao thức Đường ống được Đặt tên hoặc các kết nối đa giao thức. Do đó, bạn có thể tránh sự cố bằng cách đặt cấu hình máy khách của mình để kết nối từ giao thức không phải TCP/IP.

Khi máy khách SQL Server cố sử dụng tính năng bảo mật tích hợp qua khe cắm TCP/IP tới máy tính từ xa đang chạy SQL Server, thư viện mạng máy khách SQL Server sử dụng API SSPI để thực hiện uỷ nhiệm bảo mật. Máy khách mạng SQL Server (Dbnetlib.dll) thực hiện cuộc gọi tới chức năng AcquireCredentialsHandle và chuyển thành "thương lượng" cho tham số pszPackage. Thao tác này thông báo cho nhà cung cấp bảo mật cơ bản thực hiện uỷ nhiệm thương lượng. Trong ngữ cảnh này, thương lượng có nghĩa là cố xác thực Kerberos hoặc NTLM trên máy tính chạy Windows. Nói cách khác, Windows sử dụng uỷ nhiệm Kerberos nếu máy tính đích đang chạy SQL Server có SPN kết hợp được đặt cấu hình đúng. Nếu không, Windows sử dụng uỷ nhiệm NTLM.

Chú ý Kiểm tra xem bạn có đang sử dụng tài khoản có tên "SYSTEM" để khởi động bất kỳ dịch vụ SQL Server nào hay không (MSSQLServer, SQLServerAgent, MSSearch). Từ khoá SYSTEM có thể gây xung đột với Trung tâm Phân phối Khoá (KDC).
THAM KHẢO
Để biết thêm thông tin về cách hoạt động của tính năng bảo mật Kerberos và SSPI, hãy bấm vào các số bài viết sau đây để xem bài viết trong Cơ sở Kiến thức Microsoft:
266080 Câu trả lời cho câu hỏi thường gặp về Kerberos
231789 Quy trình đăng nhập cục bộ cho Windows 2000
304161 Xác thực tương hỗ SSPI được chỉ ra ở phía máy khách chứ không phải ở phía máy chủ
232179 Quản trị Kerberos trong Windows 2000
230476 Mô tả các lỗi phổ biến liên quan đến Kerberos trong Windows 2000
262177 Cách kích hoạt ghi sự kiện Kerberos
277658 Setspn không thành công nếu tên miền khác với tên NetBIOS mà SPN SQL Server được đăng ký
244474 Cách buộc Kerberos sử dụng TCP thay vì UDP trong Windows Server 2003, Windows XP và Windows 2000
326985 Cách khắc phục sự cố liên quan đến Kerberos trong IIS
Để xem báo cáo về tính năng bảo mật Microsoft SQL Server 2000, hãy truy nhập Web site sau của Microsoft:
Thuộc tính

ID Bài viết: 811889 - Xem lại Lần cuối: 09/17/2011 22:32:00 - Bản sửa đổi: 2.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 64-bit Edition, Microsoft Windows Server 2003, Standard Edition (32-bit x86)

  • kbsqlsetup kbhowtomaster kbhowto KB811889
Phản hồi