Làm cách nào để định cấu hình SQL Server 2012 để nó có thể khôi phục và xem các tệp trong tài khoản người dùng của tôi?


10

Tôi có một phiên bản SQL Server 2012 đang chạy như một dịch vụ trên máy tính của mình và theo trang dịch vụ, nó đăng nhập dưới dạng tài khoản "NT Service \ MSSQLSERVER". Tuy nhiên, tôi không thể thấy tên tài khoản đó ở bất kỳ nơi nào khác, kể cả trong khu vực "Người dùng và nhóm người dùng cục bộ" trong màn hình quản lý máy tính, bởi vì, như một liên kết bên dưới nói, đó không phải là Tài khoản người dùng, đó là tên dịch vụ, trong hộp đó Microsoft rất hữu ích dán nhãn "tài khoản". Lúc này tôi có thể thấy nhiều người đang bối rối.

Nhiệm vụ tôi đang cố gắng thực hiện là khôi phục các tệp bằng hộp thoại SSMS "Định vị tệp sao lưu", sử dụng hộp thoại hoàn toàn không giống với bất kỳ hộp thoại mở tệp windows tiêu chuẩn nào, có lẽ vì nó đang thực hiện công việc "từ xa" và hoạt động từ bối cảnh bảo mật của máy chủ SQL, một nguồn gây nhầm lẫn phong phú khác của người dùng cuối, mà tôi hy vọng câu hỏi này có thể giúp làm sáng tỏ.

Cho đến nay nếu tôi muốn khôi phục tệp .mdf / .bak sao lưu mà tôi có trong một trong các thư mục của mình, tôi phải đặt thư mục đó để mọi người có thể đọc được nếu không tôi không thể truy cập vào đó bằng SQL Server "Xác định vị trí sao lưu Cửa sổ tập tin ". Tôi thấy ý tưởng này là bạn đang sử dụng GUI nói chuyện với một dịch vụ có tài khoản và quyền người dùng khác với bạn, rằng không ai ở Microsoft quan tâm để làm rõ với bạn, rất khó hiểu ngay cả khi tôi có nhiều năm kinh nghiệm với quản trị hệ thống windows .

Tôi hy vọng tôi đã bỏ lỡ một số trang tài liệu cho SQL Server sẽ cho bạn biết, sau khi cài đặt phiên bản máy chủ SQL mới, cách bạn có thể thiết lập bảo mật.

Các bài đăng trên diễn đàn như thế này thậm chí có nhân viên của Microsoft nói rằng "điều này rất phức tạp" và nó "đã thay đổi, một lần nữa" ở Denali. Hiện tại nó hoạt động như thế nào trong SQL Server 2012 và làm cách nào tôi có thể thêm quyền đọc các tệp thuộc về Người dùng để bảo mật cho công cụ Cơ sở dữ liệu SQL SID.


Lý do SQL không sử dụng hộp thoại tiêu chuẩn là vì vậy bạn không thể chọn tệp mà SQL không thể đọc được. Về cách định cấu hình bảo mật, bạn có sẵn sàng thay đổi tài khoản mà SQL chạy theo không hoặc bạn có muốn để nó theo cách hiện tại không? Nếu thay đổi tài khoản dịch vụ là ổn thì điều này rất dễ chăm sóc. Chúng tôi sử dụng các tài khoản được đặt tên để tôi không thể kiểm tra tài khoản MSSQLSERVER chung chung để giúp điều đó.
cfradenburg


Nếu mọi người thay đổi Máy chủ SQL của họ để chạy với ID người dùng thông thường khi thực hiện phát triển, đó có thể là "cách thực hành tốt nhất". Tôi chỉ tự hỏi liệu đó có phải là một ý tưởng tốt hay không. Nếu thêm thủ công "NT Service \ MSSQLSERVER" vào các thư mục tôi cần thêm vào là ý tưởng chuẩn, tôi đoán đó sẽ là cách khắc phục tối thiểu hợp lý nhất, phải không? Tôi muốn là UI SSMS của máy chủ SQL dễ dàng hơn một chút để kết nối với id tài khoản "NT Server \ xxx" ẩn này.
Warren P

Câu trả lời:


5

Để tham khảo "Denali" là SQL Server 2012. Liên quan đến "sự nhầm lẫn của người dùng cuối", tôi không quan tâm đến việc người dùng cuối có bị nhầm lẫn hay không liên quan đến SSMS. Microsoft đã không phát triển công cụ này cho người dùng cuối bình thường, nhưng dành cho người quản trị cơ sở dữ liệu và / hoặc người dùng phải quản lý cơ sở dữ liệu. Do đó, sẽ có một đường cong học tập với các công cụ được cung cấp và cách chúng hoạt động. Hộp thoại tệp đã xuất hiện theo cách đó trong SSMS kể từ khi SSMS xuất hiện cùng với SQL Server 2005. Đây là lý do tại sao bạn thường thấy hầu hết gắn bó với các câu lệnh T-SQL để sao lưu, khôi phục hoặc đính kèm cơ sở dữ liệu đã sử dụng nó kể từ đó .

Để định cấu hình quyền hệ thống tệp với SQL Server, bạn có thể làm theo hướng dẫn từ MSDN tại đây .

