Applies To:
Show VersionsBIG-IP APM
- 13.1.5, 13.1.4
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.
Task summary
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-Failover device group, configuration data is synchronized automatically or manually using ConfigSync. ConfigSync has no effect on local user databases, however.
For local user database data to be synchronized across devices, the devices must be included in a Sync-Failover device group. In a Sync-Failover 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 updates to a local user database
Administrators can use the Configuration utility to update user data in a local database instance. A Local Database action in an access policy can be configured to update user data also. When this is the case, the act of changing user data from the Configuration utility can prevent an access policy from functioning correctly, that is, the access policy might fail to lock users out.
Depending on how a Local Database action is configured, it can modify the number of login failures and the locked out status for a given user. For a user that is not found in the local database, the Local Database action can dynamically create a user record and use it to lock the user out. To keep the user locked out, the user record must be retained for the lockout interval. (Dynamically created users are deleted automatically after a configurable period of time.)
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.
Furthermore, you can use the local database to count login failures by users, whether or not they are found in a user database, and locking them out for a period of time. (This is possible whether authentication occurs against an external AAA server, or a local user database.) You can accomplish these tasks by using the BIG-IP® system's Local Database actions to read and write information from an access policy.
Task summary
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 and provides a good example of using the Local Database action to lock users out of an external AAA server.
AD auth and LocalDB lockout macro
- 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).
AD auth and LocalDB lockout macrocall in an access policy
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 updates to a local user database
Administrators can use the Configuration utility to update user data in a local database instance. A Local Database action in an access policy can be configured to update user data also. When this is the case, the act of changing user data from the Configuration utility can prevent an access policy from functioning correctly, that is, the access policy might fail to lock users out.
Depending on how a Local Database action is configured, it can modify the number of login failures and the locked out status for a given user. For a user that is not found in the local database, the Local Database action can dynamically create a user record and use it to lock the user out. To keep the user locked out, the user record must be retained for the lockout interval. (Dynamically created users are deleted automatically after a configurable period of time.)
Authenticating users and locking them out with a local database
Sample access policy (with logging action on the User Locked Out branch)
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.
Task summary
Creating an access policy to branch based on local DB group membership
Sample access policy that uses local user DB groups in a branching strategy