On Sun, 2011-08-07 at 14:56 +0100, Justin B Rye wrote: > > * none: no authentication; > > * simple: simple clear text binddn/password; > > * SASL: one of the Simple Authentication and Security Layer > > mechanisms. > > Does it really mean "cleartext"? It can't be "clear text" (asking for > a text password instead of... what?), and if it really means "stored > without encryption" it should say so more directly. And what's > "binddn/password"? Should it perhaps be: It means that the password is sent to the LDAP server in plain text (as opposed to the challenge-response mechanisms that are available in SASL). A side-effect of this is that the password also needs to be stored in plain text on the client side. A binddn is basically a user name in LDAP speak. binddn/password is meant to refer to the combination (like username/password). Some Google searches suggest "stored in plain text" is the most popular of the variations (I generally prefer the democratic spelling). RFC 4616 calls PLAIN "a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism". Should I change all "clear text" to "plain text"? > > * LOGIN: deprecated in flavor of PLAIN; > > * PLAIN: simple cleartext password mechanism; > > s/cleartext/unencrypted/ I think unencrypted is confusing because you can still use SSL to encrypt the network traffic which is separate from the login mechanism. > > Template: nslcd/ldap-sasl-realm > > Type: string > > _Description: SASL realm: > > Enter the SASL realm that will be used to authenticate to the LDAP > > database. > > . > > If empty, the GSSAPI mechanism will use information from the Kerberos > > credential cache. Others mechanisms may need @<REALM> suffixing sasl_authcid > > and sasl_authzid. > > . > > The realm is appended to authentication and authorisation identities. > > Unfortunately I'm having trouble rewriting that paragraph because I > just don't understand the second sentence at all. Other mechanisms > may need... what? I've removed the second paragraph and added the Kerberos note as a third paragraph which should be a bit clearer (but I must say I'm no expert in the fields of SASL, GSSAPI and Kerberos). Attached are the templates as they are now. Thanks for your comments and also Christian's. They are much appreciated! -- -- arthur - adejong@debian.org - http://people.debian.org/~adejong --
Template: nslcd/ldap-uris
Type: string
_Description: LDAP server URI:
Please enter the Uniform Resource Identifier of the LDAP server. The format
is "ldap://<hostname_or_IP_address>:<port>/". Alternatively, "ldaps://" or
"ldapi://" can be used. The port number is optional.
.
When using an ldap or ldaps scheme it is recommended to use an IP address to
avoid failures when domain name services are unavailable.
.
Multiple URIs can be specified by separating them with spaces.
Template: nslcd/ldap-base
Type: string
_Description: LDAP server search base:
Please enter the distinguished name of the LDAP search base. Many sites use
the components of their domain names for this purpose. For example, the
domain "example.net" would use "dc=example,dc=net" as the distinguished name
of the search base.
Template: nslcd/ldap-auth-type
Type: select
__Choices: none, simple, SASL
Default: none
_Description: LDAP authentication to use:
Please choose what type of authentication the LDAP database should
require (if any):
.
* none: no authentication;
* simple: simple clear text binddn/password;
* SASL: any Simple Authentication and Security Layer mechanism.
Template: nslcd/ldap-binddn
Type: string
_Description: LDAP database user:
Enter the name of the account that will be used to log in to the LDAP
database. This value should be specified as a DN (distinguished name).
Template: nslcd/ldap-bindpw
Type: password
_Description: LDAP user password:
Enter the password that will be used to log in to the LDAP database.
Template: nslcd/ldap-sasl-mech
Type: select
Choices: auto, LOGIN, PLAIN, NTLM, CRAM-MD5, DIGEST-MD5, GSSAPI, OTP
_Description: SASL mechanism to use:
Choose the SASL mechanism that will be used to authenticate to the LDAP
database:
.
* auto: auto-negotiation;
* LOGIN: deprecated in favor of PLAIN;
* PLAIN: clear-text user/password mechanism;
* NTLM: NT LAN Manager authentication mechanism;
* CRAM-MD5: challenge-response scheme based on HMAC-MD5;
* DIGEST-MD5: HTTP Digest compatible challenge-response scheme;
* GSSAPI: used for Kerberos;
* OTP: a One Time Password mechanism.
Template: nslcd/ldap-sasl-realm
Type: string
_Description: SASL realm:
Enter the SASL realm that will be used to authenticate to the LDAP
database.
.
The realm is appended to authentication and authorization identities.
.
For GSSAPI this can be left blank to use information from the Kerberos
credential cache.
Template: nslcd/ldap-sasl-authcid
Type: string
_Description: SASL authentication identity:
Enter the SASL authentication identity that will be used to authenticate to
the LDAP database.
.
This is the login used in LOGIN, PLAIN, CRAM-MD5, and DIGEST-MD5 mechanisms.
Template: nslcd/ldap-sasl-authzid
Type: string
_Description: SASL proxy authorization identity:
Enter the proxy authorization identity that will be used to authenticate to
the LDAP database.
.
This is the object in the name of which the LDAP request is done.
This value should be specified as a DN (distinguished name).
Template: nslcd/ldap-sasl-secprops
Type: string
_Description: Cyrus SASL security properties:
Enter the Cyrus SASL security properties.
Allowed values are described in the ldap.conf(5) manual page
in the SASL OPTIONS section.
Template: nslcd/ldap-sasl-krb5-ccname
Type: string
Default: /var/run/nslcd/nslcd.tkt
_Description: Kerberos credential cache file path:
Enter the GSSAPI/Kerberos credential cache file name that will be used.
Template: nslcd/ldap-starttls
Type: boolean
_Description: Use StartTLS?
Please choose whether the connection to the LDAP server should use
StartTLS to encrypt the connection.
Template: nslcd/ldap-reqcert
Type: select
__Choices: never, allow, try, demand
_Description: Check server's SSL certificate:
When an encrypted connection is used, a server certificate can be requested
and checked. Please choose whether lookups should be configured to require
a certificate, and whether certificates should be checked for validity:
.
* never: no certificate will be requested or checked;
* allow: a certificate will be requested, but it is not
required or checked;
* try: a certificate will be requested and checked, but if no
certificate is provided it is ignored;
* demand: a certificate will be requested, required, and checked.
.
If certificate checking is enabled, at least one of the tls_cacertdir or
tls_cacertfile options must be put in /etc/nslcd.conf.
Template: libnss-ldapd/nsswitch
Type: multiselect
Choices: aliases, ethers, group, hosts, netgroup, networks, passwd, protocols, rpc, services, shadow
_Description: Name services to configure:
For this package to work, you need to modify your /etc/nsswitch.conf to use
the ldap datasource.
.
You can select the services that should have LDAP lookups enabled. The
new LDAP lookups will be added as the last datasource. Be sure to review
these changes.
Template: libnss-ldapd/clean_nsswitch
Type: boolean
Default: false
_Description: Remove LDAP from nsswitch.conf now?
The following services are still configured to use LDAP for lookups:
${services}
but the libnss-ldapd package is about to be removed.
.
You are advised to remove the entries if you don't plan on using LDAP for
name resolution any more. Not removing ldap from nsswitch.conf should, for
most services, not cause problems, but host name resolution could be affected
in subtle ways.
.
You can edit /etc/nsswitch.conf by hand or choose to remove the entries
automatically now. Be sure to review the changes to /etc/nsswitch.conf if you
choose to remove the entries now.
Template: libpam-ldapd/enable_shadow Type: boolean Default: true _Description: Enable shadow lookups through NSS? To allow LDAP users to log in, the NSS module needs to be enabled to perform shadow password lookups. The shadow entries themselves may be empty - that is, there is no need for password hashes to be exposed. See http://bugs.debian.org/583492 for background. . Please choose whether /etc/nsswitch.conf should have the required entry added automatically (in which case it should be reviewed afterwards) or whether it should be left for an administrator to edit manually.
Attachment:
signature.asc
Description: This is a digitally signed message part