Sự khác biệt giữa tài khoản 'Hệ thống cục bộ' và tài khoản 'Dịch vụ mạng'?


386

Tôi đã viết một dịch vụ Windows tạo ra một quy trình riêng biệt. Quá trình này tạo ra một đối tượng COM. Nếu dịch vụ chạy trong tài khoản 'Hệ thống cục bộ' thì mọi thứ đều hoạt động tốt, nhưng nếu dịch vụ chạy trong tài khoản 'Dịch vụ mạng', quy trình bên ngoài sẽ khởi động nhưng không thể tạo đối tượng COM. Lỗi được trả về từ việc tạo đối tượng COM không phải là lỗi COM tiêu chuẩn (tôi nghĩ nó đặc trưng cho đối tượng COM được tạo).

Vậy, làm cách nào để xác định hai tài khoản, 'Hệ thống cục bộ' và 'Dịch vụ mạng' khác nhau như thế nào? Những tài khoản tích hợp này có vẻ rất bí ẩn và dường như không ai biết nhiều về chúng.

Câu trả lời:


701

Vì có quá nhiều nhầm lẫn về chức năng của các tài khoản dịch vụ tiêu chuẩn, tôi sẽ cố gắng nhanh chóng thực hiện.

Đầu tiên là các tài khoản thực tế:

  • Tài khoản LocalService (ưu tiên)

    Tài khoản dịch vụ hạn chế rất giống với Dịch vụ mạng và có nghĩa là chạy các dịch vụ đặc quyền tối thiểu tiêu chuẩn. Tuy nhiên, không giống như Dịch vụ mạng, nó truy cập mạng dưới dạng người dùng ẩn danh .

    • Tên: NT AUTHORITY\LocalService
    • tài khoản không có mật khẩu (mọi thông tin mật khẩu bạn cung cấp đều bị bỏ qua)
    • HKCU đại diện cho tài khoản người dùng LocalService
    • các đặc quyền tối thiểu trên máy tính cục bộ
    • trình bày thông tin ẩn danh trên mạng
    • SID : S-1-5-19
    • có hồ sơ riêng theo khóa đăng ký HKEY_USERS ( HKEY_USERS\S-1-5-19)

     

  • NetworkService tài khoản

    Tài khoản dịch vụ hạn chế có nghĩa là để chạy các dịch vụ đặc quyền tiêu chuẩn. Tài khoản này bị giới hạn hơn nhiều so với Hệ thống cục bộ (hoặc thậm chí là Quản trị viên) nhưng vẫn có quyền truy cập mạng dưới dạng máy (xem cảnh báo ở trên).

    • NT AUTHORITY\NetworkService
    • tài khoản không có mật khẩu (mọi thông tin mật khẩu bạn cung cấp đều bị bỏ qua)
    • HKCU đại diện cho tài khoản người dùng NetworkService
    • các đặc quyền tối thiểu trên máy tính cục bộ
    • trình bày thông tin đăng nhập của máy tính (ví dụ MANGO$) cho các máy chủ từ xa
    • SID : S-1-5-20
    • có hồ sơ riêng theo khóa đăng ký HKEY_USERS ( HKEY_USERS\S-1-5-20)
    • Nếu cố gắng lên lịch tác vụ bằng cách sử dụng nó, hãy nhập NETWORK SERVICEvào hộp thoại Chọn người dùng hoặc nhóm

     

  • Tài khoản LocalSystem (nguy hiểm, không sử dụng!)

    Tài khoản hoàn toàn đáng tin cậy, nhiều hơn tài khoản quản trị viên. Không có gì trên một hộp mà tài khoản này không thể thực hiện được và nó có quyền truy cập mạng dưới dạng máy (điều này yêu cầu Active Directory và cấp quyền cho tài khoản máy cho một cái gì đó)

    • Tên: .\LocalSystem(cũng có thể sử dụng LocalSystemhoặc ComputerName\LocalSystem)
    • tài khoản không có mật khẩu (mọi thông tin mật khẩu bạn cung cấp đều bị bỏ qua)
    • SID : S-1-5-18
    • không có bất kỳ hồ sơ nào của riêng nó ( HKCUđại diện cho người dùng mặc định )
    • nhiều đặc quyền trên máy tính cục bộ
    • trình bày thông tin đăng nhập của máy tính (ví dụ MANGO$) cho các máy chủ từ xa

     

Ở trên khi nói về việc truy cập mạng, điều này chỉ đề cập đến SPNEGO (Đàm phán), NTLM và Kerberos chứ không phải bất kỳ cơ chế xác thực nào khác. Ví dụ, xử lý chạy như LocalServicevẫn có thể truy cập internet.

