题目#

查询域中所有已禁用的用户，只显示 Name、SamAccountName 和 DistinguishedName。

我的回答#

1
Search-ADAccount -AccountDisabled -UsersOnly |
2
    Select-Object Name,SamAccountName,DistinguishedName

复盘#

回答正确。也可以使用：

1
Get-ADUser -Filter 'Enabled -eq $false' |
2
    Select-Object Name,SamAccountName,DistinguishedName

Search-ADAccount 适合常见账户状态查询；Get-ADUser -Filter 更适合组合复杂条件。

题目#

解释下面两条命令，并说明为什么查询 Department 时需要 -Properties。

1
Get-ADUser -Filter 'Enabled -eq $true'
2

3
Get-ADUser -Identity qianyue -Properties Department,LastLogonDate

我的回答#

• 第一条筛选已启用的用户。
• 第二条查询 qianyue，并额外读取 Department 和 LastLogonDate。
• Department 不在默认返回属性集合中，因此需要额外指定。

复盘#

回答基本正确。-Identity 不只是“用户名字”，还可以接收：

• DistinguishedName
• GUID
• SID
• SamAccountName

需要记住：

题目#

查询 Domain Admins 的直接成员、递归成员，并查询用户 qianyue 所属的组。

我的回答#

第一条误用了 Get-ADGroup；后两条思路正确，但递归查询时写成了另一个组名。

正确答案#

1
# 查询直接成员
2
Get-ADGroupMember -Identity "Domain Admins"
3

4
# 递归展开嵌套组
5
Get-ADGroupMember -Identity "Domain Admins" -Recursive
6

7
# 查询用户所属的组
8
Get-ADPrincipalGroupMembership -Identity qianyue

重点复习：Get-ADGroup 查询组对象本身；Get-ADGroupMember 才查询组中的成员。

题目#

用户已经加入某个组，但仍无法访问共享目录，列出至少四个可能原因。

我的回答#

只想到可能与 Kerberos 登录令牌有关，对组类型、嵌套关系和 ACL 缺少明确思路。

正确排查方向#

1. 加入的是通讯组而不是安全组

   Distribution 组不能参与 ACL 权限判定，必须确认 GroupCategory 为 Security。

   1
   Get-ADGroup -Identity "组名" -Properties GroupCategory,GroupScope

2. 用户的访问令牌尚未刷新

   用户登录时生成的访问令牌包含当时的组成员关系。后来加组，现有令牌通常不会自动更新。

   1
   whoami /groups

   最可靠的验证方式是注销并重新登录。锁屏、断开 RDP 或只执行 gpupdate 不一定会生成新令牌。

3. 嵌套组没有按预期展开

   1
   Get-ADGroupMember -Identity "目标组" -Recursive

   同时检查组作用域、跨域成员限制以及用户是否真的出现在递归结果中。

4. 共享权限与 NTFS 权限不一致

   SMB 访问需要同时通过共享权限和 NTFS 权限，最终结果取二者中更严格的一方。

   1
   # 在文件服务器上查询共享权限
   2
   Get-SmbShareAccess -Name "ShareName"
   3
   
   4
   # 查询目录的 NTFS ACL
   5
   Get-Acl "D:\Shares\ShareName" |
   6
       Select-Object -ExpandProperty Access

5. ACL 中存在显式拒绝

   Deny 通常优先于 Allow。用户可能通过另一个组继承了拒绝项。

6. AD 复制尚未完成

   加组操作可能写入 DC01，但用户登录时联系的是尚未收到更新的 DC02。

   1
   repadmin /replsummary

重点复习：排查权限时要同时确认 AD 组成员关系、用户访问令牌、共享权限和 NTFS ACL。只确认“用户已经在组里”不能证明权限已经生效。

题目#

筛选 90 天未登录的计算机应该使用哪个属性？怎样取得尽可能准确的最后登录时间？

我的回答#

选择了 LastLogonDate 做粗筛，这是正确的；但误以为改查 LastLogonTimeStamp 会更准确。

正确结论#

LastLogonDate 是 ActiveDirectory PowerShell 模块根据 lastLogonTimestamp 转换出的易读值，二者具有相同的延迟特征。

粗筛：

1
$cutoff = (Get-Date).AddDays(-90)
2

3
Get-ADComputer -Filter * -Properties LastLogonDate |
4
    Where-Object {
5
        -not $_.LastLogonDate -or $_.LastLogonDate -lt $cutoff
6
    } |
7
    Select-Object Name,LastLogonDate

精确查询少量关键设备：

1
$computerName = "PC-01"
2

