嘗試在 bash 腳本中檢測各種目錄伺服器的可接受的 LDAP 基本 DN 預設值
基本上，我正在編寫一個腳本，當指向特定主機名時，該腳本確定基本 DN 的可接受預設值。我將它包裝在
ldapsearch輸出周圍。
- 我可以通過直接查看根 DSE 並拉取來執行 Active Directory
defaultNamingContext- 我可以通過直接在 DSE 過濾下為 objectClass 啟動一級搜尋
dominoOrganization並只獲取第一個搜尋來執行 Domino（這是預設設置，因此如果不正確，可以預期他們只需更改它）。- 我可以通過直接查看根 DSE 並提取第一個值來執行 OpenLDAP
namingContexts但我也希望它支持 eDirectory，以防萬一。問題是我沒有安裝任何 eDirectory 可供查看，而且它不是免費軟體，因此我無法安裝它的測試版本來查看它是如何設置的。
看看 Novell 的網站，看起來他們並沒有真正做
defaultNamingContextAD 所做的事情，而且他們絕對不會做 dominoOrganization objectClass。我在 eDirectory 中看到的大多數範例 DN 看起來他們也在o=OrganizationNameDomino 中使用 like，但我也看到o=OrganizationName,C=US了，所以如果國家/地區縮寫可以或不可以在基本 DN 中，我將不得不做的不僅僅是 one_level。更糟糕的是，如果目錄伺服器是分區的（如某些 AD 配置），或者像 Domino 一樣，其中有許多內置的預設組織不能反映您在哪裡可以找到重要的 LDAP 資訊。
O=RSA Data Security\, Inc.,C=US例如，我現在正在查看的 Domino LDAP 實例中有一個組織。如果我在根 DSE 開始搜尋，是否有可以過濾的特定 objectClass？我意識到這是一項昂貴的搜尋（尤其是當我必須全力以赴
sub時），但這應該是偶爾出現的類型。**長話短說：**公司組織的基礎在 eDirectory 中具有哪些辨識屬性，如果我將搜尋基礎設置為根 DSE，我如何找到它？
我更喜歡範例，因為在遇到需要在 eDirectory 伺服器上執行此腳本的機會之前，我將無法驗證您的程式碼是否有效（我們是高等教育，所以這絕對是可能的）。
對於大多數目錄上的根 DSE 對象來說，它似乎
namingContext無處不在。因此，合理的預設值通常只是採用第一個（除非 DSA 特定將一個設置為預設值，就像 AD 一樣）。namingContext如果他們有一個奇特的配置，其中在同一個非 AD DSA 上有多個分區/DIT，那麼如果第一個不是我們應該的，那麼這些相同的管理員可能也會足夠了解合適的基本 DN 是什麼正在尋找下的使用者/組。有關如何為各種 DSA 的基本 DN 預設值執行自動檢測的虛擬碼：
# 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