Server profiles
Prev | Chapter 3. Configuration | Next

## Server profiles

The server profiles store information about your LDAP server (e.g. host name) and what kind of accounts (e.g. users and groups) you would like to manage. There is no limit on the number of server profiles. See the typical scenarios about how to structure your server profiles.

### Manage server profiles

Select "Manage server profiles" to open the profile management page.

Here you can create, rename and delete server profiles. The passwords of your server profiles can also be reset.

You may also specify the default server profile. This is the server profile which is preselected at the login page. It also specifies the language of the login and configuration pages.

Templates for new server profiles

You can create a new server profile based on one of the built-in templates or any existing profile. Of course, the account types and selected modules can be changed after you created your profile.

Built-in templates:

- addressbook: simple profile for user management with inetOrgPerson object class

- samba3: Samba 3 users, groups, hosts and domains

- unix: Unix users and groups (posixAccount/Group)

- windows_samba4: Active Directory user, group and host management

All operations on the profile management page require that you authenticate yourself with the configuration master password.

### Editing a server profile

Please select you server profile and enter its password to edit a server profile.

Each server profile contains the following information:

- General settings: general settings about your LDAP server (e.g. host name and security settings)

- Account types: list of account types (e.g. users and groups) that you would like to manage and type specific settings (e.g. LDAP suffix)

- Modules: list of modules which define what account aspects (e.g. Unix, Samba, Kolab) you would like to manage

- Module settings: settings which are specific for the selected account modules on the page before

#### General settings

Here you can specify the LDAP server and some security settings.

The server address of your LDAP server can be a DNS name or an IP address. Use ldap:// for unencrypted LDAP connections or TLS encrypted connections. LDAP+SSL (LDAPS) encrypted connections are specified with ldaps://. The port value is optional. TLS cannot be combined with ldaps://.

Hint: If you use a master/slave setup with referrals then point LAM to your master server. Due to bugs in the underlying LDAP libraries pointing to a slave might cause issues on write operations.

LAM includes an LDAP browser which allows direct modification of LDAP entries. If you would like to use it then enter the LDAP suffix at "Tree suffix".

The search limit is used to reduce the number of search results which are returned by your LDAP server.

The access level specifies if LAM should allow to modify LDAP entries. This feature is only available in LAM Pro. LAM non-Pro releases use write access. See this page for details on the different access levels.

Advanced options

Display name: Sometimes, you may not want to display the server address on the login page. In this case you can setup a display name here (e.g. "Production").

Follow referrals: By default LAM will not follow LDAP referrals. This is ok for most installations. If you use LDAP referrals please activate the referral option in advanced settings.

Paged results: Paged results should be activated only if you encounter any problems regarding size limits on Active Directory. LAM will then query LDAP to return results in chunks of 999 entries.

Show deleted entries: This is for Active Directory and Samba 4 only. It will unhide LDAP entries in "CN=Deleted Objects,DC=...". You can use this to browse and restore these entries in tree view.

Referential integrity overlay: Activate this checkbox if you have any server side extension for referential integrity in place. In this case the server will cleanup references to LDAP entries that are deleted.

The following actions are skipped in this case:

- Users: group of (unique) names: memberships are not deleted when user is deleted

- Users: organizational roles: role assignments are not deleted when user is deleted

- Groups: groupOf(Unique)Names: memberships are not deleted when group is deleted

Hide password prompt for expired password: Hides the password prompt when a user with expired password logs into LAM.

LAM is translated to many different languages. Here you can select the default language for this server profile. The language setting may be overridden at the LAM login page.

Please also set your time zone here.

LAM can manage user home directories and quotas with an external script. You can specify the home directory server and where the script is located. The default rights for new home directories can be set, too.

Note: This requires lamdaemon to be installed on the remote server. This comes as separate package for DEB/RPM. See here.

Script server format:

- "server": "server" is the DNS name of your script server

- "server:NAME": NAME is the display name of this server

