Bug#489363: libpam-ldap: Auto
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
Bug#489363: libpam-ldap: Auto
On Sat, 5 Jul 2008, Petter Reinholdtsen wrote:
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.
Indeed, and the issue is not limited to just large scale deployments.
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.
I'm not convinced it can do so reliably - in anything other than a
trivial setup... but that is just from the outside - I've continually
refused to run AD, as I prefer opensource solutions (and am willing to
trade a little configuration loss in running samba - NT4 domains over
AD).
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)
libnss-ldap (but not yet libpam-ldap) can also use SRV records to locate
the apropriate ldap servers
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:
hehe, on any ldap server I touch, you'll not see namimg context entries
unless you are authenticated (other entries you have to see - esp the
sasl mechs to even be able to authenticate).
configContext: cn=config
namingContexts: dc=skole,dc=skolelinux,dc=no
monitorContext: cn=Monitor
As you can see, the LDAP base is in the namingContexts attribute.
Yes, in this sample, config and monitor can be disregarded - leaving
only the one possibility.
This is the output from an AD server:
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
A few more candidates for the ignore list
defaultNamingContext: DC=SKOLEN,DC=LOCAL
now, that is an interesting feature
schemaNamingContext: CN=Schema,CN=Configuration,DC=SKOLEN,DC=LOCAL
configurationNamingContext: CN=Configuration,DC=SKOLEN,DC=LOCAL
rootDomainNamingContext: DC=SKOLEN,DC=LOCAL
How does this play in a multi-domain (or roaming workstation)
environment ? Or does it need to ?
Would it be possible to teach pam-ldap to automatically derive the
LDAP base from the rootDSE entry?
An interesting question, and it doesn't appear to be that difficult to
impliment (he says, waving his arms wildly) - sans the roaming issues,
which'll likely require other gyrations.
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. :)
This support, libnss-ldap already has - and I've an open bug requesting
similar support in libpam-ldap... oh, libnss-ldapd - good choice, I've
moved all my servers to that as well - much nicer (and I'm the
libnss-ldap maintainer !) but it appears that libnss-ldapd also supports
SRV records by using 'uri DNS'
Happy hacking,
My preference would be to abondon libpam-ldap, as I have libnss-ldap in
favour of modifying libnss-ldapd to support the password changing
feature - I've spoken with the OpenLDAP upstream who have actually included
libnss-ldapd into newer versions of OpenLDAP! and they appeared
interested, but I've not yet spoken with the libnss-ldapd maintainer
(who is also upstream).
libpam-ldap suffers many of the same faults as libnss-ldap, and has a
bunch of its own (and major) failures, chief amongst them being that it
currently does not request a limited set of attributes on its queries,
making it fail for sites that include large items (ssl certs/etc) in
their schema... Second place would likely be its lack of SRV support.
It doesn't look that hard to extend libnss-ldapd to support a few write
operations (pwd being the obvious case)... for openldap, I'd think
using the exop approach would be best, but I don't know about AD... In
fact, I was interested to see that you're apparently using libnss-ldapd
with AD !
--
Rick Nelson
* TribFurry only gets spam mail from ucsd... I used to get email from
myself but I decided I didn't like myself and stopped talking
to me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
