Windows Server 2019域控搭建与Kali Linux入域验证指南

最近有个搞运维的朋友问我说想把Windows Server 2019主域控制器在自己虚拟机里跑起来又不确定Kali Linux在整套环境里能干什么。我干脆把前两天刚搭好的一套环境拿出来讲透从Windows Server 2019那边装AD DS、提升域控到Kali作为客户端加域、验证DNS和Kerberos票据一个环节一个环节拆开说。整个实验做下来最大的感受就是域控本身不难搭真正考验人的是DNS、时间同步、主机名这些基础配置。这篇文章适合正在学AD域控的运维新手也适合想让Linux终端体验Windows域认证场景的安全测试人员。1. 实验环境设计与整体思路拆解1.1 为什么选择这套组合Windows Server 2019是目前生产环境里比较常见的服务器系统它在AD Domain Services上的表现稳定管理工具也成熟。Kali Linux虽然多数时候被当成渗透测试发行版但在这个实验里我更愿意把它当作一个“挑剔的验收员”来用——它不是去攻击域控而是站在一台普通Linux客户端的角度去验证域控是否正常工作。很多教程只讲“在Windows上装域控”最后就让你拿一台Windows电脑加个域试试结果所有现象都发生在Windows生态里你根本看不到底层协议怎么工作。Kali加入后就不一样了你可以通过Kerberos票据、LDAP查询、DNS SRV解析这些方式直接感受到域环境的运行机制。另外标题里提到“编程”其实指的并不是写什么高深程序而是用PowerShell和Bash脚本把整个部署过程自动化。图形化操作当然也能建域控但脚本化的方式更适合可重复落地的实验你在生产环境里也不可能每次都用鼠标点几十个界面。1.2 主域控制器在实验环境里扮演什么角色主域控制器PDC是一台承载Active Directory数据库的中心服务器。整个域内的用户账号、计算机账号、组策略、DNS记录全都跟它有关。你可以把它理解成公司里的行政前台所有人入职都要在它那里登记信息进门要刷工牌验证身份门禁规则也由它统一制定。在这个实验里域控承担的具体任务有三块身份认证中心Windows和Linux客户端都通过Kerberos协议来和域控完成认证。DNS解析核心客户端要找到域控不是靠猜IP而是通过DNS里的SRV记录来定位。集中策略入口虽然实验里不涉及复杂的组策略但从这里可以延伸出GPO下发、用户权限分配等管理场景。搭建域控不是为了让虚拟机跑得多花哨而是为了把一个企业内网里最基础的认证骨架搭出来让后续的权限管理、安全策略都有地方落脚。1.3 虚拟化网络怎么规划才不乱很多人在这一步翻车。我建议不要直接用NAT模式因为NAT模式下虚拟机和宿主机共享网络域控和Kali之间的通信路径不够干净域名解析也容易被外部DNS干扰。我这次用的是VMware Workstation里的自定义VMnet网络相当于给两台虚拟机建了一个独立的小局域网。配置建议如下项目Windows Server 2019DC01Kali LinuxKALI01内存4 GB2 GBCPU2核2核磁盘60 GB40 GB网络模式自定义VMnet仅主机自定义VMnet仅主机IP地址192.168.100.10192.168.100.20子网掩码255.255.255.0255.255.255.0网关192.168.100.1192.168.100.1DNS192.168.100.10192.168.100.10有一个原则必须记住整个实验环境里所有客户端的DNS都必须指向域控本身。如果Kali的DNS指向了路由器地址那它根本解析不了lab.local这个内部域名后面所有加域操作都会失败。2. 域控搭建前必须搞懂的核心细节2.1 静态IP和主机名小步骤里的大坑域控的IP必须是固定的。如果域控本身用DHCP获得地址一旦IP变化客户端就找不到认证服务器了。这个道理谁都懂但实际操作里经常见到有人先把域控搭好了回过头才发现网卡还停留在“自动获取IP”状态。主机名同样重要。AD域一旦建立域控的计算机名就是它在域里的标识后期改名会牵连很多服务。我建议在安装AD DS角色之前就把主机名改成规划好的名字。在Windows Server 2019里改计算机名最简单的方式是通过Server Manager打开“本地服务器”。点击当前计算机名后面的“无法访问”之类提示。在“系统属性”中选择“更改”输入DC01。系统提示重启点“立即重启”。重启后再继续装AD DS。这个顺序不要颠倒因为域控提升过程中系统会根据计算机名生成服务主体名称先改好名能省掉很多麻烦。2.2 DNS才是域控的灵魂很多人以为装域控就是装一个功能角色其实真正复杂的是DNS。Active Directory和DNS的绑定深度超出一般人的预期客户端在加入域的时候要查询域控的SRV记录登录的时候也要通过DNS定位域控。在安装AD DS角色的过程中系统会询问是否一起安装DNS服务器。这一步建议选择“是”。随后在提升为域控时向导会自动为lab.local区域生成对应的记录。要理解这件事你只需要记住一个公式客户端要加入域先问DNS“域控在哪里”DNS回答“192.168.100.10”客户端再去访问那台服务器。如果DNS答不上来加域必然失败。所以前期的网络规划里我把DNS指向写得非常清楚。我遇到过一个特别典型的情况有人在Windows客户端的网卡里填了8.8.8.8作为备选DNS结果为了排错花了两小时都没找到原因。实验环境里不需要外部DNS不要给它任何机会走出这个小局域网。2.3 图形向导和PowerShell脚本怎么选搭建AD DS角色两种方式都能完成但适合的场景完全不同。图形化方式的优势是直观适合第一次接触域控的读者。Server Manager的向导会一步一步引导就算不知道某个参数的含义也能根据提示往下走。缺点也很明显步骤重复、难以记录如果你想重新搭一遍还得重新点一遍。PowerShell方式则适合已经熟悉流程、追求效率的人。脚本可以保存下来变成自己的部署模板以后几台服务器批量初始化的时候特别省事。我的建议是第一次搭用图形化方式走一遍理解每一步在干什么第二遍开始直接写脚本。这也是我标题里“编程”二字的体现——把运维经验转化成可复用的代码比单纯会点鼠标值钱得多。3. Windows Server 2019 主域控完整搭建实录3.1 图形化方式一步步跑通我把这次实际操作的过程完整记录下来每一步都标注了关键点。第一步配置静态IP。在“网络连接”里右键网卡进入“Internet协议版本4TCP/IPv4”属性填入规划好的地址192.168.100.10子网掩码255.255.255.0网关192.168.100.1。首选DNS先填192.168.100.10也就是域控自己的内网地址。第二步修改计算机名为DC01。第三步添加角色和功能。打开Server Manager点击“管理”菜单选择“添加角色和功能”。在“服务器角色”页面里勾选“Active Directory域服务”。系统会弹出一堆依赖功能的提示直接确认。安装过程大概几分钟结束后服务器会提示需要提升为域控制器。第四步提升为域控。点击Server Manager通知区里的黄色感叹号图标选择“将此服务器提升为域控制器”。这一步要注意部署操作选择“添加新林”。根域名填lab.local。林功能级别和域功能级别选择Windows Server 2016或更高。功能级别决定了域内可用的高级特性不是越高越好要考虑兼容性。设置DSRM还原密码这个密码一定要记牢忘记的话后期做目录恢复会很痛苦。在DNS选项页面系统会提示创建DNS委派保持默认即可。第五步检查先决条件。向导会做一次健康检查如果没报错就可以点“安装”。安装完成后系统自动重启。等再次登录进去Server Manager左上角能看到“AD DS”和“DNS”两个服务。3.2 PowerShell脚本化搭建的完整代码图形化操作习惯之后我建议把整个流程交给PowerShell。这次实测的命令如下# 设置静态IP网卡名称请根据实际环境替换 New-NetIPAddress -InterfaceAlias Ethernet0 -IPAddress 192.168.100.10 -PrefixLength 24 -DefaultGateway 192.168.100.1 Set-DnsClientServerAddress -InterfaceAlias Ethernet0 -ServerAddresses 192.168.100.10 # 修改计算机名 Rename-Computer -NewName DC01 -Restart重启后以管理员身份打开PowerShell安装AD DS角色Install-WindowsFeature AD-Domain-Services -IncludeManagementTools随后提升为域控。注意密码字符串需要转成安全字符串$safeModePassword ConvertTo-SecureString YourDSRMPassword123! -AsPlainText -Force Install-ADDSForest -DomainName lab.local -DomainNetbiosName LAB -ForestMode Win2016 -DomainMode Win2016 -SafeModeAdministratorPassword $safeModePassword -InstallDns:$true解释几个参数的含义DomainNetbiosName是指域的NetBIOS名称这里用LAB。ForestMode和DomainMode决定了功能等级Win2016代表Windows Server 2016模式。InstallDns设置为$true让系统自动安装并配置DNS。整个脚本执行完系统同样会自动重启。这种方式的优势是你只需要把IP和域名换成自己的就能在另一台服务器上完全复刻。3.3 创建域账号和验证环境域控启动后我先创建了一个测试用户后续Kali加域和验证认证就用这个账号。PowerShell一样可以做New-ADUser -Name testuser -SamAccountName testuser -UserPrincipalName testuserlab.local -Path CNUsers,DClab,DClocal -AccountPassword (ConvertTo-SecureString Pssw0rd123 -AsPlainText -Force) -Enabled $true创建完成后用以下命令确认用户已经写入AD数据库Get-ADUser -Filter SamAccountName -eq testuser到这一步Windows Server 2019侧的主域控制器状态已经正常。接下来就是让Kali这台Linux机器加入域从另一端验证整个环境是否真的可用。4. Kali Linux 客户端配置与入域验证4.1 先把Kali的网络参数收拾干净Kali默认使用DHCP获取地址这在实验环境里不行。我先把它的IP改成静态的。Debian系的网络配置最顺手的方式是用nmclisudo nmcli con mod Wired connection 1 \ ipv4.addresses 192.168.100.20/24 \ ipv4.gateway 192.168.100.1 \ ipv4.dns 192.168.100.10 \ ipv4.method manual sudo nmcli con up Wired connection 1改完IP后再改主机名sudo hostnamectl set-hostname kali01然后手动编辑/etc/hosts文件把两台机器的主机名和IP映射写进去192.168.100.10 dc01.lab.local dc01 192.168.100.20 kali01.lab.local kali01这一步很不起眼但能避免后面解析混乱。很多人在Kali上加域失败就是因为文件名、映射这些细节没处理干净。确认一下/etc/resolv.conf里面的DNS是不是已经指向192.168.100.10。如果是其他地址就手动改掉或者重新触发nmcli的更新。4.2 用realmd加入Windows域Kali有不少方式可以加入Windows域我优先使用realmd加sssd这套组合因为配置相对友好。先安装相关组件sudo apt update sudo apt install realmd sssd samba-common krb5-user adcli ldap-utils然后直接执行加入域操作sudo realm join -U administratorlab.local lab.local执行过程中会提示输入管理员密码。如果你在Kali端看到的不是“Successfully enrolled machine in realm”而是几行报错别急着怀疑命令先检查两类问题DNS是否指向域控、系统时间是否和域控差太多。加入成功后用下面命令确认状态realm list输出里会显示realm名称、域控制器位置、登录策略这些信息。再验证一下域用户是否能被正常识别id testuserlab.local如果Kali能正确读取到testuser的uid和所属组说明SSSD到AD的链路已经通了。4.3 用Samba的net命令作为替代方案有些环境下realmd可能缺依赖或者配置不顺这时候可以换用Samba的传统工具。先安装Samba客户端sudo apt install samba-client然后编辑/etc/samba/smb.conf加上以下几行[global] workgroup LAB realm LAB.LOCAL security ADS接着执行sudo net ads join -U administratorlab.local这个方式的原理有点不一样它直接通过Samba的ADS客户端机制去联系域控所用的认证流程还是Kerberos和LDAP。只要能成功加入域效果和realmd是一样的。不过从长期管理角度看SSSD的方案更适合需要本地缓存、离线登录的场景net ads join更适合一次性的身份登记。4.4 获取Kerberos票据和LDAP查询验证加域成功后我要做的第一件事就是在Kali上拿到域用户的Kerberos票据这是判断认证链路是否正常的最直接证据。kinit testuserLAB.LOCAL注意这里的域名要大写因为Kerberos realm对大小写敏感。执行后查看票据klist正常情况下能看到类似这样的输出Ticket cache: FILE:/tmp/krb5cc_0 Default principal: testuserLAB.LOCAL Valid starting Expires Service principal ...出现票据说明Kali和域控之间完成了Kerberos认证时间同步、DNS解析都已经正常。还可以用ldapsearch查询域控里的用户信息ldapsearch -x -H ldap://dc01.lab.local -b dclab,dclocal (objectClassuser) sAMAccountName这条命令会返回域内所有用户对象的sAMAccountName列表我们创建的testuser就在里面。看到这个结果基本上可以断定整个域环境已经跑通。4.5 回到域控侧检查Kali的计算机对象验证从来不是单方向的。我在DC01上也查了一下确认Kali这台机器已经作为计算机对象写进AD数据库。在Windows Server 2019的PowerShell里执行Get-ADComputer -Filter Name -eq KALI01 -Properties OperatingSystem如果一切正常输出里能看到KALI01的DN路径和OperatingSystem字段。Linux机器加入Windows域后AD计算机对象的OperatingSystem属性往往会显示系统版本字符串这是AD从客户端上报信息里读到的。到此主域控搭建和Linux客户端认证的完整闭环就验证结束了。5. 常见故障排查与避坑指南5.1 场景一域控提升时DNS先决条件检查报错这是我在新手阶段踩过最多次的坑。提升向导里提示“无法创建DNS委派”或者“DNS服务器不存在”大概率是网卡的DNS地址没有指向自己。解决方法是回到网络连接把首选DNS改成192.168.100.10然后重新打开提升向导。输入ipconfig /all确认当前DNS配置别凭印象。提示AD域控的DNS指向自己这个原则在任何版本Windows Server上都适用。别指望临时用外部DNS也能通过先决条件检查这是一个硬性依赖。5.2 场景二Kali加域报“域不存在”现象是realm join时提示找不到lab.local这个域。排查顺序很重要执行ping dc01.lab.local确认域名能解析。查看/etc/resolv.conf确认DNS是192.168.100.10。用DNS查询验证SRV记录是否存在命令是host -t SRV _ldap._tcp.lab.local如果返回的记录里有dc01.lab.local说明DNS侧没问题。如果查询失败去检查域控上的DNS服务器是否正常工作。5.3 场景三Kerberos票据报时钟漂移Kerberos协议对时间同步要求很严格一般要求客户端和服务器之间的时间差不能超过5分钟。如果kinit时报“Clock skew too great”说明Kali的时间和域控差太多。解决方法是同步时间sudo apt install ntpdate -y sudo ntpdate 192.168.100.10正式一点的做法是配置chrony服务让它持续跟随域控的时间。实验环境里临时同步一次已经够用。这个坑很隐蔽因为Kali默认的时间源可能被其他服务接管看起来时间“差不多”实际上已经偏出安全阈值。5.4 场景四Windows防火墙挡住LDAP和Kerberos如果Kali已经成功加入域但ldapsearch或者后续的一些验证操作超时先考虑防火墙是否拦了相关端口。AD域服务需要用到不少端口最常见的是TCP 389LDAP查询TCP 88Kerberos认证TCP 135RPC端点映射TCP 445SMB文件共享在隔离的虚拟机实验环境里可以先临时关闭Windows防火墙来定位问题。生产环境千万不要直接关防火墙正确的做法是放行上述端口并且限制来源IP。5.5 故障排查速查表现象可能原因处理方向域控提升时DNS报错网卡DNS未指向自己设置首选DNS为192.168.100.10Kali解析不了lab.localresolv.conf里的DNS不正确修改DNS指向域控内网地址realm join报域不存在DNS SRV记录缺失或时间偏移检查DNS解析和时间同步kinit提示Clock skew too great客户端与域控时间差超过5分钟用ntpdate或chrony同步时间ldapsearch连接超时防火墙拦截389端口实验环境可临时关闭防火墙定位Get-ADComputer查不到Linux机器加入域后未重新初始化SSSD重启Kali或重新执行realm join5.6 几个值得养成的操作习惯我这次搭建过程中最大的感触就是规划先行。前期把IP、主机名、域名这三个东西定死后面每一步都顺很多。临时起意改一个参数往往会连带出DNS、Kerberos、AD对象注册三四个关联问题。另外虚拟机的快照功能一定要用起来。在Windows Server 2019安装完系统、还没提升域控之前打一个快照在Kali加域成功之后再打一个快照。这样一来后面想复现故障或者练习重装都只需要一瞬间回滚不用重新从零开始。最后分享一个小技巧域控上执行完PowerShell命令如果发现中文字符显示成乱码或者命令输出没有格式化先在控制台窗口执行chcp 65001这个命令把控制台代码页切换成UTF-8能缓解很多编码问题。做实验也好写脚本也好稳定的输出格式能帮你更快定位错误。