Your message dated Tue, 28 Feb 2023 15:13:40 +0000
with message-id <[email protected]>
and subject line Bug#1032123: Removed package(s) from unstable
has caused the Debian Bug report #489363,
regarding libpam-ldap: Support LDAP autoconfiguration using rootDSE?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
489363: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489363
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Version: 186-4.1+rm
Dear submitter,
as the package libpam-ldap has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/1032123
The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)
--- End Message ---
