Server profiles
Prev | Chapter 2. 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.

You can create a new server profile by simply entering its name and password. After you created a new profile you can go back to the profile login and edit your new server profile.

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://.

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.

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

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.

LAM supports two methods for login. 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))").

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.

- 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.

### 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 2. Configuration | Home | Chapter 3. Managing entries in your LDAP directory