Applies To:
Show VersionsBIG-IP APM
- 11.5.1
Overview: Configuring and administering a local user database
You can create multiple local user databases to provide on-box authentication, to control user access, to segment your users, and to store user information.
During access policy operation, you can read from and write to a local user database.
-
You can read from a local user database to:
- Determine whether a user is locked out of a local user database instance.
- Check the number of failed login attempts for a user.
- Check group membership for the user to determine which access policy branch to take.Note: Groups are text strings. You create them from the Configuration utility.
-
You can write to a local user database primarily to increment or reset the number of login failures for a user. You can also update the locked out status for the user; although this option provides flexibility, use it sparingly. Normally, locked out status is set programmatically.
About backing up and restoring users
You can export user data from a local user database instance to a comma-separated values (CSV) file. The purpose is to provide you with a way to back up user data, which you can import from the CSV file.
About local user database synchronization across devices
When BIG-IP systems are included in a Sync-only device group, configuration data is synchronized automatically or manually using ConfigSync. ConfigSync has no effect on local user databases, however. In a Sync-only device group, the active node provides the local user database data to the other nodes initially, and then provides updated data every five minutes.
Synchronization status
The date and time of the last high availability (HA) synchronization displays in the Configuration utility on the Local User List and Local Database Instance screens. If errors occur, they are logged and then available in Access Policy Manager reports.
About writing to a local user database from an access policy
Administrators using the Configuration utility to update user data need to know that user data can also be updated by access policies. When you include a Local Database action in an access policy and configure a write action in it, it can make these changes in a local user database instance.
Updates to local user databases in the Common partition
You can use the Local Database action to write to local user databases in the Common partition, in addition to the partition in which you create the access policy.
Changes to individual user data
The Local Database action can change these types of information for a user:
- Number of login failures
- Locked out status - If you change the locked out status for a user, you could change the result of other access policy actions, such as a local database read action, or a local database authentication action.
Addition and deletion of dynamic users
The Allow User Creation option of the Local Database action creates a user when one does not already exist in a local user database. You can use this option to track login attempts by users who are not found in the local user database and to lock them out for a period of time. Dynamically created users are removed from the database after 20 minutes.
Task summary
Configuring a local user database instance
Adding a user to a local user database instance
Forcing change of password for a local user database instance
Overview: Using a local user database to control authentication
You can authenticate users directly against a local user database using the Local DB Auth action from an access policy.
Also, you can use the local user database to track login failures and lock a user out for a period of time. (This is possible whether authentication occurs against an external AAA server, or a local user database.) Furthermore, you can use the local database to count login failures by users that are not found in a user database, and locking them out for a period of time. You can accomplish these tasks by using Local Database actions to read and write information from an access policy.
About locking a user out of an AAA server using a local user database
A macro, AD auth and LocalDB lockout, is available in the visual policy editor that provides a good example of using the Local Database action to lock users out of an external AAA server.
- A local database action (LocalDB - Read) reads the locked_out database property and determines whether the user is locked out.
- Exiting the LocalDB - Read action on the User Locked Out branch leads to a logging action and a Failure terminal.
- If the login (AD Auth) fails, a local database write action (LocalDB - Write (Incr))
increments the number of login failures by 1.Note: To keep actual logon attempts aligned with the number recorded by the LocalDB - Write (Incr) action (incrementing by 1), the Max Logon Attempts Allowed property in the AD Auth action is set to 1. If it was set to another number, for example 2, you would need to configure the LocalDB - Write (Incr) action to increment login failures by the same number, 2.
- A Loop terminal in the macro causes the macro to loop through the AD Auth and LocalDB - Write (Incr) actions until authentication succeeds or until the maximum number of logon attempts is surpassed and the macro exits through the Loop terminal.
- If the login, AD Auth, succeeds, a Local Database write action, LocalDB - Write (Reset), resets the user's login failures to 0 (zero).
In an access policy, three branches follow the macro:
- Successful: The user logged in successfully.
- Loop: The user failed to log in the maximum number of times and is locked out now.
- Failure: The user is locked out and does not get another chance to try to log in.
About writing to a local user database from an access policy
Administrators using the Configuration utility to update user data need to know that user data can also be updated by access policies. When you include a Local Database action in an access policy and configure a write action in it, it can make these changes in a local user database instance.
Updates to local user databases in the Common partition
You can use the Local Database action to write to local user databases in the Common partition, in addition to the partition in which you create the access policy.
Changes to individual user data
The Local Database action can change these types of information for a user:
- Number of login failures
- Locked out status - If you change the locked out status for a user, you could change the result of other access policy actions, such as a local database read action, or a local database authentication action.
Addition and deletion of dynamic users
The Allow User Creation option of the Local Database action creates a user when one does not already exist in a local user database. You can use this option to track login attempts by users who are not found in the local user database and to lock them out for a period of time. Dynamically created users are removed from the database after 20 minutes.
Task summary
Authenticating users and locking them out with a local database
Unlocking a user who is locked out of a local user database instance
Overview: Branching in an access policy based on local user database groups
You can store user group membership strings in a local user database instance. You can add one or more strings for a user to the database. The strings can reflect any grouping strategy that you want to apply. You can make user group-based branching decisions in an access policy by reading the group information for the user from the database, and creating rules for branching based on it.
Before you can perform this task, you need users and user group membership strings configured in a local user database instance. You also need an access profile.