Package: libpam-ldap
Version: 180-1.7
Severity: wishlist
User: [EMAIL PROTECTED]
Usertag: debian-edu

One issue with large scale deployment of Linux is the need to
configure each client.  It would be easier if the clients were able to
automatically derive their configuration using network services.  This
is successfully done with MS Active directory, where it uses DNS to
locate the LDAP servers, and then uses the LDAP rootDSE to figure out
the LDAP base.

This one-liner show how the SRV record at _ldap._tcp can be used to
locate the LDAP servers:

  ad_servers=$(host -N 2 -t srv _ldap._tcp | grep SRV | rev | awk '{print $1}' 
| cut -d. -f2- | rev)

The next step done is to query any of the LDAP server for the LDAP
base to use

  ldapsearch -LLL -h $(echo $ad_servers | awk '{print $1}')  -s base -b '' -x 
'*' +

The latter trick work with OpenLDAP too.  This is the output from the
OpenLDAP server used in Debian Edu:

  dn:
  objectClass: top
  objectClass: OpenLDAProotDSE
  structuralObjectClass: OpenLDAProotDSE
  configContext: cn=config
  namingContexts: dc=skole,dc=skolelinux,dc=no
  monitorContext: cn=Monitor
  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.334810.2.3
  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
  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: DIGEST-MD5
  supportedSASLMechanisms: CRAM-MD5
  supportedSASLMechanisms: NTLM
  entryDN:
  subschemaSubentry: cn=Subschema

As you can see, the LDAP base is in the namingContexts attribute.
This is the output from an AD server:

  dn:
  currentTime: 20080705093026.0Z
  subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=SKOLEN,DC=LOCAL
  dsServiceName: CN=NTDS Settings,CN=AD2,CN=Servers,CN=Default-First-Site-
   Name,CN=Sites,CN=Configuration,DC=SKOLEN,DC=LOCAL
  namingContexts: DC=SKOLEN,DC=LOCAL
  namingContexts: CN=Configuration,DC=SKOLEN,DC=LOCAL
  namingContexts: CN=Schema,CN=Configuration,DC=SKOLEN,DC=LOCAL
  namingContexts: DC=DomainDnsZones,DC=SKOLEN,DC=LOCAL
  namingContexts: DC=ForestDnsZones,DC=SKOLEN,DC=LOCAL
  defaultNamingContext: DC=SKOLEN,DC=LOCAL
  schemaNamingContext: CN=Schema,CN=Configuration,DC=SKOLEN,DC=LOCAL
  configurationNamingContext: CN=Configuration,DC=SKOLEN,DC=LOCAL
  rootDomainNamingContext: DC=SKOLEN,DC=LOCAL
  supportedControl: 1.2.840.113556.1.4.319
  supportedControl: 1.2.840.113556.1.4.801
  supportedControl: 1.2.840.113556.1.4.473
  supportedControl: 1.2.840.113556.1.4.528
  supportedControl: 1.2.840.113556.1.4.417
  supportedControl: 1.2.840.113556.1.4.619
  supportedControl: 1.2.840.113556.1.4.841
  supportedControl: 1.2.840.113556.1.4.529
  supportedControl: 1.2.840.113556.1.4.805
  supportedControl: 1.2.840.113556.1.4.521
  supportedControl: 1.2.840.113556.1.4.970
  supportedControl: 1.2.840.113556.1.4.1338
  supportedControl: 1.2.840.113556.1.4.474
  supportedControl: 1.2.840.113556.1.4.1339
  supportedControl: 1.2.840.113556.1.4.1340
  supportedControl: 1.2.840.113556.1.4.1413
  supportedControl: 2.16.840.1.113730.3.4.9
  supportedControl: 2.16.840.1.113730.3.4.10
  supportedControl: 1.2.840.113556.1.4.1504
  supportedControl: 1.2.840.113556.1.4.1852
  supportedControl: 1.2.840.113556.1.4.802
  supportedControl: 1.2.840.113556.1.4.1907
  supportedControl: 1.2.840.113556.1.4.1948
  supportedLDAPVersion: 3
  supportedLDAPVersion: 2
  supportedLDAPPolicies: MaxPoolThreads
  supportedLDAPPolicies: MaxDatagramRecv
  supportedLDAPPolicies: MaxReceiveBuffer
  supportedLDAPPolicies: InitRecvTimeout
  supportedLDAPPolicies: MaxConnections
  supportedLDAPPolicies: MaxConnIdleTime
  supportedLDAPPolicies: MaxPageSize
  supportedLDAPPolicies: MaxQueryDuration
  supportedLDAPPolicies: MaxTempTableSize
  supportedLDAPPolicies: MaxResultSetSize
  supportedLDAPPolicies: MaxNotificationPerConn
  supportedLDAPPolicies: MaxValRange
  highestCommittedUSN: 745693014
  supportedSASLMechanisms: GSSAPI
  supportedSASLMechanisms: GSS-SPNEGO
  supportedSASLMechanisms: EXTERNAL
  supportedSASLMechanisms: DIGEST-MD5
  dnsHostName: ad2.SKOLEN.LOCAL
  ldapServiceName: SKOLEN.LOCAL:[EMAIL PROTECTED]
  serverName: CN=AD2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Con
   figuration,DC=SKOLEN,DC=LOCAL
  supportedCapabilities: 1.2.840.113556.1.4.800
  supportedCapabilities: 1.2.840.113556.1.4.1670
  supportedCapabilities: 1.2.840.113556.1.4.1791
  isSynchronized: TRUE
  isGlobalCatalogReady: TRUE
  domainFunctionality: 2
  forestFunctionality: 2
  domainControllerFunctionality: 2

Would it be possible to teach pam-ldap to automatically derive the
LDAP base from the rootDSE entry?  Also, would it be possible to teach
it to automatically figure out which LDAP servers to talk to using the
SRV record provided by AD.  We could easily provide the same DNS entry
in Debian Edu, and thus get the clients to automatically configure
pam-ldap based on the values fetched from the network.  Would need to
get libnss-ldapd to do the same to get this working, though. :)

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to