- "server:NAME:/prefix": /prefix is the directory prefix for all operations. E.g. creating a home directory "/home/user" would create "/prefix/home/user" then.

You can provide a fixed user name. If you leave the field empty then LAM will use your current account (the account you used to login to LAM).

There are two possibilities to connect to your home directory/quota server:

- SSH key (recommended): Please generate a SSH key pair and provide the location to the private key file. If the key is protected by a password you can also specify it here.

- Password: If you do not set a SSH key then LAM will try to connect with your current account (the password you used to login to LAM).

LAM Pro users may directly set passwords from list view. You can configure if it should be possible to set specific passwords and showing password on screen is allowed.

LAM Pro users can send out changed passwords to their users. Here you can specify the options for these mails.

If you select "Allow alternate address" then password mails can be sent to any address (e.g. a secondary address if the user account is also bound to the mailbox).

LAM supports two methods for login:

- Fixed list

- LDAP search

The first one is to specify a fixed list of LDAP DNs that are allowed to login. Please enter one DN per line.

The second one is to let LAM search for the DN in your directory. E.g. if a user logs in with the user name "joe" then LAM will do an LDAP search for this user name. When it finds a matching DN then it will use this to authenticate the user. The wildcard "%USER%" will be replaced by "joe" in this example. This way you can provide login by user name, email address or other LDAP attributes.

Additionally, you can enable HTTP authentication when using "LDAP search". This way the web server is responsible to authenticate your users. LAM will use the given user name + password for the LDAP login. You can also configure this to setup advanced login restrictions (e.g. require group memberships for login). To setup HTTP authentication in Apache please see this link and an example for LDAP authentication here.

Hint: LDAP search with group membership check can be done with either HTTP authentication or LDAP overlays like "memberOf" or "Dynamic lists". Dynamic lists allow to insert virtual attributes to your user entries. These can then be used for the LDAP filter (e.g. "(&(uid=%USER%)(memberof=cn=admins,ou=groups,dc=company,dc=com))").

Global password policy override

This allows you to override some password policy options of LAM's global password policy (LAM main configuration). You can increase and decrease the values of the global policy.

2-factor authentication

LAM supports 2-factor authentication for your users. This means the user will not only authenticate by user+password but also with e.g. a token generated by a mobile device. This adds more security because the token is generated on a physically separated device (typically mobile phone).

The token is validated by a second application. LAM currently supports:

- privacyIdea

- YubiKey

- Duo

- WebAuthn/FIDO2

- Okta

- OpenID

Configuration options:

privacyIDEA

- Base URL: please enter the URL of your privacyIDEA instance

- User name attribute: please enter the LDAP attribute name that contains the user ID (e.g. "uid").

- Optional: By default LAM will enforce to use a token and reject users that did not setup one. You can set this check to optional. But if a user has setup a token then this will always be required.

- Disable certificate check: This should be used on development instances only. It skips the certificate check when connecting to verification server.

Please note that LAM needs to authenticate to privacyIdea with the user's user name and password WITHOUT second factor. This is needed to get the list of tokens that are setup for the user. You can setup a separate policy (scope: authentication) for LAM inside privacyIdea that has IP restriction ("Client" setting) to LAM's server IP and an action "otppin" "none".

YubiKey

