Windows AD Practice Day9
Day 9｜基础复习与结果判断（15 题）
本篇保留题目、交卷原答、批改与正确思路；答案直接跟在对应题目后面。
本轮 5 题基本完整，7 题需要补充或纠正，Q13～Q15 未作答，补充分步讲解，不把带做示范计为自主完成。本次不设综合压轴题。
作答方式未完整标记，部分题目明确查过笔记。没有新的完整 VM 输出；参考命令没有在本轮由助手执行，文中的精简输出与数值均为题目假设，不是实时环境结果。
Q1｜用户与账户：锁定不等于禁用（简单·先闭卷）
只查询域中当前被锁定的用户账户，显示 Name、SamAccountName、LockedOut。写出命令，再用一句话说明“锁定”和“禁用”是否是同一状态。本题不执行解锁。
我的回答：
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut锁定与禁用的区别：
锁定与禁用不是同一个状态，一个是可能因为一些原因，例如密码策略之类的导致账户被锁定。但是禁用则需要手动操作禁用用户。
批改：基本正确，漏了“仅用户”的范围。
正确答案与思路：
Search-ADAccount -LockedOut -UsersOnly | Select-Object Name,SamAccountName,LockedOut锁定与禁用是不同状态。锁定通常由错误认证触发账户锁定策略；禁用是账户启用标志被关闭，可由管理员或自动化执行。题目只查用户，所以需要 -UsersOnly。Search-ADAccount
Q2｜组与成员：查询方向（简单·先闭卷）
现在要看 QYNET-Admin 中包含哪些账户，嵌套组中的成员也要展开，只显示 Name 和 ObjectClass。写命令即可。
补一句：这与“查询 qianyue 属于哪些组”是不是同一个查询方向？
我的回答：
Get-ADGroupMember -Identity 'QYNET-Admin' -Recursive | Select-Object Name, ObjectClass并不是，这是两个查询方向。一个是查一个组里有哪些成员，一个是查询成员分别归属于哪些组。
Get-ADPrincipalGroupMembership -Identity 'qianyue'批改：正确。
正确答案与思路：
Get-ADGroupMember -Identity 'QYNET-Admin' -Recursive | Select-Object Name,ObjectClass
# 反方向：查询用户属于哪些组Get-ADPrincipalGroupMembership -Identity 'qianyue'第一条从组找成员，第二条从用户找所属组。嵌套成员展开用 -Recursive。
Q3｜计算机：最后登录时间（简单·先闭卷）
某计算机的 LastLogonDate 显示为十天前。能否据此断定“它今天一定没有进行过域登录／认证”？说明依据。
如果必须进一步核对 AD 记录的最近登录时间，应查询哪个不复制的属性？需要只查一台 DC，还是遍历相关域的 DC？不要求写遍历脚本。
我的回答：
并不能，因为 LastlogonDate 并不是实时同步的。如果需要进一步核对，需要核对 LastLogon 属性。而且要查相关域的 DC。
批改：正确，补齐最后一步即可。
正确答案与思路：
不能仅凭 LastLogonDate 判断今天一定没有认证。它由 lastLogonTimestamp 转换而来，不是独立实时记录。要进一步核对，应查询相关域各 DC 不复制的 lastLogon，转换后取最大值；有 DC 查询失败时，结果不完整，不能称为全域精确值。
Q4｜域控与 FSMO：只查林级角色（简单·先闭卷）
不使用 netdom，用一条 PowerShell 命令查询林级的两个 FSMO 角色持有者，显示对应的两个属性。此次只写这两个，不要求写域级三个。
我的回答：
Get-ADForest # 查两个林级角色（架构、域命名）Get-ADDomain # 查三个域级角色（RID、PDC、基础结构）批改：角色分层正确，命令未完成题目要求。
正确答案与思路：
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster架构主机和域命名主机是林级角色。你的原命令能查询林信息，缺少的只是按题目限制显示的两个属性，不应判成完全不会 FSMO。
Q5｜复制健康：一个成功不代表全部成功（简单·输出判断）
以下为虚构的精简输出，不是 VM 实测结果：
目标 DC：QYNET-CORE01来源 DC：QYNET-CORE02
DC=qy,DC=net 最近尝试：成功
CN=Configuration,DC=qy,DC=net 最近尝试：失败，8524，DNS 查找故障能否写“CORE01 复制已完全恢复正常”？写一句更准确的结论，再写出查询 CORE01 入站复制详情的命令。无需执行修复。
我的结论：
并不能完全判断恢复正常。只能说最近一次的复制是成功的。需要进一步查询摘要。
查询命令：
repadmin /showrepl QYNET-CORE01批改：命令正确，结论需要按分区描述。
正确答案与思路：
repadmin /showrepl QYNET-CORE01准确结论：CORE01 从 CORE02 接收域分区的最近复制成功，但配置分区仍因 DNS 查找故障 8524 失败，不能认定全部健康。复制结果按命名上下文分别记录，不要笼统概括成“最近一次复制成功”。
Q6｜DCDiag：SYSVOL 检查的边界（简单·可查）
写一条 dcdiag 命令，对 QYNET-CORE01 执行 SysVolCheck 和 Advertising 两项测试。
如果它们通过，能否仅凭这两项就证明“两台 DC 的所有 GPO 文件内容已经一致”？只需简短判断，不要求展开 DFSR 修复。
我的回答：
dcdiag /test:SysVolCheck /test:Advertising结果能证明什么、还不能证明什么： SysVolCheck：检查本机的 SYSVOL 共享是否正常，SYSVOL 和 NETLOGON 共享是否存在、能否访问。 Advertising：检查本机是否在 DNS 里正确广告自己，也就是 NetLogon 服务有没有注册 LDAP、Kerberos、GC 等 SRV 记录，让客户端能找到它。
但不能证明的是，复制是否健康、SYSVOL 内容是否一致、客户端实际能定位到它、认证能用、权限能过、其他 DC 是否健康、服务端口是否都通。
查了笔记：https://springtsuki.xucjno.com/posts/springtsuki/notes/windowsad/powershell/921-dcdiag/
批改：知道不能证明内容一致，这是对的；目标 DC 漏写，两个测试的解释需纠正。
正确答案与思路：
dcdiag /s:QYNET-CORE01 /test:SysVolCheck /test:AdvertisingSysVolCheck：读取 Netlogon 的SysVolReady注册表值，检查是否为 1；不直接检查共享可访问性，也不比较文件内容。Advertising：通过 DC Locator／DsGetDcName检查 DC 是否声明应具备的角色，不等于逐项验证所有 SRV 记录。NetLogons：补充检查执行测试的用户能否读取 SYSVOL／NETLOGON 共享及相关权限。
这两项通过，不能证明两台 DC 的 GPO 文件全部一致。Advertising 通过也不能证明所有客户端到 Kerberos 端口均可达。微软 DCDiag 测试范围
Q7｜DNS 与 SPN：扩大查询范围（简单·先闭卷）
反查 HTTP/testweb.qy.net 注册在哪个账户上，要求查询范围为整个林，而不是仅限当前域。写出 setspn 查询命令。本题不添加或删除 SPN。
我的回答：
setspn -Q HTTP/testweb.qy.net -F批改：正确。
正确答案与思路：
setspn -F -Q HTTP/testweb.qy.net-Q 反查 SPN，-F 扩大到林范围。你的写法已包含两者，不因参数顺序扣分；本次没有运行记录，不写成已实测。setspn 参数
Q8｜Kerberos：票据与权限（简单·概念）
补全下面三处：
- 客户端申请某个服务的票据时，用什么名称标识目标服务？
- TGT 与服务票据（ST）中，哪一个用于向目标服务证明身份？
- 拿到服务票据，是否就意味着一定有权读写目标共享文件夹？说明一句原因。
我的回答：
- SPN
- ST
- 并不意味着一定有权限读写ACL。因为ST只是票据通过了，并不意味着自身身份有权限访问ACL。
查了笔记：https://springtsuki.xucjno.com/posts/springtsuki/notes/windowsad/powershell/922-kerberos/
批改：三项核心判断正确。
正确答案与思路：
目标服务用 SPN 标识；客户端向服务出示 ST／服务票据。取得票据不等于获得文件读写权限，访问还需通过共享权限与 NTFS ACL 等授权检查。
原答的“读写 ACL”改为“按 ACL 判断能否读写资源”更准确。ACL 是访问控制规则，修改 ACL 本身又是另一种权限。本题查了笔记，不据此认定已经闭卷熟练。
Q9｜时间同步：不同角色，不同判断（简单·概念）
以下是假设情境，不是当前 VM 状态：
- 一台普通域成员机的时间源显示某台域控。
- 林根域 PDC 的时间源显示
Local CMOS Clock。
前者是否一定异常？后者是否足以证明它正在与外部 NTP 同步？分别回答，再写出查看本机时间源的命令。不要修改配置。
我的判断：
并非一定异常，后者不足以证明与外部 NTP 同步。
查询命令：
w32tm /query /source批改：正确。
正确答案与思路：
w32tm /query /source普通域成员机从 DC 获取时间可以正常；Local CMOS Clock 不是外部 NTP 来源。评估林根 PDC 的同步健康还需结合状态、最近成功同步和实际偏差，而不是只看来源命令有输出。
Q10｜事件日志：补齐昨天漏答的字段（简单·先闭卷）
事件 4740 中，用来定位锁定来源机器的字段叫什么？只写字段名即可。
再判断：看到了 4776，是否就能断定 NTLM 密码验证失败？还需要看事件中的什么信息？本题不要求写日志脚本。
4740 来源字段：
Computer
4776 判断依据：
不能，还要看 status 的状态码
批改：4776 的判断正确；4740 的字段名需要纠正。
正确答案与思路：
4740 的来源字段是 Caller Computer Name／调用方计算机名，事件 XML 中通常为 CallerComputerName。System/Computer 则是产生日志的计算机，在 DC 上查日志时常是 DC 本身，不能直接当作锁定来源客户端。
4776 需要看具体状态／错误码，不能仅凭事件 ID 判断密码验证失败。你的后半部分判断正确。微软 4740 字段说明
Q11｜备份与恢复：System Writer 的检查入口（简单·可查）
Windows Server Backup 报“未在备份中找到系统写入程序”。你想先确认 System Writer 是否存在、状态是什么，应执行哪条只读命令？
如果该命令列出的其他 Writer 全部正常，却根本没有 System Writer，能否说“所有必要 Writer 都正常”？写一句判断，并说明还会去哪个日志中查哪类相关来源。不要重启服务或修改 ACL。
查询命令：
vssadmin list writers判断与日志入口： 不能。System Writer 缺失本身就是异常，而系统状态备份依赖它；其他 Writer 正常不代表它正常。
位置：事件查看器 → Windows 日志 → 应用程序 来源：筛选 VSS、Backup、Windows Backup、SPP 等相关来源
查了笔记。
未实测
批改：查询与核心判断正确，日志来源需补上 CAPI2。
正确答案与思路：
vssadmin list writers检查是否列出 System Writer、状态和上次错误。其他 Writer 正常不能补偿它缺失。
在 Application 日志中重点对照失败时间查看 Microsoft-Windows-CAPI2、VSS，并结合 Windows Server Backup 的任务错误与日志。SPP 有相关事件时可辅助，但不能代替 CAPI2。昨天的 CAPI2 513 / OnIdentity / TraverseDir 就是重要线索，不应直接套用不匹配的权限修复命令。System Writer 缺失说明
Q12｜磁盘与性能：单位不混淆（简单·可查）
以下是虚构数值，不是当前 VM 的 C 盘空间：
Get-PSDrive C 查询结果中的 Free = 10737418240这个原始数值的单位是什么？如果除以 PowerShell 的 1GB，得到多少 GiB？可以使用计算器或 PowerShell 做算术，不要求心算。
我的回答：
10 GB
批改：换算数值对，单位和原始单位漏写。
正确答案与思路：
10737418240 / 1GB# 参考算术结果为 10，不是 VM 实测输出原始单位是 Bytes／字节；PowerShell 的 1GB 为 1024³ 字节，所以换算得到 10 GiB。你算出的数值正确，但题目要求的原始单位没有回答；这里不是十进制的 10 GB。
Q13｜站点与服务：站点和子网不是一回事（简单·可查）
管理员已经创建了站点 Branch-Shanghai。这是否自动意味着 192.168.50.0/24 网段的客户端会被识别为属于该站点？还需核对什么映射？
写出查询 AD 子网及其关联站点的 PowerShell 命令，或写明在“Active Directory 站点和服务”中的 GUI 检查位置。本题不创建站点或子网。
我的回答：
未作答，希望手把手讲解。
批改：未作答，以下是带做示范，不计为自主完成。
正确答案与思路：
带做 1：先区分两个对象
站点是一个逻辑位置，子网是地址范围；创建站点不等于自动把客户端 IP 归入它。
可以这样理解：
客户端 IP → 匹配 AD 子网 → 子网关联站点 → 按站点等条件定位 DC
同一 IP 网段内的机器，AD 不会只靠站点名称猜出它属于哪里。
带做 2：先查映射，不修改任何东西
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site逐行看：有没有覆盖目标 IP 的子网？其 Site 指向哪里？若存在更具体的子网，也要核对匹配关系。
GUI：运行 dssite.msc → Sites／站点 → Subnets／子网 → 找到对应子网 → 属性，核对关联的站点。不要只看到 Sites 下有 Branch-Shanghai 就结束。
带做 3：再到客户端核对实际识别结果
nltest /dsgetsite这一步在目标客户端执行，用来核对它当前识别的站点。先记录输出，若与预期不符，再考虑映射、网络、缓存等原因，不直接重建站点。
**本题正确结论：**不一定属于 Branch-Shanghai，必须核对覆盖客户端地址的 AD 子网与该站点的关联。
Q14｜清理与维护：空 OU 到底看什么（简单·可查）
某 OU 中没有用户，但有一个计算机对象，另有一个子 OU。能否把它当作“空 OU”删除？
如果要用 PowerShell 检查一个指定 OU 是否存在直接子对象，可以查 Get-ADObject 的哪些搜索参数？写查询命令或说明思路即可；不要求写全域扫描脚本，也不实际删除 OU。
可以查资料。示例目标 DN：
OU=RecoveryLab,OU=Organization,DC=qy,DC=net。即使当前 VM 中不存在这个 OU，也可以只写命令，不必创建它。
我的回答：
未作答，希望手把手讲解。
批改：未作答，以下是带做示范，不计为自主完成。
正确答案与思路：
带做 1：先理解“空”的对象范围
没有用户，不代表没有 AD 对象。计算机、组、子 OU 等都算内容；本题已明确有计算机和子 OU，因此不是空 OU。
带做 2：拆开两个搜索参数
-SearchBase：从哪个 DN 开始查。-SearchScope OneLevel：只查它的直接子对象，不把该 OU 本身算进结果。
$ouDN = 'OU=RecoveryLab,OU=Organization,DC=qy,DC=net'
Get-ADObject -SearchBase $ouDN -SearchScope OneLevel -Filter * | Select-Object Name,ObjectClass,DistinguishedNameGet-ADUser 会漏掉计算机、组、子 OU，所以这里用 Get-ADObject。
带做 3：读结果，不做删除
- 返回计算机、子 OU 或其他对象：不空。
- 在权限足够、目标正确且查询成功的前提下，无子对象结果：支持“当前没有可见直接子对象”。
- 报 OU 不存在、服务器不可达或权限错误：查询未完成，不能当作空 OU。
GUI：在 AD 用户和计算机中选择目标 OU，查看其内容。后续真要删除，还需核对 GPO 链接、委派和业务用途；对象为空不自动等于可以删除。
Q15｜GPO：在正确区域找答案（简单·输出判断）
以下为虚构的 gpresult 精简输出，不是 USER01 实测结果：
已应用的组策略对象------------------ Default Domain Policy
下列组策略对象被筛选排除，因此没有应用------------------------------------ Policy-User 正在筛选: 拒绝（安全性）有人用 findstr 搜到了 Policy-User，便说它已应用。你同意吗？说明依据，再写出在当前用户会话中查看用户范围文本结果的规范命令。不要求修改安全筛选。
我的回答：
未作答，希望手把手讲解。
批改：未作答，以下是带做示范，不计为自主完成。
正确答案与思路：
带做 1：先在输出中找“区域”，不是找“关键词”
本题 Policy-User 位于“被筛选排除，因此没有应用”区域，因此不能认定它已应用；“拒绝（安全性）”将下一步方向指向安全筛选／相关权限。
带做 2：在正确用户会话中获取结果
在 USER01 的目标用户会话中执行：
whoamigpresult /scope user /r先确认当前身份，再看用户范围；不要拿管理员自己的结果代替目标用户。
GUI 可用 gpmc.msc → Group Policy Results／组策略结果 → 向导，选择目标计算机与用户。需要相应权限与连通性，不要为练习随手关闭防火墙。
带做 3：从线索走向配置核对
管理端 GPMC 中找到该 GPO，检查 Scope／作用域中的链接与 Security Filtering／安全筛选，再到 Delegation／委派查看权限。不要看到“安全性拒绝”就直接给 Everyone 授权。
应用策略通常涉及目标用户／计算机的 Read 与 Apply Group Policy 权限；用户策略还要考虑客户端计算机对 GPO 的读取权限。这里先认识检查入口，不要求今天改权限。
**本题正确答案：**不同意它已应用；它被安全筛选排除。关键词命中只能证明文字存在，不能证明其处于已应用区域。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或打赏支持！
音乐
暂未播放