3
Get-ADDomainController -Filter * |
4
    ForEach-Object {
5
        $computer = Get-ADComputer `
6
            -Identity $computerName `
7
            -Server $_.HostName `
8
            -Properties LastLogon
9

10
        [pscustomobject]@{
11
            DomainController = $_.HostName
12
            LastLogon = if ($computer.LastLogon -gt 0) {
13
                [datetime]::FromFileTime($computer.LastLogon)
14
            }
15
        }
16
    } |
17
    Sort-Object LastLogon -Descending

重点复习：LastLogonDate 与 LastLogonTimeStamp 不是两套精度；真正精确的方法是查询每台 DC 的 LastLogon 并取最大值。

题目#

解释 Remove-ADComputer 与 Remove-Computer 的区别。

复盘#

结论正确，但 $credential 被误认为计算机名。它实际保存的是有权执行退域操作的凭据。

1
# 删除 AD 中的计算机对象，不会让在线设备自动退出域
2
Remove-ADComputer -Identity PC-OLD-01
3

4
# 获取退域凭据
5
$credential = Get-Credential "QY\Administrator"
6

7
# 让执行命令的本机退出域并加入工作组
8
Remove-Computer `
9
    -UnjoinDomainCredential $credential `
10
    -WorkgroupName "WORKGROUP"

不指定 -ComputerName 时，Remove-Computer 操作的是本机。计算机是“加入域”，不是“加入 DC”。

我的回答与复盘#

本题回答正确。

我的回答#

• 原 DC 正常可用或计划下线时，使用 Transfer。
• 原角色持有者永久故障、确认不能恢复时，才使用 Seize。

复盘#

核心判断正确，但“会立即导致域崩溃”的描述过于绝对。真正风险是旧角色持有者没有得知角色已经被夺取，又重新执行角色专属操作，形成类似双主或数据不一致的状态。

需要记住：

Seize 不是更强的 Transfer，而是灾难恢复手段。角色被夺取后，旧持有者不能未经清理或重建就直接重新接入生产网络。

RID Master 被夺取时尤其要关注 RID 池与重复 SID 风险；PDC Emulator 则会影响时间、密码变更、账户锁定和组策略管理行为。

我的回答与复盘#

总体正确，需要把 showrepl 的方向说得更准确。

1
# 全局复制摘要
2
repadmin /replsummary
3

4
# QYNET-CORE01 的入站复制详情
5
repadmin /showrepl QYNET-CORE01
6

7
# 同步当前 DC 的所有分区，并跨站点向外推送
8
repadmin /syncall /AdeP

/e 在多站点环境可能瞬间增加站点间链路流量，不能把 /syncall /AdeP 当作日常无脑修复命令。

题目#

repadmin /replsummary 显示 QYNET-CORE02 复制失败，错误为 1722 The RPC server is unavailable，应该怎样排查？

我的回答#

想到先检查 Ping、DNS、复制摘要和事件日志，但排查链不够完整。

推荐顺序#

1
# 1. DNS 正向解析是否正确
2
Resolve-DnsName QYNET-CORE02.qy.net
3

4
# 2. ICMP 只作为辅助信息
5
Test-Connection QYNET-CORE02 -Count 2
6

7
# 3. RPC Endpoint Mapper
8
Test-NetConnection QYNET-CORE02 -Port 135
9

10
# 4. LDAP 与 SMB
11
Test-NetConnection QYNET-CORE02 -Port 389
12
Test-NetConnection QYNET-CORE02 -Port 445
13

14
# 5. DCDiag 基础检查
15
dcdiag /s:QYNET-CORE02 /test:Connectivity /v
16
dcdiag /s:QYNET-CORE02 /test:DNS /DnsBasic /v
17

18
# 6. 查看具体复制伙伴、分区和错误
19
repadmin /showrepl QYNET-CORE02 /verbose

还要检查：

• RPC、NTDS、Netlogon、DNS、KDC 等服务。
• Windows 防火墙及 RPC 动态端口。
• 两台 DC 的 DNS 客户端配置。
• 路由、站点间 ACL 和网络设备。
• 时间同步、Kerberos 与安全通道。
• Directory Service、DNS Server 和 System 事件日志。

重点复习：1722 表示 RPC 通信不可用，不等于服务器一定关机。Ping 可能被防火墙禁用；Ping 成功也不能证明 TCP 135 和 RPC 动态端口可用。

我的回答与复盘#

总体正确：

1
Connectivity → DNS → Advertising → Replications → SYSVOL

Advertising 不是检查 DC “拥有哪种角色”，而是检查 DC 是否正常向客户端声明自己能够提供 LDAP、KDC、GC、时间服务等能力。

DNS 失败会让 DC 定位、复制伙伴查找、FSMO 定位和 Kerberos 认证产生大量连锁错误。因此应先修复 DNS，再重新运行后续测试，而不是同时修改多个组件。

我的回答#

已经覆盖计算机 OU、GPO 链接、DNS、SRV、DC Locator、DCDiag、SYSVOL 和 DFSR 日志，整体排查思路良好。

遗漏内容#

缺少最后的策略刷新和结果查询：

1
# 在客户端刷新策略
2
gpupdate /force
3

4
# 查看计算机策略摘要
5
gpresult /Scope Computer /R
6

7
# 生成详细报告
8
gpresult /Scope Computer /H "C:\Temp\Computer-GPO.html"

同时验证两个关键共享：

1
Test-Path "\\qy.net\SYSVOL"
2
Test-Path "\\qy.net\NETLOGON"

dcdiag 主要用于诊断域控制器。应在 DC 或装有 RSAT 的管理机上，针对客户端实际定位到的 DC 运行：

1
dcdiag /s:QYNET-CORE01 /test:Connectivity
2
dcdiag /s:QYNET-CORE01 /test:DNS /DnsBasic /v
3
dcdiag /s:QYNET-CORE01 /test:Advertising
4
dcdiag /s:QYNET-CORE01 /test:SysVolCheck /test:NetLogons