NAV can authenticate web users externally via an LDAP server. This article describes how this feature works, and how to configure it.
Configuration for LDAP authentication is stored in the config file
webfront/webfront.conf
, in the [ldap]
section. You should restart
Apache to make sure any config changes take effect.
Available options:
New in version 4.4.
Can be used to customize the search filter used when verifying group memberships using the require_group option (specifically for group schemas that register user distinguished names as member values).
The default value, (member=%%s)
is fine for most purposes. Microsoft AD
will support a recursive group search operator, so that nested group
memberships are allowed. Use a value of
(member:1.2.840.113556.1.4.1941:=%%s)
to enable this AD extension
New in version 3.7.
Selects which method to use for finding users in the LDAP directory. Valid
settings are direct and search. direct will cause the user’s DN to be
constructed as <uid_attr>=<login name>,<basedn>
. Specifying search
will bind to the LDAP directory as <manager>, if specified, and search for
<uid_attr>=<login name>
. If a bind suffix is specified for AD-style
binds, using a manager account can be avoided.
New in version 4.4.
When set to a doman suffix, such as @ad.example.com
, the username to
bind as will be constructed from the login name and this suffix. This type
of direct bind is supported by Microsoft AD, and can be used to avoid having
to configure a manager user to search the catalog.
New in version 3.7.
The DN of a user to bind as when searching for users in the directory. Can be omitted if authentication is not required for searches, or the lookupmethod is direct.
New in version 3.7.
Password needed to bind as the manager user.
New in version 3.15.
Specifies the character encoding to expect from the LDAP catalog. The default value is UTF-8.
A typical setup for an OpenLDAP server looks like this:
[ldap]
enabled = yes
server = ldap.example.com
port=389
basedn= ou=people,dc=example,dc=com
require_group= cn=noc-operators,cn=groups,dc=example,dc=com
A typical setup for Microsoft Active Directory would look more like this:
[ldap]
enabled = yes
server = ad.example.com
port = 636
encryption = ssl
uid_attr = sAMAccountName
basedn = ou=people,dc=example,dc=com
lookupmethod = search
manager = cn=John Doe,ou=people,dc=example,dc=com
managerpassword = secret
Or, without a manager account, like this:
[ldap]
enabled = yes
server = ad.example.com
port = 636
encryption = ssl
uid_attr = sAMAccountName
basedn = ou=people,dc=example,dc=com
suffix = @ad.example.com
lookupmethod = search
If you are using TLS or SSL encryption with your LDAP server, you may need to
configure your OpenLDAP installation with the proper certificates. On most
systems, you should see the man page ldap.conf(5) for details. On
Debian, this config file is located in /etc/ldap/
.
If you are using a self-signed certificate, you should put that certificate
(in pem format) somewhere accessible on your NAV server, and add the
TLS_CACERT option to ldap.conf
:
TLS_CACERT /path/to/my/certificate.pem
When LDAP authentication is enabled, NAV will, if necessary, attempt to do authenticated binds against the LDAP tree when users log in.
When the user is created locally by the admin
When the user does not exist in the local NAVdb
When the user exists in the local NAVdb, and has previously been retrieved from the LDAP server
Users should always be able to login to NAV to diagnose network problems, even if the LDAP server happens to be unreachable (this could be the very problem you want to inspect). The above documented authentication procedure makes sure that any user known to NAV will be able to log in as long as NAV is up. LDAP-based users that have never logged in to NAV before will not be able to do so as long as the LDAP server is unreachable.
Users that have been created locally in NAV will not be authenticated with the LDAP server when LDAP authentication is enabled at a later time. The only way to do this is to tinker with the SQL database.
Run psql nav nav, use the password from db.conf
. List the
existing accounts:
nav=# select * from account;
id | login | name | password | ext_sync
------+---------+-------------------+----------+----------
0 | default | Default User | |
1 | admin | NAV Administrator | password |
1000 | foo | Foo Bar | password |
1001 | arthur | A. Dent | password |
1002 | zaphod | Z. Beeblebrox | password | ldap
(5 rows)
The ext_sync column defines what external mechanism is used to authenticate a user. As you can see, only the user zaphod will be authenticated using LDAP here. To allow the user arthur to be authenticated using LDAP (assuming the LDAP server knows of a user with that login name), issue the following SQL statement:
UPDATE account SET ext_sync='ldap' WHERE login='arthur';