3.2. Configuring UserIdResolvers

The idea of UserIdResolvers and Realms is described in section A.16.2 on page 75. You should read this to get an idea of how to setup LinOTP in the right way.

Open Config → LinOTP Server Configuration. Within the tab “Userstores” all the UserIdResolvers that hold the user data can be defined. LinOTP only needs read access to those user stores. You can define as many UserIdResolvers as you like to. There are three possible types at the moment:

LDAP
Which can be used to read users from LDAP servers like OpenLDAP, Active Directory and Novell eDirectory.
SQL
Which can be used to read users from a vast number of different SQL servers.
Flatfile
Which can be used to read the users from any flat file located on the LinOTP server. This would usually be /etc/passwd but can be any other file, too.

3.2.1. Configuring LDAP UserIdResolver

The LDAPIdResolver (Figure 9) can be used to resolve user loginnames via OpenLDAP, Active Directory or Novell eDirectory.

To get redundancy, you can configure more than one LDAP server. To do this, you may enter more than one server in the LDAP Server configuration URI. Lets say, you have got two domain controllers with the addresses 192.168.1.31 and 192.168.1.32. (You may also use FQDN [2]). Then you need to enter the line:

ldap://192.168,1.31, ldap:192.168.1.32

If LinOTP fails to contact the first LDAP server, it will try to contact the second one. If the second one can be contacted, it will be set first then.

Note

Before saving your configuration, you should push the button “Test LDAP connection” to see, if your settings enable the LinOTP server to connect to the LDAP successfully. If you have got problems setting up your LDAP connection, you may monitor your LinOTP log file /var/log/linotp/linotp.log on your LinOTP server. This may give you some clues about problems with the LDAP connection. Also see section LDAP/Active Directory Connection.

Loginname attribute
is the attribute that holds the name, the user will use to login.
Search filter
is used to filter the user objects found within the configured base DN [1]. You can only assign tokens to those users found by the search filter.
User Filter
in turn will be used to resolve the users the other way round. E.g. if the user logs in, he will provide the loginname. The login name will be replaced with the “%s” in the user filter, to resolve the login name to the distinguished name of the user object in the LDAP.

Attribute mapping will fetch more user information from your LDAP server like:

username, phone, groups, mobile, email, surname, givenname

The required attribute is username. All other attributes are optional.

Using the button “Preset Active Directory” you can change the default LDAP attribute definition to fit the needs in an Active Directory environment. In this case you will not need to change the attribute definition manually. After having entered all necessary values, you need to push “Apply” to store the changes. The changes will be sent to the server as soon as you push the button “OK” of the Configuration Dialog.

Note

When configuring a LDAPIdResolver for connecting to Active Directory and your BaseDN is set to your top level domain components like dc=mydomain,dc=com you should also select the option “No anonymous referral chasing”.

3.2.2. Configuring SQL UserIdResolver

The SQL UserIdResolver can be used to resolve loginnames via SQL databases. You need to enter a valid database driver like sqlite, mysql, postgresql, oracle, sapdb, mssql as described in the sqlalchemy documentation:

You need to enter the table name, where the users are stored in. In the “Attribute mapping” you may enter the fields:

username, phone, groups, mobile, email, surname, givenname, password

The attributes username and userid are required. All other attributes are optional. The password column in the attribute mapping holds a crypted password, where the first two bytes are the salt that was used to crypt the password. The tool create-sqlidresolver-user.py can be used to create crypted passwords.

E.g. if your user table has a column “loginname” and a primary key “id”, you might at least enter:

{ “username”:”loginname”, “userid”:”id”  }
In the field database encoding
you enter the encoding of your database. This should be “utf-8” but could also be something like “latin1”.
The field Where statement
can be used to filter the users used for LinOTP. If you e.g. only want to use with an ID bigger than 5 you could enter a where statement like “id>5”.

If your usernames or other fields contain non-ASCII characters you probably use another encoding. In this case you can enter the information, what encoding your database table uses.

Usually it might be latin1 or utf-8. You can also add additional parameters that get added to the connection string. The parameters very much depend on the used driver. If you are only using ASCII characters you will not have to bother with this setting. E.g. for a mysql database containing utf-8 tables and storing usernames with non-ASCII characters, you should add the parameters “use_unicode=1&charset=utf8”.

After having entered all necessary values, you need to push the button “Apply” to store the changes. The changes will be sent to the server as soon as you push the button “OK” of the Configuration Dialog.

3.2.3. Configuring Passwd (Flatfile) UserIdResolver

The simplest userstore are flat files on the LinOTP server. These flat files can be used by configuring the Flatfile UserIdResolver. You only need to enter the filename of the file on the LinOTP server. The default filename would be /etc/passwd. Other files need to follow the syntax of the passwd file, i.e. each line represents a user entry in each line, all fields are separated by a colon (:)

The fields represent the following

  1. column: loginname (used as loginname by LinOTP)
  2. column: password (used for otpin=1 policies and login to selfservice) [3]
  3. column: numerical id (used as unique ID by LinOTP)
  4. column: (not used – usually this would contain the groupid)
  5. column: description. Containing information about given name, surname, email and phone numbers. According to [4] this field is a comma seperated list of 5 items.
    1. item: Name. The name is split by a blank into given name and surname.
    2. item: (not used – usually this would contain the room number)
    3. item: Used as mobile number.
    4. item: Used as phone number.
    5. item: Used as email address.
  6. column: (not used – usually this would contain the home directory)
  7. column: (not used – usually this would contain the login shell)

After having entered all necessary values, you need to push “Apply” to store the changes. The changes will be sent to the server as soon as you push the button “OK” of the Configuration Dialog.

[1]Distinguished Name
[2]Fully qualified domain name
[3]The file /etc/passwd does not contain the password. Using the tool linotp-create-pwidresolver-user you can create valid lines, that also contain the password.
[4]http://en.wikipedia.org/wiki/Passwd