SQL Server 2008 Windows Auth Login Error: Đăng nhập từ một miền không đáng tin cậy

Khi cố gắng kết nối với Phiên bản SQL Server 2008 bằng Management Studio, tôi gặp lỗi sau:

Đăng nhập thất bại. Thông tin đăng nhập là từ một miền không đáng tin cậy và không thể được sử dụng với xác thực Windows. (Microsoft SQL Server, Lỗi: 18452)

Tôi có thể đăng nhập bằng Xác thực SQL mà không có vấn đề gì. Tôi đã gặp lỗi này một cách đột ngột. Tôi đã bật Xác thực ở chế độ hỗn hợp.

Có ai có bất cứ kinh nghiệm với điều này?

Thông tin bổ sung: Phiên bản 64-bit của SQL Enterprise Edition trên Windows 2003 Server

Một lý do khác mà điều này có thể xảy ra (chỉ xảy ra với tôi) ... là mật khẩu của người dùng hết hạn. Tôi không nhận ra điều này cho đến khi tôi cố gắng điều khiển từ xa vào máy chủ thực tế và được nhắc thay đổi mật khẩu của mình.

Đối với tôi, điều này đã xảy ra khi tôi chỉnh sửa một drivers/etc/hoststệp trống và thêm một mục nhập cho một trang web địa phương, nhưng lại bỏ qua việc thêm127.0.0.1 localhost

Vấn đề là do Active Directory Server bị hỏng, tất nhiên không thể xác thực tài khoản Windows. Cám ơn sự giúp đỡ của bạn.

Đối với bất kỳ ai khác gặp phải vấn đề này, tôi đã có thông tin này trong tệp máy chủ của mình:

127.0.0.1   localhost
127.0.0.1   customname

và tôi cần nó là cái này:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Vấn đề là do Active Directory Server bị hỏng, tất nhiên không thể xác thực tài khoản Windows"

Đó không phải là "tất nhiên - bởi vì nếu AD không có sẵn thì xác thực Kerberos sẽ trở lại NTLM (thông tin đăng nhập tài khoản miền được lưu trữ cục bộ, người ta có thể đăng nhập bằng nó ngay cả khi AD / Kerberos không khả dụng). Tôi đoán rằng bạn có thể có 2 điều kiện đồng thời để xảy ra lỗi này:

• SQL Server không cục bộ (trên một máy khác)
• Sự tin cậy được định cấu hình "Chỉ Kerberos"

hoặc các cấu hình mạng / máy chủ / AD / máy cụ thể khác

Tôi đã gặp sự cố này đối với một phiên bản máy chủ trên máy cục bộ của mình và nhận thấy rằng đó là do tôi đang trỏ đến 127.0.0.1 bằng một thứ gì đó khác với "localhost" trong tệp máy chủ của mình. Có hai cách để khắc phục sự cố này trong trường hợp của tôi:

1. Xóa mục nhập vi phạm trỏ đến 127.0.0.1 trong tệp máy chủ
2. sử dụng "localhost" thay vì tên khác trong tệp máy chủ trỏ đến 127.0.0.1

* Điều này chỉ hiệu quả với tôi khi tôi đang chạy phiên bản máy chủ sql trên hộp cục bộ của mình và cố gắng truy cập nó từ cùng một máy.

Đảm bảo rằng bạn không kết nối với VPN trên miền \ người dùng khác . Hoặc ngược lại, hãy chắc chắn bạn đang kết nối, nếu đó là những gì được yêu cầu.

Tôi đã khắc phục sự cố này trên máy vô hiệu hóa cài đặt kiểm tra lặp lại:

1. Chỉnh sửa sổ đăng ký Windows: Bắt đầu -> Chạy> Regedit
2. Điều hướng đến: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Thêm giá trị DWORD được gọi là “DisableLoopbackCheck”
4. Đặt giá trị này thành 1

thử sử dụng thông tin đăng nhập hợp lệ khác bằng lệnh RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Đối với tôi, đó là vì tôi đã không thêm tài khoản để có các vai trò mà tôi muốn sử dụng cho chính Cơ sở dữ liệu SQL. Và cũng do một mật khẩu không hợp lệ thông qua sự cố sao chép dán khóa tài khoản.

