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.

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.

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

1. On the Main tab, select Access > Authentication > Local User DB > Instances .
   The Instances screen displays.
2. Click Create New Instance.
   The Create New Local User DB Instance popup screen displays.
3. In the Name field, type a unique name for the database instance.
4. In the Lockout Interval (in seconds) field, type the number of seconds to keep a user account locked.
   The default setting is 600 seconds.
   Note: Access Policy Manager^® (APM^®) unlocks the user account after the interval completes; however, this does not occur immediately. The actual duration varies depending on the workload on the process that unlocks the user account.
5. In the Lockout Threshold field, type the maximum number of login failures to allow.
   The default setting is 3.
6. In the Dynamic User Remove Interval (in seconds) field, type the number of seconds to keep a user account locked.
   The default setting is 1800 seconds.
   Note: APM deletes the dynamic user after the interval completes; however, this does not occur immediately. The actual duration varies depending on the workload on the process that deletes the user.
7. Click OK.

1. On the Main tab, select Access > Authentication > Local User DB > Users .
   The Users screen displays.
2. Click Create New User.
   The Create New Local User screen opens and displays User Information settings.
3. In the User Name field, type the user name.
4. In the Password and Confirm Password fields, type the user's password.
5. Select the Force Password Change check box to force the user to change password the next time they log in.
   After the user successfully changes password, this check box is cleared. You can select this check box at any time to force the user to change password at their next log in.
6. From the Instance list, select a local user database instance.
   You have completed the mandatory settings.
7. Optional: Select Personal Information to specify First Name, Last Name, and Email.
   This information is not accessible to an access policy.
8. Optional: Select User Groups to specify Group Memberships for the user.
   A group membership is a text string.
   A Local Database action can read groups from the database to determine branching strategy in an access policy.
9. Click OK.

1. On the Main tab, select Access > Authentication > Local User DB > Users .
   The Users screen displays.
2. Select a user and click Edit.
   The Edit Local User screen opens and displays User Information settings.
3. Select the Force Password Change check box.
   You can select this check box at any time to force the user to change a password at their next log in.
4. Click OK.
   The screen closes.

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

1. A local database action (LocalDB - Read) reads the locked_out database property and determines whether the user is locked out.
2. Exiting the LocalDB - Read action on the User Locked Out branch leads to a logging action and a Failure terminal.
3. 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.
4. 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.
5. 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.

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

1. On the Main tab, click Access > Profiles / Policies .
   The Access Profiles (Per-Session Policies) screen opens.
2. In the Per-Session Policy column, click the Edit link for the access profile you want to configure.
   The visual policy editor opens the access policy in a separate screen.
3. On a policy branch, click the (+) icon to add an item to the policy.
   Repeat this action from the visual policy editor whenever you want to add an item to the policy.
   A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
4. On the selection screen, type logon in the search field, select Logon Page from the results, and select Add Item.
   A logon page should precede other actions in the access policy.

   Note: A locked out user is not presented with a logon page, regardless of how many authentication attempts are allowed.
5. Make any changes that you require to the logon page properties and click Save.
   The properties screen closes and the policy displays.
6. On the fallback branch after the previous action, click the (+) icon to add an item to the policy.
   A popup screen opens.
7. Add a Local Database action and configure it to read the user's locked out status, and create a branch for a locked out user.
   1. Type local in the search field.
      Search is not case-sensitive.
      A list of matching actions displays.
   2. Select Local Database and click Add Item.
      A properties screen opens.
   3. From the LocalDB Instance list, select a local user database.
   4. In the User Name field, retain the default session variable or type another variable name or a user name.
   5. Click Add new entry
      A new line is added to the list of entries with the Action set to Read and other default settings.
   6. In the Destination column Session Variable field, type session.localdb.locked_out (or type the name of another variable).
   7. In the Source column from the DB Property list, select locked_out.
      The entry is complete. A read action reads a value from the database into a session variable.
   8. Click the Branch Rules tab.
   9. Click Add Branch Rule.
      A new entry with Name and Expression settings displays.
   10. In the Name field, replace the default name by typing a new name.
       The name appears on the branch in the policy.
   11. Click the change link next to the Expression setting.
       A popup screen opens.
   12. Click the Add Expression button.
       Settings are displayed.
   13. From the Agent Sel. list select LocalDB.
       The Condition list displays LocalDB Auth Passed. The LocalDB Auth Passed list displays Passed.
   14. From the LocalDB Auth Passed list, select Locked User Out.
       The branch rule is complete.
   15. Click Finished.
       The popup screen closes.
   16. Click Save.
       The properties screen closes and the policy displays.
