Last Modified: Nov 06, 2024
Affected Product(s):
BIG-IP Install/Upgrade
Known Affected Versions:
13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 17.0.0, 17.0.0.1, 17.0.0.2, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4
Opened: May 07, 2018 Severity: 2-Critical
When upgrading to version 13.1.0.x or later, users who previously had permissions to make calls to iControl REST lose the ability to make those calls.
A previously privileged user can no longer query iControl REST. In addition, some remotely authenticated users may lose access to the Network Map and Analytics view after the upgrade.
You will notice this issue when you use iControl REST and are upgrading to version 13.1.0.x or later. You can also detect if the user is impacted by this issue with the following steps 1. Run below API to for impacted user account XYZ. # curl -ik -u username:XYZ -XPOST https://localhost/mgmt/shared/authn/login --data-binary '{"username":"XYZ", "password":"XYZpass", "loginProviderName":"tmos"}' -H "Content-Type: application/json" 2. Find user XYZ's 'link' path under 'token' in previous output There are two formats possible for 'link' a. Path will have a UUID For example "token"->"link"->"https://localhost/mgmt/cm/system/authn/providers/tmos/1f44a60e-11a7-3c51-a49f-82983026b41b/users/<UUID>" b. Path will have a username (not UUID) For example "token"->"link"->"https://localhost/mgmt/shared/authz/users/<username>" 3. Run below API to get list of user roles. # restcurl -u "admin:<admin-user-pass>" /shared/authz/roles | tee /var/tmp/rest_shared_authz_roles.json 4. Check user XYZ's link path from step 2 in above output. Check under the "userReferences" section for group "iControl_REST_API_User" . You will see the link path in one of the two formats listed in 2a/2b. If you do not see the user link path then you are impacted by this bug
You can repair the current users permissions with the following process: 1) Delete the state maintained by IControlRoleMigrationWorker and let it rerun by restarting restjavad process: # restcurl -X DELETE "shared/storage?key=shared/authz/icontrol-role-migrator" 2) Restart services # bigstart restart restjavad *or* tmsh restart /sys service restjavad 3) Now, the permissions should start in a healthy state. Re-try making an iControl REST call with an affected user. 4) If this still does not resolve the issue you could update shared/authz/roles/iControl_REST_API_User userReference list to add all affected users' accounts using PUT. Here you may need to use the UUID path as described under 'Conditions' # restcurl shared/authz/roles/iControl_REST_API_User > role.json # vim role.json a. add { "link": "https://localhost/mgmt/shared/authz/users/[your-user-name]" } object to userReferences list OR b. add { "link": "https://localhost/mgmt/cm/system/authn/providers/tmos/1f44a60e-11a7-3c51-a49f-82983026b41b/users/<UUID>" } object to userReferences list # curl -u admin:admin -X PUT -d@role.json http://localhost/mgmt/shared/authz/roles/iControl_REST_API_User
None