デフォルトでは、特定のホスト名を指すときにプライマリDNに許可されるデフォルト値を決定するスクリプトを作成しています。私はそれをldapsearch出力の周りに包みます。
- ルートDSEを直接表示してドラッグしてActive Directoryを実行できます。
defaultNamingContext - objectClassのDSEフィルタリングの下で直接単一レベルの検索を開始し、最初の検索のみを実行してDominoを実行できます
dominoOrganization。これはデフォルト値なので、正しくない場合は変更できます。 - ルートDSEを直接表示し、最初の値を抽出してOpenLDAPを実行できます。
namingContexts
しかし、万が一に備えてeDirectoryもサポートしたいと思います。問題は、それを見ることができるeDirectoryがインストールされておらず、フリーソフトウェアではないため、どのように設定されているかを確認するためにテストバージョンをインストールできないことです。
Novellのウェブサイトを見ると、実際にはdefaultNamingContextADと同じことをしないように見え、確かにdominoOrganization objectClassを実行していないようです。 eDirectoryで見たほとんどのサンプルDNは、o=OrganizationNameDominoにも存在するかのように使用されているように見えますが、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