测验：LDAP 与组织架构

LDAP 过滤器 (&(objectClass=inetOrgPerson)(|(title=부장)(title=차장))(!(ou=총무팀))) 会选出哪些对象？

• 既是部长又是次长，且属于总务团队的人
• 职级为部长或次长，且不属于总务团队的人
• 总务团队中的部长和次长
• 所有部长、次长和总务团队成员

与 AD 同步时，为什么不能使用 uid 或 DN，而应把 objectGUID 作为关联键？

• 姓名变更或部门调动会改变 uid/DN，导致同一个人被创建为新用户
• objectGUID 比字符串短，索引和比较成本更低
• AD 只为 objectGUID 建立索引，因此查询更快
• DN 表示法是 AD 专有扩展，迁移到其他目录时不兼容

AD 过滤器 (!(userAccountControl:1.2.840.113556.1.4.803:=2)) 的作用是什么？

• 只排除 userAccountControl 值恰好为 2 的账号
• 排除 userAccountControl 中启用了 ACCOUNTDISABLE（0x2）位的账号，即禁用账号
• 排除密码已过期的账号
• 只选择计算机账号

只获取“最近发生变更的条目”的增量同步有什么结构性局限？

• 无法发现已删除条目，离职人员账号会残留在我方系统
• 无法发现新建账号
• 无法获取组信息
• 无法同步密码

在组通过 member 指向用户的目录中，每次登录都查询“该用户所属的组”时应注意什么？

• 无法获取组信息
• 不能查询 member 属性
• 需要扫描所有组，组数量增加后登录会急剧变慢
• 组名可能重复

LDAP 组中产生“悬空成员关系（dangling member）”的根本原因是什么？

• 不同服务器实现存在已知的删除缺陷
• member 数量超过上限时，后面的条目会被截断
• 多主复制中删除传播较慢，造成暂时不一致
• member 只是 DN 字符串，服务器并不强制引用完整性

在运维脚本中，为什么不应使用 ldapsearch -w <비밀번호>，而应改用 -y <파일>？

• 通过 -w 传入的密码会暴露在进程列表中，同一服务器上的其他用户可以看到
• -w 的参数会先被 Shell 解析，含特殊字符的密码无法原样传递
• -y 会预读认证信息，从而减少一次 bind 往返
• -w 只适用于明文 LDAP，连接 LDAPS 时会被忽略