AD intro

1 files changed, 99 insertions, 0 deletions

diff --git a/docs/sysadmin/iam/adds/index.md b/docs/sysadmin/iam/adds/index.md
index f4d0f18..aa1cc86 100644
--- a/docs/sysadmin/iam/adds/index.md
+++ b/docs/sysadmin/iam/adds/index.md
@@ -1 +1,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.