Tên chính mục tiêu không chính xác. Không thể tạo ngữ cảnh SSPI

Tôi đang đấu tranh để có được kết nối SQL Server từ máy A đến máy B đang chạy SQL Server.

Tôi đã sử dụng Google rộng rãi và tất cả những thứ tôi tìm thấy đều không hoạt động. Họ cũng không hướng dẫn bạn từng bước trong quá trình giải quyết việc này.

Chúng tôi không sử dụng Kerberos mà sử dụng NTLM ở nơi được định cấu hình.

Các máy liên quan là (xx được sử dụng để che khuất một số tên máy cho mục đích bảo mật):

• xxPRODSVR001 - Bộ điều khiển miền Windows Server 2012
• xxDEVSVR003 - Windows Server 2012 (Máy này đang tạo ra lỗi)
• xxDEVSVR002 - Windows Server 2012 (Máy này đang chạy SQL Server 2012)

Các SPN sau được đăng ký trên DC (xxPRODSVR001). Tôi đã che khuất miền với yyy vì mục đích bảo mật:

ServicePrincipalNames đã đăng ký cho CN = xxDEVSVR002, CN = Máy tính, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

ServicePrincipalNames đã đăng ký cho CN = xxDEVSVR003, CN = Máy tính, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Bây giờ nếu chỉ có thông báo lỗi SQL Server mang tính mô tả nhiều hơn và cho tôi biết tên chính mà nó đang cố gắng kết nối với thì tôi có thể chẩn đoán được điều này.

Vì vậy, bất cứ ai có thể hướng dẫn tôi cách giải quyết vấn đề này hoặc bạn có thể thấy bất kỳ điều gì trong những gì tôi đã cung cấp là sai không?

Tôi rất vui khi tạo thêm thông tin gỡ lỗi, chỉ cần cho tôi biết bạn cần gì.

Tôi gặp sự cố này với ứng dụng ASP.NET MVC mà tôi đang làm việc.

Tôi nhận ra rằng gần đây tôi đã thay đổi mật khẩu của mình và tôi đã có thể sửa nó bằng cách đăng xuất và đăng nhập lại.

Tôi gặp lỗi này khi kết nối qua SQL Server Management Studio bằng Xác thực Windows. Mật khẩu của tôi đã hết hạn nhưng tôi vẫn chưa thay đổi nó. Sau khi thay đổi, sau đó tôi phải đăng xuất và đăng nhập lại để máy hoạt động bằng thông tin đăng nhập mới của tôi.

Thử cài đặt Integrated Security=trueđể xóa thông số này khỏi chuỗi kết nối.

QUAN TRỌNG: Như người dùng @Auspex đã nhận xét,

Xóa Bảo mật Tích hợp sẽ ngăn lỗi này do lỗi xảy ra khi cố gắng đăng nhập bằng thông tin đăng nhập Windows của bạn. Thật không may, hầu hết thời gian, bạn muốn có thể đăng nhập bằng thông tin đăng nhập Windows của mình

Tôi đã gặp lỗi tương tự khi thử thông qua xác thực cửa sổ. Nghe có vẻ lố bịch nhưng đề phòng nó giúp ích cho người khác: đó là do tài khoản miền của tôi bị khóa bằng cách nào đó trong khi tôi vẫn đăng nhập (!). Mở khóa tài khoản đã sửa nó.

Tôi đã đăng nhập vào Windows 10 bằng mã PIN thay vì mật khẩu. Thay vào đó, tôi đã đăng xuất và đăng nhập lại bằng mật khẩu của mình và có thể đăng nhập vào SQL Server thông qua Management Studio.

Lỗi ngữ cảnh SSPI chắc chắn cho biết xác thực đang được cố gắng sử dụng Kerberos .

Vì xác thực Kerberos Xác thực Windows của SQL Server dựa trên Active Directory , yêu cầu mối quan hệ đẩy giữa máy tính và bộ điều khiển miền mạng của bạn, bạn nên bắt đầu bằng cách xác thực mối quan hệ đó.