- Base URLs: please enter the URL(s) of your YubiKey verification server(s). If you run a custom verification API such as yubiserver then enter its URL (e.g. http://www.example.com:8000/wsapi/2.0/verify). The URL needs to end with "/wsapi/2.0/verify". For YubiKey cloud these are "https://api.yubico.com/wsapi/2.0/verify", "https://api2.yubico.com/wsapi/2.0/verify", "https://api3.yubico.com/wsapi/2.0/verify", "https://api4.yubico.com/wsapi/2.0/verify" and "https://api5.yubico.com/wsapi/2.0/verify". Enter one URL per line.

- Client id: this is only required for YubiKey cloud. You can register here: https://upgrade.yubico.com/getapikey/

- Secret key: this is only required for YubiKey cloud. You can register here: https://upgrade.yubico.com/getapikey/

- Optional: By default LAM will enforce to use a token and reject users that did not setup one. You can set this check to optional. But if a user has setup a token then this will always be required.

- Disable certificate check: This should be used on development instances only. It skips the certificate check when connecting to verification server.

Duo

This requires to register a new "Web SDK" application in your Duo admin panel.

- User name attribute: please enter the LDAP attribute name that contains the user ID (e.g. "uid").

- Base URL: please enter the API-URL of your Duo instance (e.g. api-12345.duosecurity.com).

- Client id: please enter your client id.

- Secret key: please enter your client secret.

WebAuthn/FIDO2

See the WebAuthn/FIDO2 appendix for an overview about WebAuthn/FIDO2 in LAM.

Users will be asked to register a device during login if no device is setup.

- Domain: Please enter the WebAuthn domain. This is the public domain of the web server (e.g. "example.com"). Do not include protocol or port. Browsers will reject authentication if the domain does not match the web server domain.

- Optional: By default LAM will enforce to use a 2FA device and reject users that do not setup one. You can set this check to optional. But if a user has setup a device then this will always be required.

Okta

This requires to register a new application of type "Web".

There, you will need to configure LAM's 2-factor URLs as "Login redirect URIs" in the new application. They are "https://YOURDOMAIN/lam/templates/login2Factor.php" for admin interface and "https://YOURDOMAIN/lam/templates/selfService/selfService2Factor.php" for self service. You will get an error message during login with the URL to configure in case it was wrong.

On "Sign On" tab you need to add a rule that prompts for the factor.

LAM options:

- User name attribute: please enter the LDAP attribute name that contains the user ID (e.g. "mail").

- Base URL: please enter the URL of your Okta domain (e.g. https://mydomain.okta.com)

- Client id: please enter your application client id.

- Secret key: please enter your application secret key.

OpenID

This will use an OpenID server as 2nd factor for authentication.

LAM options:

- User name attribute: please enter the LDAP attribute name that contains the user ID (e.g. "uid").

- Base URL: please enter the URL of your OpenID client URL. The URL is the one before the "/.well-known/openid-configuration".

- Client id: please enter your application client id.

- Secret key: please enter your application secret key.

KeyCloack example configuration:

Create a new client, select "OpenID Connect" client type and enter a client ID.

Now enable "Client authentication" and enter the valid redirect URLs in the last step.

They are "https://YOURDOMAIN/lam/templates/login2Factor.php" for admin interface and "https://YOURDOMAIN/lam/templates/selfService/selfService2Factor.php" for self service. You will get an error message during login in case it was wrong. Then save the configuration.

Next, switch to tab "Credentials" to get the client secret.

Example configuration values:

- User name: uid

- Base URL: http://openidserver/auth/realms/master

- Client id: demo

- Secret key: 59bdf504-b76e-4138-8421-ef662b2c6c83

Remember device

You can allow users to remember the 2FA device for privacyIDEA, WebAuthn and YubiKey. When a device is remembered then users can login for the specified time without presenting their 2nd factor.

The password for the device remembering is used to authenticate the device data. It can be any long passphrase (use > 30 characters). LAM auto-generates one for you. If you change the passphrase then all device data gets invalid and users need to represent their 2nd factor again (which then can be saved again).

Login

After logging in with user + password LAM will ask for the 2nd factor. If the user has setup multiple factors then he can choose one of them.

Password

You may also change the password of this server profile. Please just enter the new password in both password fields.

#### Account types

LAM supports to manage various types of LDAP entries (e.g. users, groups, DHCP entries, ...). On this page you can select which types of entries you want to manage with LAM.

The section at the top shows a list of possible types. You can activate them by simply clicking on the plus sign next to it.

Each account type has the following options:

- LDAP suffix: the LDAP suffix where entries of this type should be managed

- List attributes: a list of attributes which are shown in the account lists

- Additional LDAP filter: LAM will automatically detect the right LDAP entries for each account type. This can be used to further limit the number of visible entries (e.g. if you want to manage only some specific groups). You can use "@@LOGIN_DN@@" as wildcard (e.g. "(owner=@@LOGIN_DN@@)"). It will be replaced by the DN of the user who is logged in.

- Hidden: This is used to hide account types that should not be displayed but are required by other account types. E.g. you can hide the Samba domains account type and still assign domains when you edit your users.

- Read-only (LAM Pro only): This allows to set a single account type to read-only mode. Please note that this is a restriction on functional level (e.g. group memberships can be changed on user page even if groups are read-only) and is no replacement for setting up proper ACLs on your LDAP server.

- Custom label: Here you can set a custom label for the account types. Use this if the standard label does not fit for you (e.g. enter "Servers" for hosts).

- No new entries (LAM Pro only): Use this if you want to prevent that new accounts of this type are created by your users. The GUI will hide buttons to create new entries and also disable file upload for this type.

- Disallow delete (LAM Pro only): Use this if you want to prevent that accounts of this type are deleted by your users.

On the next page you can specify in detail what extensions should be enabled for each account type.

#### Modules

The modules specify the active extensions for each account type. E.g. here you can setup if your user entries should be address book entries only or also support Unix or Samba.

Each account type needs a so called "base module". This is the basement for all LDAP entries of this type. Usually, it provides the structural object class for the LDAP entries. There must be exactly one active base module for each account type.

Furthermore, there may be any number of additional active account modules. E.g. you may select "Personal" as base module and Unix + Samba as additional modules.

#### Module settings

Depending on the activated account modules there may be additional configuration options available. They can be found on the "Module settings" tab. E.g. the Personal account module allows to hide several input fields and the Unix module requires to specify ranges for UID numbers.

### Cron jobs (LAM Pro)

LAM Pro can execute common tasks via cron job. This can be used to e.g. notify your users before their passwords expire.

#### LDAP and database configuration

Please add the LDAP bind user and password for all jobs. This LDAP account will be used to perform all LDAP read and write operations.

Next, select the database type where LAM should store job related data. Supported databases are SQLite and MySQL.

SQLite

This is a simple file based database. It needs no special database server. The database file will be located next to the server profile in config directory.

You will need to install the SQLite PDO module for PHP (pdo_sqlite.so). For Debian/Ubuntu this is located in package php-sqlite3.

MySQL

This will store all job data in an external MySQL database.

You will need to install the MySQL PDO module for PHP (pdo_mysql.so). For Debian/Ubuntu this is located in package php-mysql.

Steps to create a MySQL database and user:

# login
mysql -u root -p
# create a database
mysql> create database lam_cron;
#
mysql> CREATE USER 'lam_cron'@'%' IDENTIFIED BY 'password';
mysql> CREATE USER 'lam_cron'@'localhost' IDENTIFIED BY 'password';
# grant access for new user
mysql> GRANT ALL PRIVILEGES ON lam_cron.* TO 'lam_cron'@'%';
mysql> GRANT ALL PRIVILEGES ON lam_cron.* TO 'lam_cron'@'localhost';

Test your settings

After the LDAP and database settings are done you can test your settings.

Cron entry

LAM also prints the crontab line that you need to run the configured jobs on a daily basis. The command must be run as the same user as your webserver is running. You are free to change the starting time of the script or run it more often.

Dry-run: You can perform a dry-run of the job. This will not perform any actions but only print what would be done. For this please put "--dry-run" at the end of the command. E.g.:

/usr/share/ldap-account-manager/lib/runCronJobs.sh serverProfile lam --dry-run

#### Adding jobs

To add a new job just click on the "Add job" button and select the job type you need. The list of available jobs depends on your active account modules. E.g. the PPolicy job will only be available if you activated PPolicy user module.

Depending on the job type jobs may be added multiple times with different configurations. For descriptions about the available job types see next chapters.

Available jobs:

- PPolicy: Notify users about password expiration

- 389ds: Notify users about password expiration

- Shadow: Notify users about password expiration

- Shadow: Delete or move expired accounts

- Shadow: Notify users about account expiration

- Windows: Notify users about password expiration

- Windows: Notify users about account expiration

- Windows: Delete or move expired accounts

- Windows: Notify users about their managed groups

- FreeRadius: Delete or move expired accounts

- FreeRadius: Notify users about account expiration

- Qmail: Delete or move expired accounts

- Qmail: Notify users about account expiration

- OpenLDAP: Deactivate accounts based on last successful login

##### PPolicy: Notify users about password expiration

This will send your users an email reminder before their password expires.

You need to activate the PPolicy module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

LAM calculates the expiration date based on the last password change and the assigned password policy (or the default policy) using attributes pwdMaxAge and pwdExpireWarning. Negative values are possible to send mails when LDAP's warning time already started.

Examples:

Warning time (pwdExpireWarning) = 14 days, notification period = 10: LAM will send out the email 24 days before the password expires

Warning time (pwdExpireWarning) = 14 days, notification period = 0: LAM will send out the email 14 days before the password expires

No warning time (pwdExpireWarning), notification period = 10: LAM will send out the email 10 days before the password expires

Table 3.1. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before password expires.
Default password policy | Default PPolicy password policy entry (object class "pwdPolicy").

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### 389ds: Notify users about password expiration

This will send your users an email reminder before their password expires.

You need to activate the Account Locking module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

LAM calculates the expiration date based on the attribute passwordExpirationTime.

Table 3.2. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before password expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Shadow: Notify users about password expiration

This will send your users an email reminder before their password expires.

You need to activate the Shadow module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

LAM calculates the expiration date based on the last password change, the password warning time (attribute "shadowWarning") and the specified notification period. Negative values are possible to send mails when Shadow's warning time already started.

Examples:

Warning time = 14, notification period = 10: LAM will send out the email 24 days before the password expires

Warning time = 14, notification period = 0: LAM will send out the email 14 days before the password expires

Table 3.3. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before password expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Shadow: Delete or move expired accounts

You can automatically delete or move expired accounts. The job checks Shadow account expiration dates (not password expiration dates).

Table 3.4. Options

Option | Description
Delay | Number of days to wait after the account is expired.
Action | Delete or move accounts
Target DN | Move only: specifies the DN where accounts are moved

##### Shadow: Notify users about account expiration

This will send your users an email reminder before their whole account expires.

You need to activate the Shadow module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

Table 3.5. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before account expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Windows: Notify users about password expiration

This will send your users an email reminder before their password expires.

You need to activate the Windows module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

LAM calculates the expiration date based on the last password change and the domain policy.

Table 3.6. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before password expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Windows: Notify users about account expiration

This will send your users an email reminder before their whole account expires.

You need to activate the Windows module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

Table 3.7. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before account expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Windows: Delete or move expired accounts

You can automatically delete or move expired accounts.

Table 3.8. Options

Option | Description
Delay | Number of days to wait after the account is expired.
Action | Delete or move accounts
Target DN | Move only: specifies the DN where accounts are moved

##### Windows: Notify users about their managed groups

This will send your users an email with the groups they manage. This also includes a list of users in these groups. The users and groups are searched using the user+group account types that are specified in server profile.

You need to activate the Windows module for users to be able to add this job. The job can be added multiple times.

Table 3.9. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
HTML format | Send email as HTML instead of plain text.
Text | The email body text. Supports wildcards, see below.
Period | Defines how often the mail is sent (e.g. quarterly).

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

Use the wildcard "@@LAM_MANAGED_GROUPS@@" to insert the group listing. This wildcard is mandatory.

##### FreeRadius: Delete or move expired accounts

You can automatically delete or move expired accounts.

Table 3.10. Options

Option | Description
Delay | Number of days to wait after the account is expired.
Action | Delete or move accounts
Target DN | Move only: specifies the DN where accounts are moved

##### FreeRadius: Notify users about account expiration

This will send your users an email reminder before their FreeRadius account expires.

You need to activate the FreeRadius module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

Table 3.11. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before account expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### Qmail: Delete or move expired accounts

You can automatically delete or move expired accounts. The job reads the qmail deletion date of user accounts.

Table 3.12. Options

Option | Description
Delay | Number of days to wait after the account is expired.
Action | Delete or move accounts
Target DN | Move only: specifies the DN where accounts are moved

##### Qmail: Notify users about account expiration

This will send your users an email reminder before their Qmail account expires.

You need to activate the Qmail module for users to be able to add this job. The job can be added multiple times (e.g. to send a second warning at a later time).

Table 3.13. Options

Option | Description
From address | The email address to set as FROM.
Reply-to address | Optional Reply-to address for email.
CC address | Optional CC mail address.
BCC address | Optional BCC mail address.
Subject | The email subject line. Supports wildcards, see below.
Text | The email body text. Supports wildcards, see below.
Notification period | Number of days to notify before account expires.

Wildcards:

You can enter LDAP attributes as wildcards in the form @@ATTRIBUTE_NAME@@. E.g. to add the user's common name use "@@cn@@". For the common name it would be "@@cn@@".

There are also two special wildcards for the expiration date. @@EXPIRE_DATE_DDMMYYYY@@ will print the date as e.g. "31.12.2016". @@EXPIRE_DATE_YYYYMMDD@@ will print the date as e.g. "2016-12-31".

##### OpenLDAP: Deactivate accounts based on last successful login

This job deactivates all users that did not perform a successful login for a given time. It requires OpenLDAP with activated "lastBind" and "PPolicy" overlays.

You need to activate the Last login (lastBind) module for users to be able to add this job.

Table 3.14. Options

Option | Description
Delay | The number of days after the last successful login when to deactivate the account.

#### Job history

This will show the list of all executed job runs and their result.

### Typical scenarios

This is a list of typical scenarios how your LDAP environment may look like and how to structure the server profiles for it.

#### Simple: One LDAP directory managed by a small group of admins

This is the easiest and most common scenario. You want to manage a single LDAP server and there is only one or a few admins. In this case just create one server profile and you are done. The admins may be either specified as a fixed list or by using an LDAP search at login time.

#### Advanced: One LDAP server which is managed by different admin groups

Large organisations may have one big LDAP directory for all user/group accounts. But the users are managed by different groups of admins (e.g. departments, locations, subsidiaries, ...). The users are typically divided into organisational units in the LDAP tree. Admins may only manage the users in their part of the tree.

In this situation it is recommended to create one server profile for each admin group (e.g. department). Setup the LDAP suffixes in the server profiles to point to the needed organisational units. E.g. use ou=people,ou=department1,dc=company,dc=com or ou=department1,ou=people,dc=company,dc=com as LDAP suffix for users. Do the same for groups, hosts, ... This way each admin group will only see its own users. You may want to use LDAP search for the LAM login in this scenario. This will prevent that you need to update a server profile if the number of admins changes.

Attention: LAM's feature to automatically find free UIDs/GIDs for new users/groups will not work in this case. LAM uses the user/group suffix to search for already assigned UIDs/GIDs. As an alternative you can specify different UID/GID ranges for each department. Then the UIDs/GIDs will stay unique for the whole directory.

#### Multiple LDAP servers

You can manage as many LDAP servers with LAM as you wish. This scenario is similar to the advanced scenario above. Just create one server profile for each LDAP server.

#### Single LDAP directory with lots of users (>10 000)

LAM was tested to work with 10 000 users. If you have a lot more users then you have basically two options.

- Divide your LDAP tree in organisational units: This is usually the best performing option. Put your accounts in several organisational units and setup LAM as in the advanced scenario above.

- Increase memory limit: Increase the memory_limit parameter in your php.ini. This will allow LAM to read more entries. But this will slow down the response times of LAM.

Prev | Up | Next
Chapter 3. Configuration | Home | Self Service (LAM Pro)