Applies To:
Show Versions![Show Versions](/etc/designs/pcx/techdocs/images/expandversions.gif)
BIG-IQ Centralized Management
- 5.2.0
About Access
The BIG-IQ® system offers you centralized management for BIG-IP ®Access Policy Manager® (APM) and F5 Secure Web Gateway (SWG) configurations. Centralized management gives you easy-to-deploy sets of access policies, and access policy configuration objects. This means you don't need to repeat the configuration on each BIG-IP system individually. Access also offers you centralized reporting, which allows you to compare and monitor BIG-IP APM® usage across many groups of devices.
Access configuration workflow
![Adding devices; Discovering services; Importing LTM; Importing APM while joinining Access group; Editing device-specific resources; Evaluating changes; Deploying Changes](/kb/global/manual_images/MAN-0615-02_v1/GUID-D0B49EAE-D85D-4F33-B417-F3B268BFCDE4-online.png)
What are Access groups?
Each Access group is a group of BIG-IP® devices across which you plan to share the same Access configuration. When you import an APM service configuration from a device, the device must join an Access group.
About the types of resources that Access imports
When you import an APM® service configuration from a device, the device must join an Access group.
- If the device joins a new Access group, Access imports both shared resources and device-specific resources from the device.
- If the device joins an existing Access group, Access imports only the device-specific resources from the device.
About shared resources
In an Access group on the BIG-IQ® system, shared resources are a set of configuration objects that are expected to be the same on every device in an Access group.
How do shared resources work in the configuration?
Initially, shared resources are imported with the APM® service configuration from the device. After import, they are read-only on the BIG-IQ® system. The deployment process configures the shared resources on all devices in the Access group. This can result in major configuration changes on the devices, with resources being overwritten, deleted, or added on them.
About device-specific resources
In an Access group on the BIG-IQ® system, device-specific resources are a set of configuration objects that are expected to exist on every device in the Access group. However, the properties of these resources can differ from device to device.
For example, an access policy could use an Active Directory server for user authentication. Device apm_north_america.xyz.com must use an Active Directory server configured in a North American domain or data center, while device apm_south_america.xyz.com must use an Active Directory server configured in a South American domain or data center.
How do device-specific resources work in the configuration?
When you add a device to an Access group, device-specific resources are created from the device's APM® service configuration. Or, if particular resources do not exist on a device, Access creates device-specific resources that match those in the device configuration. After import, you are instructed to review and change device-specific resources if needed; in addition, you can change them at your option. You can also make a device-specific resource shared, so that its properties can only be configured in the shared resources. At deployment, device-specific resources are configured on the specific devices.
Reporting configuration workflow
BIG-IQ logging nodes are required for Access and SWG reporting. To set up a discovered device so that it sends report data to a logging node, you must run the remote logging configuration. Then, you can run reports.
![Configure Logging nodes; Run Remote Logging configuration on discovered devices with APM service configuration; Run reports](/kb/global/manual_images/MAN-0615-02_v1/GUID-30C29AC2-9348-47DC-A046-FECCCDC7D40E-online.png)
Upgrading BIG-IQ Access version 5.1 to 5.2
After upgrading from BIG-IQ® Centralized Management version 5.1 to version 5.2, send out a POST request to a REST API in order to restore session data after an upgrade. If you do not perform this step, then the sessions that you created before upgrading will not display in either the Sessions report or in the Active Sessions report after the upgrade. You take this action after restoring the elastic snapshot.
Enter this command: restcurl -X POST -u admin:admin http://localhost:8100/mgmt/cm/access/reports/access-es-upgrade-task -d ‘{ }’ .