Bạn có thể nhanh chóng kiểm tra mối quan hệ đó, thông qua lệnh Powershell Test-ComputerSecureChannel sau đây .

Test-ComputerSecureChannel -verbose

Nếu nó trả về False , bạn phải sửa chữa kênh bảo mật Active Directory cho máy tính của mình, vì nếu không có nó thì không thể xác thực tên miền bên ngoài máy tính của bạn.

Bạn có thể sửa chữa Kênh bảo mật máy tính của mình thông qua lệnh Powershell sau :

Test-ComputerSecureChannel -Repair

Kiểm tra nhật ký sự kiện bảo mật, nếu bạn đang sử dụng kerberos, bạn sẽ thấy các lần đăng nhập với gói xác thực: Kerberos.

Xác thực NTLM có thể không thành công và do đó, một nỗ lực xác thực kerberos đang được thực hiện. Bạn cũng có thể thấy lỗi cố gắng đăng nhập NTLM trong nhật ký sự kiện bảo mật của mình?

Bạn có thể bật tính năng đăng nhập sự kiện kerberos trong nhà phát triển để cố gắng gỡ lỗi tại sao kerberos bị lỗi, mặc dù nó rất dài dòng.

Trình quản lý cấu hình Kerberos của Microsoft dành cho SQL Server có thể giúp bạn nhanh chóng chẩn đoán và khắc phục sự cố này.

Truyện hay nên đọc đây: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

Chỉ để thêm một giải pháp tiềm năng khác cho lỗi mơ hồ nhất này The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Xác minh rằng IP được giải quyết khi ping SQL Server giống với IP trong Trình quản lý cấu hình. Để kiểm tra, hãy mở SQL Server Configuration Manager, sau đó đi tới SQL Server Network Configuration> Protocols for MSSQLServer> TCP / IP.

Đảm bảo TCP / IP được bật và trong tab Địa chỉ IP, hãy đảm bảo rằng IP mà máy chủ phân giải khi ping là cùng một IP ở đây. Điều đó đã sửa lỗi này cho tôi.

Vấn đề dường như là vấn đề thông tin đăng nhập windows. Tôi đã gặp lỗi tương tự trên máy tính xách tay làm việc của mình với VPN. Tôi được cho là đã đăng nhập bằng Tên miền / Tên người dùng của mình, đây là những gì tôi sử dụng thành công khi kết nối trực tiếp nhưng ngay sau khi tôi chuyển sang VPN có kết nối khác, tôi nhận được lỗi này. Tôi nghĩ rằng đó là sự cố DNS vì tôi có thể ping máy chủ nhưng hóa ra tôi cần chạy SMSS một cách rõ ràng với tư cách là người dùng của mình từ Command prompt.

ví dụ: runas / netonly / user: YourDoman \ YourUsername "C: \ Program Files (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"

Đăng nhập vào cả SQL Box và máy khách của bạn và nhập:

ipconfig /flushdns
nbtstat -R

Nếu cách đó không hiệu quả, hãy gia hạn DHCP của bạn trên máy khách của bạn ... Điều này hoạt động cho 2 PC trong văn phòng của chúng tôi.

Tôi vừa gặp phải vấn đề này và sửa nó bằng cách làm 2 việc:

1. Cấp quyền đọc / ghi servicePrincipalName cho tài khoản dịch vụ bằng ADSI Edit, như được mô tả trong https://support.microsoft.com/en-us/kb/811889

2. Xóa SPN đã tồn tại trước đó trên tài khoản máy tính SQL Server (trái ngược với tài khoản dịch vụ) bằng cách sử dụng

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
   

   trong đó 1234 là số cổng được sử dụng bởi phiên bản (của tôi không phải là phiên bản mặc định).

Trong trường hợp của tôi, khởi động lại SQL Server 2014 (trên máy chủ phát triển của tôi) đã khắc phục sự cố.

Tôi đang thử nghiệm IPv6 trên một cụm PC trong một mạng bị cô lập và gặp sự cố này khi tôi hoàn nguyên lại IPv4 của yo. Tôi đã chơi trong thư mục hoạt động, DNS và DHCP nên không biết tôi đã kích hoạt gì để phá vỡ thiết lập Kerberos.

