7.5. Enrollment Policies

Enrollment Policies are checked during the enrollment process of a token. Be it during administrative enrollment or user self enrollment.

7.5.1. Token limits per Realm

You may limit the number of tokens that are managed within a realm. This is done by defining a policy consisting of

• Policy name: This is the unique name of the policy.
• Scope: You need to set this to enrollment.
• Realm: Enter the name of the realm here.
• Action: This field is comma separated. It should contain the keyword tokencount = <tokennumber>.

Using the action tokencount you may allocate specified numbers of tokens to your different realms.

You may for example have a license with 1000 tokens, but one of your five realms should only be able to manage a maximum of 80 tokens, since this realm is managed by another department.

Note

Each realm, for which no tokencount is defined, may use as many tokens as possible.

7.5.2. Token limits per user

You may limit the number of tokens that can be assigned to a user. This is done by defining a policy consisting of

• Policy name: This is the unique name of the policy.
• Scope: You need to set this to enrollment.
• Realm: Enter the name of the realm, that contains the users who should be restricted in the number of tokens owned.
• Action: This field is comma separated. It should contain the keyword maxtoken = <tokennumber>.
• User: Here you can enter a list of usernames or resolvers. See Users in policies for more details.

Note

If there is no maxtoken defined for a realm, then you may enroll as many tokens as possible for a single user.

7.5.3. Random OTP PIN

During enrollment a random OTP PIN may be set. This is done per realm by defining the policy:

• Policy name: This is the unique name of the policy.
• Scope: You need to set this to enrollment.
• Realm: Enter the name of the realm, that contains the users who should be restricted in the number of tokens owned.
• Action: This field is comma separated. It should contain the keyword otp_pin_random = <length>. This will create a random OTP PIN during token initialization of the given length.
• User: Here you can enter a list of usernames or resolvers. See Users in policies for more details.

Note

If there is no otp_pin_random defined for a realm, than no PIN is set during enrollment. If a random OTP PIN is set, it is not possible to view this PIN. This means, that the user or the administrator has to reset the OTP PIN.

7.5.4. Encrypted OTP PIN

During setting an OTP PIN this policy defines, if the OTP PIN will be stored as hashed value or as an encrypted value. The default behavior is to store the OTP PIN as a hashed value.

• Policy name: This is the unique name of the policy.
• Scope: You need to set this to enrollment.
• Realm: Enter the name of the realm, that contains the tokens, the policy should be valid for.
• Action: This field is a comma separated list. It should contain the keyword otp_pin_encrypt = 1.

Note

The encrypted value can be decrypted again. This is used in case of getOtp function. Usually it is a good idea to leave this untouched.

7.5.5. Tokenlabels

It is possible to set a token label for the Google Authenticator and OATH token. You may define a policy, what this token label should be made of.

• Policy name: This is the unique name of the policy.
• Scope: enrollment
• Realm: Enter the name of the realm, that contains the tokens, the policy should be valid for. The tokens of users in this realm will be labeled accordingly.
• Action: This is a comma separated list. It should contain tokenlabel=<string>, where <string> is a regular expression, that works like this: - <u> will be replaced with the name of the user - <r> will be replaced with the name of the realm - <s> will be replaced with the serial number of the token.
• User: Here you can enter a list of usernames or resolvers. See Users in policies for more details.

If no policy can be found or the token is not assigned to any user, then the token will be labeled with the serial number.

Example: tokenlabel=<u>@<r> will result in a label like username@realm1. tokenlabel=ourtokens_<s> will result in something like outtokens_oath1278489

7.5.6. Auto Assignment

Enrolling tokens to users can be a hard process to do. LinOTP provides a way to assign existing tokens to users in the most easy way. If Auto Assigment is configured for a realm tokens can be assigned like this:

First you need to import the token seed file and set the token realm of these tokens.

Then you need to configure a autoassignment policy.

After having done so, the enrollment workflow is as follows:

1. Tokens are set to realmA but not assigned.
2. The user, who is in realmA, grabs any of those realmA tokens.
3. Now he authenticates against LinOTP using his userstore password, which will be either the passwd-password, the LDAP-password or his SQL-password and an OTP value from the token he just grabbed.
4. LinOTP will check,
   • if the autoassignment policy is set for this realm,
   • if the user has not yet any token assigned,
   • if the user provided the right password,
   • and then look up the token for the given OTP value in the tokens of realmA that are not yet assigned.
5. LinOTP then will assign the found token to the user and set the userstore password as OTP PIN.
6. The user is successfully authenticated and will have to use this very token for all future logins.

The autoassigment policy is defined like this:

• Policy name: This is the unique name of the policy.
• Scope: enrollment
• Realm: Enter the name of the realm, that contains the tokens, the policy should be valid for. The tokens of users in this realm will be labeled accordingly.
• Action: This is a comma separated list. It should contain autoassignment=<int>, where <int> is either 6 or 8, depending on the length of the tokens OTP value.
• User: Here you can enter a list of usernames or resolvers. See Users in policies for more details.

7.5.7. Ignore Auto Assignment Pin

When using the autoassignment feature the user is identified by his login name and by the password (pin), while the token is identified by the otp value. If the identification of user and token was successful, by default the password of the user will be used as pin of the token. To prevent this behaviour the ignore_autoassignment_pin policy can be set.

7.5.8. Lost token

When a user looses a token, the help desk can enroll a temporary token that will replace the lost token. The lost token will be disabled. The OTP PIN of the lost token will be used for the new temporary token. The administrator or the help desk employee do not need to know and can not know the OTP PIN. The temporary token will be a long static password and will only be valid for a restricted amount of days. The length of the password and the validity period can be configured using an enrollment policy:

• Scope: enrollment
• Action: lostTokenPWLen=<length of password> (default = 10)
• Action: lostTokenValid=<length of validity period in days> (default = 10)
• Action: lostTokenPWContents=<contents of the temporary password>
• User: Here you can enter a list of usernames or resolvers. See Users in policies for more details.

Contents

The contents is described by these characters:

C: The password will contain upper characters.

c: The password will contain lower characters.

n: The password will contain digits/numbers.

s: The password will contain special characters.

Example: A temporary token with lostTokenPWLen=10, lostTokenValid=30 will get a 10 characters static password created and will be valid for the next 30 days.