Попытка обнаружить приемлемый LDAP основывает значения по умолчанию DN для различных серверов каталогов в сценарии удара

Это появляется namingContext довольно повсеместно для корневого объекта DSE на большинстве каталогов. Таким образом, разумное значение по умолчанию обычно просто берет первый (если DSA определенные наборы один как значение по умолчанию, как с AD). Если у них есть экзотическая конфигурация, где существует несколько разделов/DIT на том же неAD DSA затем, те те же администраторы, вероятно, также собираются быть sw00ft, достаточно знают, каков соответствующий основной 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)"

Определение хорошего основного DN от OpenLDAP DSA:

[root@policyServer ~]# ldapsearch -x -LLL -H ldap://localhost -b '' -s base + | egrep "^namingContexts:" | head -1 | cut -d: -f2
 dc=trunkator,dc=com
[root@policyServer ~]#

Для ссылки это - полный корневой DSE того же самого DSA (я удостоверился, что были несколько, 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