Windows Domains
Là một tập các người dùng và máy tính được quản trị tập trung bởi một active directory (AD). Server chạy AD có tên là domain controller (DC).
Windows domains được sinh ra để giải quyết vấn đề quản lý danh tính (indentity management) và các chính sách bảo mật (security policy) của nhiều người dùng và máy tính trong một tổ chức.
Active Directory
Các đối tượng (objects) tồn tại trong AD bao gồm: users, groups, machines, printers, shares, etc.
Security principals là những đối tượng được xác thực bởi domain và được gán các đặc quyền trên các tài nguyên chẳng hạn như tập tin hoặc máy in.
Users được xem như là security principals và thể hiện 2 thứ:
- Con người
- Dịch vụ chẳng hạn như IIS hoặc MSSQL
Machines cũng được xem như là security principals và được gán với một machine account.
Security groups bao gồm nhiều user và việc gán user vào security group sẽ khiến cho user đó kế thừa tất cả các đặc quyền đã được cấp cho security group.
Security groups có thể chứa user, machine hoặc những group khác.
Có một số security groups mặc định: Active Directory security groups | Microsoft Learn. Ví dụ:
Security Group | Description |
---|---|
Domain Admins | Users of this group have administrative privileges over the entire domain. By default, they can administer any computer on the domain, including the DCs. |
Server Operators | Users in this group can administer Domain Controllers. They cannot change any administrative group memberships. |
Backup Operators | Users in this group are allowed to access any file, ignoring their permissions. They are used to perform backups of data on computers. |
Account Operators | Users in this group can create or modify other accounts in the domain. |
Domain Users | Includes all existing user accounts in the domain. |
Domain Computers | Includes all existing computers in the domain. |
Domain Controllers | Includes all existing DCs on the domain. |
Active Directory Users and Computers
Để cấu hình users, groups hoặc machines, ta cần dùng công cụ “Active Directory Users and Computers”.
Các đối tượng sẽ được tổ chức theo các organizational units (OU). Mỗi OU sẽ có các chính sách khác nhau. Ví dụ, chính sách của OU dành cho Sales sẽ khác với chính sách của OU dành cho IT.
Chúng ta có thể thực hiện một số thao tác nhất định với các đối tượng trong OU chẳng hạn như thêm, xóa, sửa hoặc thậm chí là reset password.
Bên trong một OU có thể sẽ có những OU khác.
Các thành phần khác được tạo mặc định bởi Windows:
- Builtin: các group mặc định áp dụng cho Windows host bất kỳ
- Computers: các machine mới thêm vào network
- Domain Controllers: các DC ở trong network
- Users: các user và group mặc định
- Manages Service Accounts: các tài khoản mà được sử dụng bởi các dịch vụ bên trong Windows domain
Sự khác biệt giữa security group và OU:
- OU: dùng để áp dụng các chính sách cho các user. Mỗi user chỉ có thể ở trong một OU tại một thời điểm
- Security group: dùng để cấp quyền trên các tài nguyên. Mỗi user có thể ở trong nhiều security group tại một thời điểm
Managing Users in AD
Để xóa một OU, chúng ta cần bật “Advanced Features” thông qua “View” chứ không được xóa một cách thông thường. Windows làm vậy là để tránh việc vô tình xóa. Sau đó, chọn “Properties”, chuyển sang tab “Object” rồi bỏ tick “Protect object from accidental deletion”.
Chúng ta có thể ủy quyền cho một user để thực hiện những tác vụ cho các user trong một OU nào đó chẳng hạn reset password thông qua tính năng “Delegate Control”.
Người dùng được ủy quyền có thể không truy cập được “Active Directory Users and Computers” để thực hiện reset password. Trong trường hợp này, người dùng đó có thể sử dụng PowerShell:
Sau đó, ta sẽ yêu cầu người dùng thay đổi password trong lần đăng nhập kế tiếp như sau:
Managing Computers in AD
Các machine mới thêm vào network mặc định sẽ ở trong container “Computers”.
Chúng ta nên phân chia các machine thành các OU sau:
- Workstations: dùng để làm việc và không yêu cầu tài khoản đặc quyền để sử dụng
- Servers: cung cấp các dịch vụ
- Domain Controllers: quản lý AD. Là các thiết bị nhạy cảm vì nó chứa tất cả các hashed password của các tài khoản
Ví dụ:
Group Policies
Sau khi đã phân chia users và machines ra các OU, chúng ta sẽ áp dụng các chính sách cho các user và machine đó tùy vào OU mà chúng thuộc về.
Windows quản lý các chính sách sử dụng Group Policy Objects (GPO). Nó chỉ đơn giản là một tập các cài đặt mà có thể áp dụng cho các OU.
Để cấu hình GPO, ta cần dùng công cụ “Group Policy Management”. Công cụ này sẽ có các thư mục phân cấp tương tự như công cụ “Active Directory Users and Computers”:
Cấu hình GPO ở trong mục “Group Policy Objects” rồi liên kết với OU mà ta muốn áp dụng GPO.
Trong hình trên, ta thấy có 3 GPO đã được liên kết: “Default Domain Policy” và “RDP Policy” được liên kết với domain thm.local
còn “Default Domain Controllers Policy” thì được liên kết với OU có tên là “Domain Controllers”.
Note
Cần chú ý rằng các GPO cũng sẽ được áp dụng cho các sub-OU.
Chúng ta có thể áp dụng GPO cho các user và machine cụ thể trong OU thông qua tính năng “Security Filtering” ở trong tab “Scope”. Mặc định thì sẽ áp dụng cho “Authenticated Users” group, tương ứng với tất cả các user/machine:
Chúng ta xem các cấu hình của GPO ở tab “Settings”:
Có thể thấy, “Default Domain Policy” chỉ có các cấu hình áp dụng cho machines.
Mỗi cấu hình có thể có nhiều thuộc tính:
GPO Linking
Chúng ta kéo GPO vào OU để liên kết.
GPO Distribution
Các GPO được phân phối đến network thông qua một share của DC có tên là SYSVOL
. Tất cả các machine ở trong domain cần phải có quyền truy cập vào share này để đồng bộ các GPO một cách thường xuyên. Địa chỉ mặc định của SYSVOL
là C:\Windows\SYSVOL\sysvol\
trên từng DC ở trong network.
Sau khi GPO bị thay đổi, cần khoảng gần 2 tiếng để các machine đồng bộ. Nếu muốn cập nhật một máy nào đó cụ thể, ta có thể chạy lệnh sau ở trên máy đó:
Authentication Methods
Các hashed password sẽ được lưu ở DC. Khi một user muốn thực hiện việc xác thực với một service nào đó sử dụng domain credentials, service đó sẽ gửi yêu cầu đến DC nhằm kiểm tra xem các credential đó là đúng.
Có 2 loại giao thức xác thực được sử dụng:
- Kerberos: mới
- NetNTLM: cũ
Kerberos Authentication
User khi đăng nhập vào service sẽ được cung cấp một ticket, là minh chứng cho việc user đó đã thực hiện việc xác thực và có thể sử dụng service.
Quá trình xác thực diễn ra như sau:
-
User gửi username và timestamp được mã hóa bằng password hash của user đến Key Distribution Center (KDC) service được cài đặt ở trên DC. KDC có nhiệm vụ tạo ra các Kerberos ticket trong network.
-
KDC tạo ra và gửi lại Ticket Granting Ticket (TGT) cho phép user có thể yêu cầu ticket cho các service cụ thể khác. TGT giúp giảm thiểu việc gửi lại credentials. Cùng với TGT, KDC cũng sẽ gửi lại Session Key, dùng để tạo ra các yêu cầu tiếp theo.
-
Khi user muốn kết nối đến một service cụ thể trong network chẳng hạn như share, website hoặc database thì sẽ gửi TGT đến KDC để yêu cầu Ticket Granting Service (TGS). Ngoài TGT thì user còn cần phải gửi username và timestamp được mã hóa bởi Session Key cùng với Service Principal Name (SPN) cho biết service và server name mà user cần kết nối.
-
KDC sẽ gửi lại TGS cùng với Service Session Key để mã hóa trên đường truyền giữa user và service. TGS sẽ được mã hóa bởi Service Owner Hash( Service Owner là user/machine chạy service). TGS cũng sẽ chứa bản sao của Service Session Key và có thể được giải mã bởi Service Owner.
-
Cuối cùng, user gửi TGS đến service để thực hiện xác thực và thiết lập kết nối. Service sẽ sử dụng Service Owner Hash để giải mã TGS và kiểm tra Service Session Key.
NetNTLM Authentication
Sử dụng cơ chế challenge-response:
Note
Hình trên mô tả việc xác thực sử dụng domain account. Trong trường hợp sử dụng local account, server có thể tự xác thực mà không cần tương tác với DC vì nó có lưu password hash ở trong SAM.
Trees, Forests and Trusts
AD có thể mở rộng ra thành các subdomain, đặc biệt là khi cần phân vùng một network của công ty mà có trụ sở ở nhiều quốc gia. Khi đó, các domain sẽ tạo thành một Tree:
Có thể thấy, mỗi subdomain sẽ có một DC riêng để quản lý subdomain đó.
Nếu network mở rộng ra đến mức có nhiều tree, mỗi tree tương ứng với 1 domain thì khi đó sẽ hình thành nên forest:
Khi một user tại domain uk.thm.local
muốn truy cập vào một file của asia.mht.local
(khác domain) thì cần phải thiết lập một trust relationship. Có hai loại trust relationship:
- One way: domain AAA tin tưởng domain BBB thì BBB sẽ có thể truy cập vào tài nguyên của AAA.
- Two way: việc kết nối nhiều domain lại với nhau mặc định sẽ hình thành nên kiểu quan hệ này.
Note
Việc thiết lập trust relationship không đồng nghĩa với việc cấp quyền truy cập.