Được rồi, hoàn toàn không có câu trả lời từ tôi. Tôi gặp lỗi này từ môi trường phát triển được lưu trữ trên VM VirtualBox. Ba máy chủ; SharePoint, SQL DB và Bộ điều khiển miền. Máy chủ SharePoint không thể kết nối với cơ sở dữ liệu cấu hình. Tôi vẫn có thể kết nối qua ODBC để xác thực Sql bằng tài khoản SA nhưng không xác thực Windows. Nhưng người dùng đó sẽ vui vẻ đăng nhập vào SSMS trên chính máy chủ sql. Tôi cũng nhận được thông báo lỗi tốt hơn từ ODBC và cũng bằng cách kiểm tra thông báo đăng nhập không thành công trên máy chủ sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Không thể ghi nhận điều này vì tôi đã yêu cầu một trong những Quản trị viên Hệ thống Doanh nghiệp của chúng tôi giúp đỡ và anh ấy đã chẩn đoán nó trong khoảng 5 phút sau khi xem một vài ảnh chụp màn hình mà tôi gửi cho anh ấy. Vấn đề là đồng hồ của Bộ điều khiển miền đã được đặt không chính xác! Không thể tin được. Các máy chủ được thiết lập cho mạng Chỉ máy chủ lưu trữ nên không có Internet để đồng bộ hóa đồng hồ. Điều đó cũng giải thích tại sao quay lại ảnh chụp nhanh trước đó khi tôi biết hệ thống đang hoạt động không giải quyết được vấn đề.

Chỉnh sửa: Việc cài đặt Bổ sung khách trên máy chủ sẽ đồng bộ hóa đồng hồ của khách với máy chủ.

Có một cài đặt trên trình điều khiển jTDS được gọi là USENTLMV2 được đặt thành false theo mặc định. Đặt điều này thành 'true' trong phần mềm db của tôi (DBVisualizer) đã giải quyết được nó.

Một tình huống khác mà bạn có thể thấy điều này là khi bạn đang cố gắng kết nối với một máy chủ SQL khác từ một phiên SSMS đã được đăng nhập trong khi bạn thay đổi mật khẩu của mình. Chuỗi sự kiện có thể diễn ra như sau:

1. RDP tới Server-A (SQL Server của bạn), mở SSMS và đăng nhập
2. RDP tới Server-B trong cùng một miền và thay đổi mật khẩu của bạn
3. Quay lại phiên RDP trên Server-A và thông qua SSMS cố gắng thêm một DB khác vào nhóm khả dụng AlwaysOn hiện có. Khi kết nối với các bản sao, bạn nhận được "tên miền không đáng tin cậy" -login-error

Để giải quyết, chỉ cần đăng xuất và đăng nhập lại

Bạn có thể bị hiểu nhầm về tên người dùng mà bạn sử dụng cục bộ. Đó là trường hợp của tôi trong Windows 10 Home. Khi tôi nhìn vào người dùng trong bảng điều khiển, tôi thấy tên usrpc01 . Tuy nhiên khi tôi nhập net config workstation, có vẻ như tên người dùng là spc01 . Có vẻ như ai đó đã đổi tên người dùng, nhưng tên nội bộ vẫn không thay đổi.

Không biết cách sửa tên người dùng windows (và tên thư mục bên dưới C:\Users, cũng đề cập đến tên nội bộ ban đầu), tôi đã thêm tài khoản người dùng mới trên máy chủ db của mình.

Tôi đã cố gắng đăng nhập vào SQL Server 2008 từ một tài khoản miền. SQL Server 2008 được lưu trữ trên một máy tính nhóm làm việc khác không phải là một phần của miền. Nghe có vẻ lạ, trên máy chủ nhóm làm việc đang chạy SQL Server 2008, tôi phải truy cập Thuộc tính hệ thống | Tên máy tính (tab) | Thay đổi (nút) | Thay đổi tên máy tính | Thêm ... (nút) và nhập "Hậu tố DNS chính của máy tính này" (nó trống, vì vậy hãy nhập hậu tố mong muốn cho mạng của bạn) và chọn hộp "Thay đổi hậu tố DNS chính khi thành viên miền thay đổi". Điều này cho phép quá trình Xác thực Windows hoàn tất khi đăng nhập vào SQL Server 2008.

