1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
# Active Directory
Active Directory is Microsoft's on-premise IAM solution, first introduced in
Windows 2000.
## Features
1. A LDAP + Kerberos IAM but is extremely easy to manage. All features are
available in GUI MMCs.
2. Zero-cost replication. Spin up a new remote site or domain controller within
a few clicks, and AD will do all the complicated mutli-master distribution
stuff for you.
3. Industry standard in on-premise IAM. Think of it like the OAuth in web.
4. Advanced user / group / computer permission and authorization management.
5. Highly integrated with almost all Windows components, and Linux support is
also OK.
6. Has a mechanism to distribute policies to Windows clients (group policy).
Although it is much simpler than MDM solutions like SCCM.
7. Works on low bandwidth networks. ADDS is designed to work witn ADSL.
8. Strong compatibility. Windows 2000 workstation can easily join a Windows
server 2022 domain.
## Protocols
1. LDAP: The user / computer database. Also used to store lots of configuration
that needs to be replicated to the whole domain, like ADCS certificates and
templates, Windows activation objects, and other services data.
2. Kerberos: Single sign on. NTP is also required due to Kerberos. AD-joined
computers will all sync time from domain controllers.
3. DNS: Service discovery. All computers register their internal IP address to
the domain DNS server using the nsupdate protocol, protected by Kerberos. The
domain DNS also provides SRV records helping to locate the domain controller.
4. SMB: The sysvol (system volume) contains group policy files.
However, Windows 2000 is the period of Microsoft that strongly adheres to its EEE
strategy. Thus, its LDAP schema and Kerberos protocol are highly extended with
proprietary extensions.
## Architecture
1. Users, groups, and computers all live in a **domain**. Domain is the security
boundary.
2. Multiple domains can exist under a single **forest** with explicitly-set
trust relationships. No relationships between forests.
3. **Domain controller** is the server that runs the ADDS role (ntds.exe). It
is bascially a LDAP server + KDC + SMB (sysvol). It is commonly coupled with
the DNS server role. Multiple domain controller can exist in a domain (and is
recommended for availaiblity's concern). They do multi-master replication.
4. A domain can contain multiple **sites**. Sites represent physical locations
of an organiation, like an office. Sites are replication units. It is expected
that computers and domain controllers in a single site can contact with each
other really quick (on the same link, basically). Domain controllers within the
same site should be able to replicate instantly at any time. Site-to-site
replication, on the other hand, are expected to be slow, and even may not be
available all the time. Sites are bound with subnets (see the networking
section below), and proper design of sites will accelerate ADDS replication.
5. Group policy are registry values and files stored in both sysvol (the actual
policy data, like registry and files) and LDAP (GUID, linkage, and permission).
Multiple group policy objects exist in a single domain, and they may be linked
to organizational units, so computers and users within that OU will
automatically apply those policies.
## Networking
ADDS expects a private network. Back at Windows 2000's age it's pretty common
to trust the perimeter network, but zero-trust is much more prevalent today.
Although a secure public-facing LDAP + Kerberos server would be completely
doable using open-source solutions like OpenLDAP + MIT Kerberos, ADDS is never
designed to be exposed to the public Internet, and every security advior would
strongly against doing so. ADDS is designed with private networks and VPNs.
This is not only a security concern, but also the result of AD site hierarchy.
AD sites are bound with one or more private CIDR's. Computers choose its site
and the closest DC based on its IP address. Thus, each AD site must have a
dedicated subnet for efficient networking and replication.
## Client
Obviously, Windows itself is the best client. Windows is very good at credential
caching and roaming, so it is not pain at all for laptops to logon to the domain
over a VPN.
Unix clients are much worse. First of all, it takes time to support Microsoft's
proprietary LDAP schema, and only two implementations do that: Samba and SSSD.
Secondly, they are all poor at roaming. Linux laptops joined to a domain
usually fail to get Kerberos tickets after connecting to the network, or they
sometimes fail to update their DNS records.
SSSD and realmd is RedHat's attempt to create a Windows-like domain client
experience on Linux, and it indeed is better than Samba in terms of roaming and
caching, but it has lots of other problems, too. See the corresponding pages
for more detail.
## Alternative implementation
Due to widespread popularity, ADDS have open-source server-side implementations
as well. Samba is a open-source compatible clone of ADDS, and it supports up-to
functional level 2008 (the latest is 2016). It works well (except configuring
BIND9 with GSS is a huge pain). All management MMC works. It doesn't support AD
web services, so no PowerShell management.
|