Tôi đã kiểm tra lại kết nối bên ngoài phần mềm của mình bằng mẹo hữu ích này để kết nối kết nối từ xa mà tôi tìm thấy.

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

thì sau một cuộc tìm kiếm ngắn đã tìm thấy điều này trên trang web của Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

chạy công cụ trên máy chủ SQL xem có vấn đề gì không nếu trạng thái báo lỗi, sau đó nhấn nút sửa lỗi xuất hiện.

Điều này giải quyết vấn đề cho tôi.

Điều này thường là do Tên nguyên tắc dịch vụ (SPN) bị thiếu, không chính xác hoặc trùng lặp

Các bước giải quyết:

1. Xác nhận tài khoản AD SQL Server đang sử dụng
2. Chạy lệnh sau trong Powershell hoặc CMD ở chế độ quản trị viên (tài khoản dịch vụ không được chứa miền)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

3. Đảm bảo đầu ra được trả về chứa SPN đủ điều kiện, không đủ tiêu chuẩn, có cổng và không có cổng.

   Đầu ra mong đợi:

   Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
   MSSQLSvc/<ServerName>.<domain>.com:1433
   MSSQLSvc/<ServerName>:1433                                           
   MSSQLSvc/<ServerName>.<domain>.com
   MSSQLSvc/<ServerName>
   

4. Nếu bạn không thấy tất cả những điều trên, hãy chạy lệnh sau trong PowerShell hoặc CMD ở chế độ quản trị (đảm bảo thay đổi cổng nếu bạn không sử dụng mặc định 1433)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>

5. Sau khi hoàn tất ở trên, thông thường mất vài phút để lan truyền DNS

Ngoài ra, nếu bạn nhận được thông báo về các SPN trùng lặp được tìm thấy, bạn có thể muốn xóa chúng và tạo lại chúng

Tôi gặp sự cố này khi truy cập ứng dụng web. Có thể do tôi đã thay đổi mật khẩu windows gần đây.

Sự cố này đã được giải quyết khi tôi cập nhật mật khẩu cho nhóm ứng dụng nơi tôi đã lưu trữ ứng dụng web.

Kiểm tra đồng hồ của bạn khớp giữa máy khách và máy chủ.

Khi tôi gặp lỗi này liên tục, không có câu trả lời nào ở trên hoạt động, sau đó chúng tôi nhận thấy thời gian đã trôi qua trên một số máy chủ của chúng tôi, sau khi chúng được đồng bộ hóa lại, lỗi đã biến mất. Tìm kiếm w32tm hoặc NTP để xem cách tự động đồng bộ thời gian trên Windows.

Vì tôi đã hạ cánh ở đây khi tìm kiếm giải pháp cho vấn đề của riêng mình, nên tôi sẽ chia sẻ giải pháp của mình ở đây, trong trường hợp những người khác cũng hạ cánh ở đây.

Tôi đã kết nối tốt với SQL Server cho đến khi máy của tôi được chuyển đến văn phòng khác trên miền khác . Sau đó, sau khi chuyển đổi, tôi đã gặp lỗi này liên quan đến tên chính mục tiêu. Điều gì đã sửa nó được kết nối bằng cách sử dụng một tên đầy đủ đủ điều kiện như: server.domain.com . Và trên thực tế, khi tôi kết nối với máy chủ đầu tiên theo cách đó, tôi có thể kết nối với các máy chủ khác chỉ bằng tên máy chủ (không có đủ điều kiện), nhưng số dặm của bạn có thể thay đổi.

Tôi gặp sự cố này hôm nay và muốn chia sẻ cách khắc phục của mình, vì cái này đơn giản là bị bỏ qua và dễ sửa.

Chúng tôi quản lý rDNS của riêng mình và gần đây đã làm lại sơ đồ đặt tên máy chủ của chúng tôi. Như một phần của điều đó, đáng lẽ chúng ta nên cập nhật rDNS của mình và quên làm điều này.