Tôi đã phải sử dụng netonly để làm cho điều này hoạt động trên Windows hiện đại:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Một lý do khác> ai đó đã thay đổi mật khẩu cho người dùng SQL mặc định

điều này đã xảy ra với tôi vài phút trước khi chuyển sang bộ điều khiển miền mới ...

Tôi đã nhập sai trong tệp máy chủ lưu trữ dưới C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Đảm bảo có mục nhập như bên dưới

127.0.0.1   localhost
127.0.0.1   localhost   servername

Tôi đang sử dụng bí danh cho một phiên bản SQL Server trỏ đến "127.0.0.1". Thay đổi nó thành "localhost" thay vào đó đã thực hiện thủ thuật.

Nếu Máy chủ Sql của bạn đang chạy trên máy chủ không phải là một phần của miền và trong chuỗi kết nối bạn sử dụng tên miền đủ điều kiện (ví dụ: xyz.mypc.com) với Bảo mật tích hợp = True, bạn có thể phải chuyển sang sử dụng địa chỉ IP, Tên máy (SERVER01) hoặc dấu chấm (.) trong trường hợp được lưu trữ cục bộ.

Điều này đã làm việc cho tôi, bằng cách sử dụng fqdn đã dẫn đến lỗi ở trên.

để kích hoạt xác thực windows, cả hai máy tính cần phải ở trong cùng một miền. để cho phép các studio quản lý chuyển thông tin đăng nhập hiện tại và xác thực trong hộp sql

Đối với tôi, tôi phải ngắt kết nối (thay đổi nhóm làm việc / miền) khỏi Miền và kết nối lại.

Và một lý do có thể khác: Tài khoản cục bộ mới được tạo trên Máy chủ DB có Cờ: "Người dùng phải thay đổi Mật khẩu ở lần đăng nhập tiếp theo".

Đây là những gì đã khắc phục sự cố cho tôi: Thuộc tính của kết nối mạng Nhấp vào: "Giao thức Internet Phiên bản 4 (TCT / IPv4)". Nhấp vào nút "Thuộc tính". Nhấp vào nút "Nâng cao". Chọn tab "DNS". Xóa văn bản trong "hậu tố DNS cho kết nối này".

Tôi cũng không thể kết nối từ xa với máy chủ SQL. Cả máy chủ SQL và máy chủ từ xa trong cùng một miền. Và tôi đã được yêu cầu thay đổi mật khẩu vài ngày trước đó. Khởi động lại cả máy chủ SQL và máy chủ từ xa mà tôi đang cố gắng truy cập máy chủ SQL từ đã thực hiện một mẹo nhỏ cho tôi.

Trong trường hợp của chúng tôi, đó là thực tế là nhà phát triển đang chạy nhóm ứng dụng bằng tài khoản của chính mình và đã đặt lại mật khẩu của mình nhưng quên thay đổi nó trên nhóm ứng dụng. Tât nhiên...

Trong trường hợp của tôi, máy chủ đã bị vô hiệu hóa trong bộ điều khiển miền. Tôi đã vào OU MÁY TÍNH trong thư mục Hoạt động, nhấp chuột phải vào máy chủ, kích hoạt nó, sau đó thực hiện gpupdate / force từ máy chủ SQL. Phải mất một lúc, nhưng cuối cùng nó đã hoạt động.

Trong trường hợp của tôi, trong tệp máy chủ, tên máy được mã hóa cứng bằng IP cũ hơn. Tôi thay thế IP cũ bằng IP mới, vấn đề đã được giải quyết.

Vị trí tệp máy chủ

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Đã thực hiện sửa đổi 159.xx.xx.xxx Tên máy

Không có điều nào ở trên phù hợp với tôi. Những gì tôi phải làm là: Trong SQL Server Management Studio trên màn hình đăng nhập, chọn Tùy chọn >> Trong phần Mạng, thay đổi giao thức Mạng thành Ống được đặt tên.

Ngoài ra, những gì tôi phải làm để làm cho nó hoạt động với <default>cài đặt là vô hiệu hóa mạng không dây (máy cũng được kết nối với mạng lan có dây).

Cách khắc phục của tôi là thay đổi tệp web.config để tương quan với tên máy chủ mới của tôi cho Kết nối SQL (Bảo mật CNTT vừa thực hiện đổi tên netdom trên hộp phát triển của tôi.