8. On the fallback branch after the previous action , add a LocalDB Auth action and configure properties for it.
   Valid values for the properties, LocalDB Instance and Max Logon Attempts Allowed, are available from lists.

   Note: A user that accumulates the maximum number of logon failures specified in the LocalDB Auth action is locked out of the local user database instance and exits the action on a Locked User Out branch. A user that is not found in the local user database exits the action to the fallback branch.
9. On the fallback branch after the previous action, click the (+) icon to add an item to the policy.
   A popup screen opens.
10. Add a Local Database action to to increment and write login failures. Configure it to allow user creation.
    1. Set the LocalDB Instance and User Name fields to the same values you selected previously.
    2. From the Allow User Creation list, select Yes.
       At each subsequent login attempt, login failures increase until the user is eventually locked out.
    3. Add a new entry and configure it to read the login_failures DB property into a session variable.
    4. Add a new entry and configure it to write the value of an expression that increments the number of failures into the login_failures DB property.

       Here is an example of the expression:

       expr { [mcget {session.localdb.login_failures}] + 1 }.
11. On the successful branch after the Local DB Auth action, add a Local Database action and configure it to reset login failures to 0 (zero).
    1. Set the LocalDB Instance and User Name fields to the same values you selected previously.
    2. Add a new entry and configure it to write the value of an expression that evaluates to zero into the login_failures DB property.

       Here is an example of the expression:

       expr { "0" }.
12. Click Save.
    The properties screen closes and the policy displays.
13. Click the Apply Access Policy link to apply and activate the changes to the policy.

Sample access policy (with logging action on the User Locked Out branch)

1. On the Main tab, select Access > Authentication > Local User DB > Users .
   The Users screen displays.
2. Select a user for whom the Locked Out column specifies yes.
3. Click Unlock User.

1. On the Main tab, click Access > Profiles / Policies .
   The Access Profiles (Per-Session Policies) screen opens.
2. In the Per-Session Policy column, click the Edit link for the access profile you want to configure.
   The visual policy editor opens the access policy in a separate screen.
3. On a policy branch, click the (+) icon to add an item to the policy.
   Repeat this action from the visual policy editor whenever you want to add an item to the policy.
   A popup screen displays actions on tabs, such as General Purpose and Authentication, and provides a search field.
4. Type local in the search field.
   Search is not case-sensitive.
   A list of matching actions is displayed.
5. Select Local Database and click Add Item.
   A properties screen displays.
6. From the LocalDB Instance list, select a local user database.
7. In the User Name field, retain the default session variable or type another variable name or a user name.
8. From the Allow User Creation list, retain the default value (No).
9. Click Add new entry.
   A new line is added to the list of entries.
10. Configure the entry to read the groups from the database and store them in a variable:
    1. From the Action list, select Read.
    2. In the Source column from the DB Property list, select groups.
    3. In the Destination column Session Variable field, retain the default value, session.localdb.groups or type the name of a variable.
    4. In the Source column from the DB Property list, select groups.
       You have configured an action that reads the user's groups into a variable.
11. Click the Branch Rules tab to edit a branch rule.
12. Click the Add Branch Rule button.
    New Name and Expression settings display.
13. In the Name field, replace the default name by typing a new name over it.
    The default name is Branch Rule n where n is a number. The name appears on the branch in the policy and so should be descriptive.
14. Click the change link in the Expression area.
    A popup screen opens.
15. Click the Advanced tab.
    Use this tab to enter Tcl expressions.
    A text input field displays.
16. Type an expression into the text input field.
    If you expect groups to include only one entry, you can type an expression similar to this one.

    expr { [mcget {session.localdb.groups}] eq "eng" }

    If you expect groups to include multiple entries, you can type an expression similar to this one

    expr { [mcget {session.localdb.groups}] contains "sales" }

17. Click Finished.
    The popup screen closes.
18. Add more branch rules to provide branches for different user groups.
19. Click Save.
    The properties screen closes and the policy displays.
20. Optional: Add any other branches and actions that you need to complete the policy.

Sample access policy that uses local user DB groups in a branching strategy

1. On the Main tab, click Access > Profiles / Policies .
   The Access Profiles (Per-Session Policies) screen opens.
2. Click the name of the access profile that you want to edit.
   The properties screen opens.
3. On the menu bar, click Logs.
   The access profile log settings display.
4. Move log settings between the Available and Selected lists.
   You can assign up to three log settings that enable access system logging to an access profile. You can assign additional log settings to an access profile provided that they enable logging for URl request logging only.

   Note: Logging is disabled when the Selected list is empty.
5. Click Update.