Một ping trả về tên máy chủ chính xác, nhưng một ping -a trả về tên máy chủ không chính xác.

Cách khắc phục dễ dàng: thay đổi rDNS, thực hiện ipconfig / flushdns, đợi 30 giây (chỉ cần tôi làm gì đó), thực hiện một ping -a khác, xem nó giải quyết đúng tên máy chủ, kết nối ... lợi nhuận.

Tôi gặp phải một cái mới cho việc này: SQL 2012 được lưu trữ trên Server 2012. Được giao nhiệm vụ tạo một cụm cho SQL AlwaysOn.
Cụm đã được tạo, mọi người đều nhận được thông báo SSPI.

Để khắc phục sự cố chạy lệnh sau:

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== tài khoản miền tôi đã đặt cho SQL Tôi cần có Quản trị viên miền để chạy lệnh. Chỉ có một máy chủ trong cụm gặp sự cố.

Sau đó khởi động lại SQL. Thật ngạc nhiên khi tôi có thể kết nối.

Tôi đang cố gắng kết nối với máy ảo chạy SQL Server 2015 từ máy tính xách tay của mình trong Ứng dụng điều khiển Visual Studio 2015. Tôi chạy ứng dụng của mình vào đêm hôm trước và nó ổn. Vào buổi sáng, tôi cố gắng gỡ lỗi ứng dụng và tôi gặp lỗi này. Tôi đã thử ipconfig/flushvà release+ renewvà rất nhiều loại rác khác, nhưng cuối cùng ...

Khởi động lại máy ảo của bạn và khởi động lại máy khách. Điều đó đã sửa nó cho tôi. Tôi đã nên biết, khởi động lại công việc mỗi lần.

Tôi gặp sự cố này trên máy chủ sql của mình. Tôi setspn -D mssqlsvc \ Hostname.domainname Tên máy chủ sau đó dừng và bắt đầu dịch vụ máy chủ SQL của mình.

Tôi đang nghĩ rằng chỉ cần dừng lại và bắt đầu dịch vụ sql của tôi là có thể làm được.

Tôi đã gặp vấn đề tương tự, nhưng khóa và mở khóa máy đã hoạt động với tôi. Đôi khi, các vấn đề về tường lửa sẽ gây ra lỗi.

Tôi không chắc nó sẽ làm việc cho bạn hay không, chỉ chia sẻ kinh nghiệm của tôi.

Tôi đã thử tất cả các giải pháp ở đây và không có giải pháp nào trong số chúng hoạt động. Một cách giải quyết đang hoạt động là Nhấp vào Kết nối , nhập tên máy chủ, chọn Tùy chọn, tab Thuộc tính Kết nối. Đặt "Giao thức mạng" thành "Đường ống được đặt tên". Điều này cho phép người dùng kết nối từ xa bằng thông tin đăng nhập mạng của họ. Tôi sẽ đăng bản cập nhật khi tôi nhận được bản sửa lỗi.

Trong trường hợp của tôi, sự cố là thiết lập DNS trên wifi. Tôi đã xóa cài đặt và để trống, và hoạt động.

Đảm bảo rằng "Ống được đặt tên" được bật từ "Trình quản lý cấu hình máy chủ SQL". Điều này đã làm việc cho tôi.

1. Mở "Trình quản lý cấu hình SQL Server".
2. Mở rộng "Cấu hình mạng máy chủ SQL", từ danh sách ở bên trái.
3. Chọn "Giao thức cho [Tên trường hợp của bạn]".
4. Nhấp chuột phải vào "Đường ống được đặt tên", từ danh sách ở bên phải.
5. Chọn "Bật"
6. Khởi động lại dịch vụ Phiên bản của bạn.

Công cụ này của Microsoft giống như Magic. Chạy nó, kết nối nó với máy chủ SQL và nhấp vào Khắc phục

Phiên bản cũ được liên kết ở đây đã hoạt động trên máy chủ SQL 2017.

Trình quản lý cấu hình Kerberos dành cho SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

