LeeM's questions

我有一个 AD 环境，在 ldapsearch 中，我能够使用 DNS 中的 SRV 记录来解析域和站点中的 LDAP 服务器。

这适用于 389 上的常用 ldap 端口，具有基本身份验证和 STARTTLS。

但是，一些可怕的客户端不会执行 STARTTLS，或者供应商无法提供配置它的方法。[1] 所以我们需要在 636 上为 LDAPS 提供一个选项。

原则上，我相信创建 ldaps SRV 记录和使用ldaps:///URI 应该可以工作。我在域区域中创建了 2 个 ldaps SRV 记录（有 3 个 ldap 主机），但是当我这样做ldapsearch并指定时ldaps:///，它发现的只是 ldap 主机。

这是ldapsearch命令 - 它在端口389上返回三个带有 _ldap SRV 的 DC

$ ldapsearch -v -H "ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom" -D "user" -W -b "DC=evl,DC=example,DC=com" -b "" -s base "(objectclass=*)" -d 1

ldap_url_parse_ext(ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom)
ldap_initialize( ldaps://EVLADC002vs.evl.example.com:389 ldaps://EVLADC001vs.evl.example.com:389 ldaps://EVLADC006vs.evl.example.com:389 )
ldap_create
ldap_url_parse_ext(ldaps://EVLADC006vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC001vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC002vs.evl.example.com:389)

但是，客户端机器可以解析_ldaps的两个SRV，端口为636

$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.

这是用于比较的 LDAP SRV

$ dig -t SRV _ldap._tcp.evl.example.com +short
0 100 389 EVLADC001vs.evl.example.com.
0 100 389 EVLADC006vs.evl.example.com.
0 100 389 EVLADC002vs.evl.example.com.

如果我在 ldaps 上查询特定服务器，一切都很好

$ ldapsearch -H ldaps://evladc001vs.evl.example.com -D "user" -W -b "" -s base "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
currentTime: 20200213045340.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=evl,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=EVLADC001VS,CN=Servers,CN=Server,CN=Sites,CN=Configuration,DC=evl,DC=example,DC=com
...  

对于我是否缺少某些选项或其他明显的问题，我将不胜感激。

[1]：请不要从使用不同产品的讲座开始。大企业无论如何都有集成问题 - 尝试告诉医院系统购买不同的价值数百万美元的软件以满足他们的特定需求

我们发现域管理员帐户（除非发生灾难恢复情况，否则我们不会使用该帐户）在 LastLogonTimeStamp 属性中具有最近的日期。据我所知，在相关时间段（以及几个月后）内，没有人应该使用过此帐户，但也许某些白痴已将其配置为运行计划任务。

由于安全日志事件的数量（以及缺乏用于分析的 SIEM 工具），我想确定哪个 DC 具有帐户的实际lastLogon时间（即不是复制属性），但我已经查询了域中的每个 DC，并且他们每个人都有一个 lastLogon 为管理员的“none”。

这是林中的子域，因此可能有人使用此子域管理员帐户在父域中运行某些东西。

除了检查 LastLogonTimestamp 中记录的时间前后来自 16 个森林 DC 的潜在 2000 万个事件之外，谁能想到一种方法来确定哪个 DC 正在执行登录？我想我可以首先针对父域 DC（因为子 DC 似乎没有进行身份验证）。

解释

[根据以下使用后归零原因后添加repadmin]

这个请求的最初原因是由于我们的 IT 安全团队，他们想知道为什么我们显然经常使用默认域管理员帐户登录。

我们知道我们没有登录它。事实证明，有一种称为“Kerberos S4u2Self”的机制，当作为本地系统运行的调用进程正在执行一些权限提升时。它在域控制器上以管理员身份进行网络登录（非交互式）。由于它是非交互式的，这就是为什么lastLogon在任何 DC 上都没有该帐户的原因（该帐户从未登录到任何当前的域控制器）。

这篇文章解释了为什么这个东西会 ping 你的日志并使你的安全团队有小猫（源机器是 Server 2003，让事情变得更糟）。以及如何追踪它。https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

经验教训 - 仅lastLogon在涉及管理员登录时向 IT 安全团队提供有关属性的报告。

我们即将开始将 AD 升级到 2012 R2，我刚刚惊恐地发现，匿名 LDAP 绑定已在2003域中启用。

我们当然已经通过策略向非 Windows 系统颁发了 LDAP 身份验证帐户，但是在禁用匿名绑定之前，我们可能应该做一些尽职调查以确保没有人只是采用匿名快捷方式。

关于如何审计 LDAP 中的匿名操作有什么建议吗？显然，可以启用 AD 调试诊断日志记录，或者使用 ADInsight 之类的工具，但我不知道要过滤哪些事件。

我在构建为 VMWare 来宾的两台 Server 2008 R2 域成员服务器上遇到了这个问题。同时建的DC不存在这个问题。

当我使用域（管理员）帐户登录时尝试 ping 127.0.0.1（或“localhost”）时，我收到一条错误消息，提示“无法联系 IP 驱动程序。一般故障。” 但是，如果我以本地管理员帐户登录，它可以正常工作。

我尝试过重置 TCP/IP 堆栈netsh int ip reset并重新启动。没什么区别。

但是，ping 默认网关，它自己的 IP 和其他主机都可以作为域用户。

任何指针？