Cách xử lý tài khoản dịch vụ không đi kèm hoặc do SQL Server, đó là do sự thay đổi ở cấp độ hệ điều hành. Window Server 2008 R2 đặt thêm một chút lớp bảo mật xung quanh các tài khoản dịch vụ. Ưu điểm bạn có là tài khoản dịch vụ có thể dễ dàng truy cập tài nguyên hơn trên một tên miền ngay cả khi được cài đặt với các cài đặt mặc định. Liên kết này cung cấp một cái nhìn khá chi tiết về cách xử lý các quyền của tài khoản dịch vụ với SQL Server 2012. Trích từ liên kết bên dưới trên Tài khoản ảo được sử dụng theo mặc định trong SQL Server 2012. Ngoài ra còn có một liên kết được cung cấp trong bài viết đi sâu vào thảo luận về khái niệm Tài khoản dịch vụ với Windows, tại đây. Đó là từ Window Server 2008 R2 nhưng tôi tin rằng nó vẫn đúng trên Window Server 2012 và có khả năng Window Server 2012 R2.

Tài khoản ảo

Tài khoản ảo trong Windows Server 2008 R2 và Windows 7 được quản lý các tài khoản cục bộ cung cấp các tính năng sau để đơn giản hóa việc quản trị dịch vụ. Tài khoản ảo được quản lý tự động và tài khoản ảo có thể truy cập mạng trong môi trường miền. Nếu giá trị mặc định được sử dụng cho các tài khoản dịch vụ trong khi thiết lập SQL Server trên Windows Server 2008 R2 hoặc Windows 7, một tài khoản ảo sử dụng tên đối tượng làm tên dịch vụ được sử dụng, theo định dạng NT DỊCH VỤ \. Các dịch vụ chạy dưới dạng tài khoản ảo truy cập tài nguyên mạng bằng cách sử dụng thông tin đăng nhập của tài khoản máy tính ở định dạng \ $. Khi chỉ định tài khoản ảo để khởi động SQL Server, hãy để trống mật khẩu. Nếu tài khoản ảo không đăng ký Tên hiệu trưởng dịch vụ (SPN), hãy đăng ký SPN theo cách thủ công. Để biết thêm thông tin về việc đăng ký SPN theo cách thủ công, hãy xem Đăng ký tên hiệu trưởng dịch vụ cho các kết nối Kerberos. Lưu ý Lưu ý Không thể sử dụng tài khoản ảo cho Trường hợp cụm chuyển đổi dự phòng SQL Server, vì tài khoản ảo sẽ không có cùng SID trên mỗi nút của cụm.

Bảng sau liệt kê các ví dụ về tên tài khoản ảo.

Phiên bản mặc định của dịch vụ Công cụ cơ sở dữ liệu: NT SERVICE \ MSSQLSERVER Phiên bản được đặt tên của dịch vụ Công cụ cơ sở dữ liệu có tên PAYROLL: NT SERVICE \ MSSQL $ PAYROLL Dịch vụ đại lý máy chủ SQL trên phiên bản mặc định của SQL Server: NT SERVICE \ SQLSERVERAGENT Dịch vụ đại lý SQL trên một máy chủ phiên bản của SQL Server có tên PAYROLL: NT SERVICE \ SQLAGENT $ PAYROLL


3
Theo người dùng cuối, tôi có nghĩa là bất kỳ trong số hàng chục loại người, một số người khá chuyên nghiệp và có năng lực kỹ thuật trong các ngành khác nhau, nhưng những người KHÔNG thể là DBA. Cá nhân tôi nghĩ rằng ngay cả các DBA cũng sẽ thấy rằng UI trên công cụ này có thể được cải thiện. Thị trường công cụ bên thứ ba mạnh mẽ là một chỉ số khác cho thấy SSMS, trong khi miễn phí, hoàn toàn xứng đáng với giá tiền.
Warren P

1
Trong năm 2017, nó đã không nhận được bất kỳ tốt hơn. Vì vậy, câu trả lời ngắn gọn là "sẽ không bao giờ trở nên tốt hơn, hãy tìm hiểu cách thức hoạt động của nó, tuy nhiên giao diện người dùng được thiết kế kém".
Warren P

2

Để xem / truy cập các tệp trong thư mục khác, hãy cấp NT SERVICE\MSSQLSERVERquyền trên thư mục. Xem câu trả lời của tôi được đăng trên tệp .bak không hiển thị trong bất kỳ thư mục nào trong SSMS để chụp ảnh màn hình và các bước liên quan. (Khác một chút so với việc thêm quyền người dùng / nhóm thông thường vào một thư mục.)

Mong rằng sẽ giúp!


1

Trên thực tế, nếu bạn cố gắng thực hiện khôi phục qua SSMS và bạn đã đăng nhập thông qua Xác thực Windows (!), Đó sẽ là tài khoản Windows CỦA BẠN (chứ không phải "tất cả mọi người) cần có quyền đối với điều đó - KHÔNG phải là Dịch vụ máy chủ SQL Tài khoản. Hy vọng sẽ xóa sự nhầm lẫn. Tài khoản dịch vụ có các nhu cầu khác. Ví dụ: nếu bạn đã đăng nhập thông qua Tài khoản xác thực SQL - thì hệ điều hành nên yêu cầu quyền gì? - Đây sẽ là Tài khoản dịch vụ của SQL Server trong này trường hợp duy nhất! Điều này đã không thay đổi kể từ SQL Server 7.0 và có lẽ thậm chí không trước đó :)



Tôi không chắc chắn sẽ xóa được sự nhầm lẫn ... Nếu bạn đã đăng nhập qua WA, tài khoản SQL Server của bạn cần có quyền để khôi phục (theo như SQL Server có liên quan), nhưng tài khoản dịch vụ SQL Server cần có quyền đọc trên hệ thống tệp để mở .baktệp (thường không có trong thư mục người dùng của bạn, trừ khi được cấp rõ ràng).
Bruno
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.