Trong tình huống của tôi, tôi đang cố gắng sử dụng Bảo mật tích hợp để kết nối từ PC với SQL Server trên PC khác trên mạng không có miền. Trên cả hai PC, tôi đã đăng nhập vào Windows bằng cùng một tài khoản Microsoft . Tôi đã chuyển sang tài khoản cục bộ trên cả PC và SQL Server hiện đã kết nối thành công.

Trong Trường hợp của tôi vì tôi đang làm việc trong môi trường phát triển của mình, ai đó đã tắt Bộ điều khiển miền và không thể xác thực Thông tin đăng nhập Windows. Sau khi bật Trình điều khiển miền, lỗi đã biến mất và mọi thứ hoạt động tốt.

Một ngách khác cho vấn đề này do kết nối mạng gây ra. Tôi kết nối qua ứng dụng khách Windows VPN và vấn đề này xuất hiện khi tôi chuyển từ kết nối Wifi sang kết nối có dây. Cách khắc phục cho tình huống của tôi là điều chỉnh thủ công số liệu bộ điều hợp.

Trong powershell, hãy sử dụng Get-NetIPInterface để xem tất cả các giá trị số liệu. Những con số thấp hơn có chi phí thấp hơn và do đó chúng được ưa thích bởi các cửa sổ. Tôi đã chuyển ethernet và VPN và thông tin đăng nhập đã đến nơi chúng cần để SSMS hoạt động tốt.

Để định cấu hình tính năng Số liệu tự động: Trong Bảng điều khiển, bấm đúp vào Kết nối mạng. Bấm chuột phải vào giao diện mạng, sau đó chọn Thuộc tính. Bấm Giao thức Internet (TCP / IP), sau đó chọn Thuộc tính. Trên tab Chung, chọn Nâng cao. Để chỉ định số liệu, trên tab Cài đặt IP, hãy chọn bỏ chọn hộp kiểm Số liệu tự động, sau đó nhập số liệu bạn muốn vào trường Số liệu giao diện.

Nguồn: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes

Tôi đã gặp phải một biến thể của vấn đề này, đây là các đặc điểm:

• Người dùng có thể kết nối thành công với một phiên bản được đặt tên, ví dụ: kết nối vớiServer\Instance thành công
• Người dùng không thể kết nối với phiên bản mặc định, ví dụ: kết nối Serverkhông thành công với ảnh chụp màn hình của OP liên quan đến SSPI
• Người dùng không thể kết nối phiên bản mặc định với tên đủ điều kiện, ví dụ: kết nối Server.domain.comkhông thành công (hết giờ)
• Người dùng không thể kết nối địa chỉ IP mà không có phiên bản được đặt tên, ví dụ: kết nối 192.168.1.134không thành công
• Những người dùng khác không có trên miền (ví dụ: người dùng VPN vào mạng) nhưng sử dụng thông tin đăng nhập miền đã có thể kết nối thành công với địa chỉ IP và phiên bản mặc định

Vì vậy, sau nhiều lần đau đầu cố gắng tìm ra lý do tại sao người dùng duy nhất này không thể kết nối, đây là các bước chúng tôi đã thực hiện để khắc phục tình huống:

1. Hãy xem máy chủ trong danh sách SPN bằng cách sử dụng
   setspn -l Server
   a. Trong trường hợp của chúng tôi, nó nóiServer.domain.com
2. Thêm mục nhập vào tệp máy chủ lưu trữ nằm trong C:\Windows\System32\drivers\etc\hosts(chạy Notepad với tư cách Quản trị viên để thay đổi tệp này). Mục nhập chúng tôi đã thêm là
   Server.domain.com Server

Sau đó, chúng tôi đã có thể kết nối thành công qua SSMS với phiên bản mặc định.

Tôi cũng gặp sự cố này trên SQL Server 2014 khi đăng nhập bằng Windows Authentication, để giải quyết vấn đề, tôi đã Khởi động lại máy chủ của mình một lần và sau đó cố gắng đăng nhập, nó đã hoạt động với tôi.