Sửa cho người dùng mồ côi 'khách'?

Điều gì có thể được thực hiện, nếu có bất cứ điều gì, khi guestngười dùng đặc biệt mồ côi (không liên kết với bất kỳ thông tin đăng nhập nào)?

Đối với một trong những cơ sở dữ liệu của tôi (SQL Server 2005), việc thực thi các danh sách sau đây liệt kê người dùng khách là người dùng mồ côi.

exec sp_change_users_login 'report'

Các kết quả:

UserName    UserSID
guest       0x3C2E66759FFBC14F84127D6795C27FD3

Nếu tôi cố gắng khắc phục người dùng khách bằng quy trình đó, tôi sẽ nhận được như sau:

exec sp_change_users_login 'update_one', 'guest', 'guest'

Chấm dứt thủ tục này. 'khách' là giá trị bị cấm đối với tham số tên đăng nhập trong quy trình này.

Nếu tôi cố xóa người dùng, tôi nhận được:

Người dùng 'khách' không thể bị loại bỏ, nó chỉ có thể bị vô hiệu hóa.

select * from sys.database_principals where name = 'guest'

Kết quả trong:

name                 guest
principal_id         2
type                 S
type_desc            SQL_USER
default_schema_name  guest
create_date          11/13/98 2:58 AM
modify_date          10/16/01 4:31 PM
owning_principal_id  NULL
sid                  0x3C2E66759FFBC14F84127D6795C27FD3
is_fixed_role        0

Cơ sở dữ liệu dường như bị nhầm lẫn về việc liệu đây có phải là người dùng đặc biệt hay không. Có bất cứ điều gì có thể được thực hiện?

sql-server sql-server-2005

— JustinStolle
nguồn

SID của nó được liệt kê 0x3C2E66759FFBC14F84127D6795C27FD3thay vì0x00

— JustinStolle

Bạn đã thử làm sửa chữa tự động chưa? Tôi tò mò muốn xem kết quả.

— SQLRockstar

Tôi nhận đượcTerminating this procedure. 'guest' is a forbidden value for the login name parameter in this procedure.

— JustinStolle

Bạn gặp phải lỗi đó vì bạn không thể có khách là tên người dùng ( msdn.microsoft.com/en-us/l Library / ms174378.aspx ). Tôi đang có một thời gian khó khăn để tạo lại kịch bản của bạn.

— Thomas Stringer

Tôi muốn nói thêm rằng tôi đã gặp chính xác vấn đề giống như Justin đã làm. Vấn đề ở đây là giá trị của khách phải là 0x00 nhưng vì bất kỳ lý do gì, nó không phải và vì vậy 'báo cáo' sp_change_usftimelogin sẽ chọn nó như một người dùng mồ côi. Tôi chỉ không thể thấy rằng có một cách để các DBA thay đổi hoặc gây rối [cho khách] theo những cách thông thường. Vì vậy, đôi khi tôi nghĩ rằng mớ hỗn độn này rất có thể được tạo ra bởi các bản vá máy chủ sql.

— jyao

Câu trả lời:

Người dùng "khách" không bao giờ được gán cho thông tin đăng nhập máy chủ, ngay cả khi cài đặt mới, nó được phân loại là người dùng SQL mà không cần đăng nhập. Vì bạn chỉ có thể đặt SID của thông tin đăng nhập (khi tạo) và không phải là người dùng nên tôi không tin rằng điều này là có thể; sp_change_usftimelogin không hoạt động chính xác vì lý do tài khoản khách không bao giờ được ánh xạ tới thông tin đăng nhập máy chủ. Do đó, người dùng "khách" luôn là người dùng mồ côi. Có lẽ không phải là câu trả lời bạn muốn mặc dù :)

— Mr.Brownstone
nguồn

Bạn có nghĩ rằng có một cách để sao lưu / khôi phục cơ sở dữ liệu này đến một vị trí khác trong khi loại bỏ người dùng khách khỏi khôi phục không?

— JustinStolle