Vấn đề chung với việc chạy dưới dạng tiêu chuẩn trong tài khoản hộp là nếu bạn sửa đổi bất kỳ quyền mặc định nào, bạn sẽ mở rộng tập hợp mọi thứ mà mọi thứ chạy như tài khoản đó có thể làm. Vì vậy, nếu bạn cấp DBO cho cơ sở dữ liệu, không chỉ dịch vụ của bạn có thể chạy như Dịch vụ địa phương hoặc Dịch vụ mạng truy cập cơ sở dữ liệu đó mà mọi thứ khác cũng chạy như những tài khoản đó. Nếu mọi nhà phát triển thực hiện việc này, máy tính sẽ có một tài khoản dịch vụ có quyền thực hiện mọi thứ thực tế (cụ thể hơn là siêu bộ của tất cả các đặc quyền bổ sung khác được cấp cho tài khoản đó).

Từ góc độ bảo mật luôn được ưu tiên để chạy như một tài khoản dịch vụ của riêng bạn, có chính xác các quyền bạn cần để làm những gì dịch vụ của bạn làm và không có gì khác. Tuy nhiên, chi phí của phương pháp này là thiết lập tài khoản dịch vụ của bạn và quản lý mật khẩu. Đó là một hành động cân bằng mà mỗi ứng dụng cần quản lý.

Trong trường hợp cụ thể của bạn, vấn đề mà bạn có thể gặp là việc kích hoạt DCOM hoặc COM + bị giới hạn trong một nhóm tài khoản nhất định. Trong Windows XP SP2, Windows Server 2003 và cao hơn quyền Kích hoạt đã bị hạn chế đáng kể. Bạn nên sử dụng snapin MMC của Dịch vụ Thành phần để kiểm tra đối tượng COM cụ thể của bạn và xem các quyền kích hoạt. Nếu bạn không truy cập bất cứ thứ gì trên mạng như tài khoản máy, bạn nên nghiêm túc xem xét sử dụng Dịch vụ cục bộ (không phải Hệ thống cục bộ, về cơ bản là hệ điều hành).


Trong Windows Server 2003, bạn không thể chạy một tác vụ theo lịch trình như

  • NT_AUTHORITY\LocalService (còn gọi là tài khoản Dịch vụ địa phương) hoặc
  • NT AUTHORITY\NetworkService (còn gọi là tài khoản Dịch vụ mạng).

Khả năng đó chỉ được thêm vào với Trình lập lịch tác vụ 2.0 , chỉ tồn tại trong Windows Vista / Windows Server 2008 và mới hơn.

Một dịch vụ đang chạy như NetworkServicethể hiện thông tin đăng nhập của máy trên mạng. Điều này có nghĩa là nếu máy tính của bạn được gọi mango, nó sẽ xuất hiện dưới dạng tài khoản máy MANGO$ :

nhập mô tả hình ảnh ở đây


7
Tôi nghĩ rằng Tài khoản dịch vụ được quản lý sẽ loại bỏ một số khó khăn khi thiết lập tài khoản và quản lý mật khẩu (hay đúng hơn là chuyển nó cho quản trị viên tên miền hoặc đại biểu.)
Carl G

1
Xin chào, cảm ơn đã giải thích. Mặc dù vậy, tôi có một câu hỏi - sử dụng tài khoản dịch vụ mạng / hệ thống cục bộ là có thể thêm / xóa các mục vào vùng chứa trong thư mục hoạt động (miễn là vùng chứa trong thư mục hoạt động đã cấp quyền đầy đủ cho máy tính mà các dịch vụ windows này đang chạy). Hãy lưu ý rằng tất cả mọi thứ đang làm việc, khi tôi chạy dịch vụ là một trong những người sử dụng tên miền, nhưng không phải là hệ thống local / dịch vụ mạng (để biết chi tiết stackoverflow.com/questions/20943436/... ) Kính trọng
Dreamer

1
Vâng, nó nên. Tôi sẽ trả lời câu hỏi của bạn trực tiếp vì câu hỏi này trừu tượng hơn và đó là một cách thực hiện cụ thể.
Peter Oehlert

7
Lưu ý rằng người dùng "ẩn danh" không chỉ, không phải là thành viên của "người dùng được xác thực", đó không phải là thành viên của "mọi người" trên Windows. Trên các mạng Windows, 'ẩn danh' chỉ có quyền truy cập vào các tài nguyên đã được cấp rõ ràng cho 'ẩn danh' - theo mặc định, không có gì.
David

1
@HakamFostok Tôi không có nhiều tài liệu tham khảo. Nếu tôi nhớ lại một cách chính xác, Dan Brown đã trình bày một vài điều trong cuốn sách Lập trình Windows Security của mình. Có rất nhiều trợ giúp trong windows và tài liệu MSDN nhưng tôi không có tài liệu tham khảo cụ thể. Cuốn sách của Jeff Richter trên các cửa sổ lập trình, cũng như Inside Windows (Ed thứ 3 hoặc thứ 4) của Soloman & Russinovich cũng có một số.
Peter Oehlert
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.