![尝试在 bash 脚本中检测各种目录服务器可接受的 LDAP 基本 DN 默认值](https://linux22.com/image/45450/%E5%B0%9D%E8%AF%95%E5%9C%A8%20bash%20%E8%84%9A%E6%9C%AC%E4%B8%AD%E6%A3%80%E6%B5%8B%E5%90%84%E7%A7%8D%E7%9B%AE%E5%BD%95%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%8F%AF%E6%8E%A5%E5%8F%97%E7%9A%84%20LDAP%20%E5%9F%BA%E6%9C%AC%20DN%20%E9%BB%98%E8%AE%A4%E5%80%BC.png)
基本上,我正在编写一个脚本,用于在指向特定主机名时确定基本 DN 的可接受的默认值。我将它包裹在ldapsearch
输出周围。
- 我可以通过直接查看根 DSE 并拉取来执行 Active Directory
defaultNamingContext
- 我可以通过在 objectClass 的 DSE 过滤下直接启动单级搜索来执行 Domino
dominoOrganization
,并仅采用第一个搜索(这是默认值,因此如果不正确,他们可以预期会更改它)。 - 我可以通过直接查看根 DSE 并提取第一个值来执行 OpenLDAP
namingContexts
但我还希望它支持 eDirectory,以防万一。问题是我没有安装任何 eDirectory 来查看,而且它不是免费软件,因此我无法安装它的测试版本来查看它的设置方式。
看看 Novell 的网站,看起来他们并没有真正做defaultNamingContext
AD 做的同样的事情,而且他们绝对不会做 dominoOrganization objectClass。我见过的 eDirectory 的大多数示例 DN 看起来也像o=OrganizationName
Domino 中存在的那样使用,但我也看到过o=OrganizationName,C=US
,如果国家/地区缩写可以或不能在基本 DN 中,我将不得不做的不仅仅是 one_level。
更糟糕的是,如果目录服务器已分区(如某些 AD 配置),或者像 Domino 一样,其中有许多内置的默认组织,但这些组织无法反映您在何处可以找到重要的 LDAP 信息。例如,O=RSA Data Security\, Inc.,C=US
我现在正在查看的 Domino LDAP 实例中有一个组织。
如果我在根 DSE 处开始搜索,是否可以过滤特定的对象类?我意识到这是一项昂贵的搜索(特别是当我必须全面了解sub
范围时),但这应该是偶尔发生的事情。
长话短说:公司组织的基础在 eDirectory 中具有哪些标识属性?如果将搜索基础设置为根 DSE,如何找到它?
我更喜欢示例,因为我无法验证您的代码是否有效,直到我遇到需要在 eDirectory 服务器上运行此脚本的机会(我们受过高等教育,所以这绝对是可能的)。
答案1
namingContext
对于大多数目录中的根 DSE 对象来说,它似乎非常普遍。因此,合理的默认值通常只是采用第一个(除非 DSA 特定将第一个设置为默认值,就像 AD 一样)。如果他们有一个奇特的配置,其中同一个非 AD DSA 上有多个分区/DIT,那么这些相同的管理员可能也足够了解适当的基本 DN 是什么,如果第一个namingContext
不是我们应该在其下寻找用户/组。
有关如何运行基本 DN 默认值自动检测的伪代码对于各种 DSA:
# Active Directory Test
# rootDSE lists acceptable default base DN for us
If "1.2.840.113556.1.4.800" in rootDSE["supportedCapabilities"]:
defaultBase = rootDSE["defaultNamingContext"]
# IBM Domino LDAP Test
# Take the dn of the first dominoOrganization Object we find
If "IBM Lotus Software" == rootDSE["vendorname"]
ldapsearch -LLL "objectClass=dominoOrganization" dn | head -1
# eDirectory Test
# Take the first Partition Object we find
If "Novell Inc." == rootDSE["vendorName"]
ldapsearch -LLL "objectClass=Partition" dn | head -1
# OpenLDAP Tests
# This is the same as the default action so not technically required but it shows
# how you identify OpenLDAP DSA's. It's possible to nest some additional checks/searches
# here for the various types of top level containers (For example to prefer domain
# container-style entries to org-style, etc).
If "OpenLDAProotDSE" in rootDSE["objectClass"]
ldapsearch -LLL -b '' -s base namingContext | head -1
# Apache DS Tests
# Same as above, not technically required but it shows how you identify Apache DS
If "Apache Software Foundation" in rootDSE["vendorName"]
ldapsearch -LLL -b '' -s base namingContext | head -1
# Default to taking the first namingContext attribute if present but no tests works
If $(ldapsearch -LLL -b '' -s base namingContexts | head -1 | cut -d: -f2 | wc -c ) > 1
ldapsearch -LLL -b '' -s base namingContext | head -1
# I'm out of ideas on how to find a base DN so ultimately default to something explicit
return "(null)"
从 OpenLDAP DSA 确定良好的基本 DN:
[root@policyServer ~]# ldapsearch -x -LLL -H ldap://localhost -b '' -s base + | egrep "^namingContexts:" | head -1 | cut -d: -f2
dc=trunkator,dc=com
[root@policyServer ~]#
作为参考,这是同一个 DSA 的完整根 DSE(我确保列出了多个 DIT 以进行完整说明):
[root@policyServer ~]# ldapsearch -x -LLL -H ldap://localhost -b '' -s base +
dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
monitorContext: cn=Monitor
namingContexts: dc=trunkator,dc=com
namingContexts: dc=localhost
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.1.8
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
supportedSASLMechanisms: GSSAPI
entryDN:
subschemaSubentry: cn=Subschema