Có nhưng nó không đẹp. Một bản sao lưu và khôi phục đơn giản sẽ không hoạt động vì người dùng khách sẽ được bao gồm trong đó. Bạn sẽ cần bắt đầu với một cơ sở dữ liệu mới được tạo bằng chính phương thức bạn đã sử dụng để cài đặt cơ sở dữ liệu ban đầu (giả sử khách trong mô hình có SID chính xác). Sau đó, từ hệ thống hiện tại của bạn xuất tất cả dữ liệu vào cơ sở dữ liệu mới của bạn. Điều này sẽ làm việc, nhưng nó là rất nhiều nỗ lực cho một cái gì đó rất nhỏ ...

— Mr.Brownstone

Vì vậy, mặc dù tài khoản có SID bất ngờ, bạn nghĩ rằng thực sự không có vấn đề gì với nó và có an toàn khi bỏ qua nó trong sp_change_users_loginbáo cáo không?

— JustinStolle

Trong trường hợp này tôi sẽ nói như vậy, dựa trên thực tế là thực sự không có nhiều thứ bạn thực sự có thể làm về nó. Sau đó, có cuộc tranh luận kinh điển về việc bạn có nên / không nên sử dụng nó hay không, nhưng đó hoàn toàn là một câu hỏi khác ... :)

— Mr.Brownstone

Suy nghĩ của tôi ... Lý do sp_change_users_loginlà ném lỗi đó là vì MS cũng đã viết nó. [Nhìn qua mã thủ tục hệ thống mỗi giờ và sau đó có thể vui vẻ. :)] Tuy nhiên, thực tế là nó xuất hiện khi chạy báo cáo cho thấy ai đó / một số quá trình bị rối với tài khoản hoặc một bản sửa lỗi nóng có thể có từ MS có thể đã làm điều đó (bạn không bao giờ biết).

Tài khoản khách được cho là ở đó, nó tồn tại trong mọi cơ sở dữ liệu được tạo do tài khoản tồn tại theo mô hình theo mặc định. Làm cho nó không xuất hiện trong báo cáo có thể sẽ yêu cầu SID thay đổi trở lại thành 0x00tôi đoán. Miễn là tài khoản bị vô hiệu hóa tôi sẽ để nó một mình và bỏ qua nó. Nếu điều đó thực sự làm phiền tôi mặc dù tôi sẽ bỏ tiền ra và gọi điện với sự hỗ trợ của Microsoft.

Nói cách khác, bạn đang nói rằng đó không phải là vấn đề guestxuất hiện trong kết quả trong trường hợp này.

— JustinStolle

Khá nhiều, vâng.

Lưu ý: Bất cứ khi nào bạn di chuyển cơ sở dữ liệu của mình từ máy chủ này sang máy chủ khác, sẽ xảy ra sự cố người dùng mồ côi. FileListOnly là thuật ngữ mới trong máy chủ sql có tất cả các chi tiết của bản sao lưu được tạo mà ai có quyền truy cập vào nó.

Vì vậy, có chuỗi nhiệm vụ mà bạn phải tuân theo

Trước tiên, bạn phải khôi phục FileListOnly từ bản sao lưu đã tạo đến đích hoặc máy chủ mới.

Khôi phục lại bản sao lưu.

Sử dụng sp_change_usftimelogin theo nhu cầu. Để được trợ giúp về thủ tục này, bạn có thể tham khảo http://msdn.microsoft.com/en-us/l Library / ms174378.aspx .

Tôi đặt một ví dụ ở đây hy vọng nó sẽ giúp:

> RESTORE FILELISTONLY FROM DISK = N'C:\YourDB.bak'
> 
> RESTORE DATABASE YourDb FROM DISK = N'C:\YourDB.bak' WITH MOVE
> N'YourDB' TO N'D:\YourDB.mdf', MOVE N'YourDB_log' TO N'D:\YourDB.ldf',
> REPLACE
> 
> exec YourDB.dbo.sp_change_users_login 'update_one', 'UserName','UserName'

— JP Chauhan
nguồn

Điều này sẽ không làm việc cho guestngười dùng. Xem câu trả lời ở trên của Mr.Brownstone.

— Simon Righarts