contact LDAP directory server for
login_ldap utility contacts an LDAP
server to authenticate a user.
Available options are:
- Print debugging information.
- Specify the service. Currently only “login” and
“response” are supported. The challenge service is not
supported, but it is not an error to specify this service. If this
login_ldapwill request the response service.
- This option is for compatibility and is ignored.
login_ldap searches for the
user on the LDAP server based on the filter parameters
in the configuration file. If the user is found, it will try to bind to it
using the supplied password.
login_ldap uses the
login.conf(5) variable to determine the location of the configuration
file. If no ldap-conffile can be found, it will fall
back to /etc/login_ldap.conf. The configuration file
must be owned by root with group auth and permissions 0640.
The login_ldap.conf file takes one key value pair per line separated by a ‘=’. No spaces are allowed between the ‘=’ and value. The key may have leading and trailing whitespaces. Empty lines and lines starting with a ‘#’ are ignored.
login_ldap utility requires the
- The hostname of the LDAP server or an LDAP URL. The LDAP URL is described
in the following format:
The following protocols are supported:
- Connect with TCP in plain text. This is the default.
- Connect with TLS. The default port is 636.
- Connect with TCP and enable TLS using the StartTLS operation.
Multiple host entries are supported and are tried in order of appearance.
- Point in the LDAP server's Directory Information Tree
login_ldapshould begin searching for user objects. This option can be omitted if the binddn points directly to the user entry.
- DN used by
login_ldapto bind to the LDAP server. If no basedn is set, this is used to bind directly to the user and uses the user supplied password. Use FORMAT FILTERS to specify the username in this case.
If basedn is set, it is used together with bindpw to bind to the LDAP server and search for the user entry based on filter and scope. If binddn is omitted and basedn is set, an anonymous bind is used to search for the user entry.
In most cases, you will need to configure additional options. The
following entries to login_ldap.conf are also recognised by
login_ldap and are optional:
- Password used by
login_ldapto bind to the LDAP server. Leave this out for a passwordless bind.
- LDAP search filter (in accordance with RFC 1558) which identifies the
objectclasses and attributes necessary for
login_ldapto locate the user object. See the FILTER FORMATS section for details.
- Time in seconds to wait for the LDAP server to respond to a query. The default is 60 seconds per query, with up to four queries occurring.
- The directory scope when performing the user lookup (first pass) search.
Acceptable values are:
- Base object search
- One level search
- Full subtree search
The default is sub if scope is unspecified.
- The pathname of the CA used for SSL certificates.
- The directory containing the certificates of trusted CAs.
An additional groupcheck can be performed to verify the user is allowed to log in. This can be done by specifying gbasedn, gfilter and optionally gscope. See basedn, filter and scope for semantics. These checks are performed by the binddn user.
The following format specifiers are valid for the filter:
- Username. The username of the user to be authenticated as specified by the user argument.
- Hostname. The hostname of the host the user is trying to authenticate on, as returned by gethostname(3) and displayed by hostname(1).
- The dn of the user attempting authentication as returned from the first pass of the search. This option is only available to gfilter and gbasedn.
- A literal ‘%’ character.
- Example configuration file.
ldap(1), login(1), login.conf(5), ldapd(8), ypldap(8)
login_ldap utility first appeared in
OpenBSD 3.3 ports and was later mostly rewritten by
Martijn van Duren
and imported into OpenBSD 6.8.
login_ldap utility was originally
Michael Erdely <firstname.lastname@example.org>
As there is no SASL support, passwords are sent to the LDAP server. TLS should be used to protect the password in transit.