Applicable to both Navigator/Navxwsm and Manage/Secure with minor screen differences
Not able to login due to missing search rights
When trying to login, the end user receives the error User is not authorized with descriptions of "show_searches" and "include_shared_searches" are required.
As an example, chris_smith tried to login and saw these errors
The most common cause is that the user is not associated with any groups. Since these are the first rights that are checked when logging in, they are reported immediately.
Since this is a security related error, it is going to involve a security administrator to validate the configuration. This requires access to the web security manager to review.
Note: if you have recently made any changes in security manager, be sure to have issued a refresh security command before troubleshooting.
Have user attempt to Login
The first step is to have the user login so you can review their status. Some information may be removed over time so best to do it immediately after they try to login.
Determining if the user is defined
In Security Manager, navigate to User Management and search for the user in question. You should see something like the following
This indicates that Chris Smith has logged on to meshIQ platform and shows the time which if they just logged in should be current. If they are not present, you will need to ensure that you have the proper databases configured and security settings.
It indicates that they are a auto generated user. All current customers of the meshIQ platform use auto generated users integrated with other security systems like LDAP.
Select the user and choose Edit or Preview (if available). Then select the groups that are assigned.
In this example, there are no assigned user groups for them. This is what was implied from the error they received so now we need to determine why.
Obtain their LDAP group(s)
The first thing to confirm is what groups is the user intended to be in. They may know this or you may need to obtain from your security team. In many companies, the LDAP accounts are a long string of characters with various encoded meanings such as PRD_APP01_TESTER_0103 or APP01_PROD-ANALYST-TECH and so on
For our example, we find that they are in the PRD_APP01_TESTER_0103 group.
Verify that LDAP Group Exists
Only groups defined to the security manager are assigned to the user and User Group Management will show what groups are available.
In the example above, we searched all of the groups for APP and can see that there are 2 groups. However, while not completely obvious, there is a typo in PRD_APP01_TESTER_0103 which was entered as PRD_APP01_TESTER-0103. This would be sufficient to cause the login error since this does not match the expected LDAP group. We can edit this group and correct the name to resolve the problem but for purposes of example, we will review a few more settings first.
Verifying Roles assigned
The next step would be to confirm that the correct rights have been assigned. You do this by selecting Edit or Preview (if available). From there, navigate to the Roles to view the associated roles.
In this case, Message Browser is assigned which can be checked in Role Management. From there we can confirm that it has the required search rights.
Verifying groups in Domain Server
The final check is to ensure that these groups exist in the Domain Server. The domain server is the initial filter for LDAP groups. If not defined in Domain, then the groups will not be passed through. These can be checked directly from User Group Management by selecting Compare option. Once on this screen, selecting only different will show any inconsistencies.
Here we can see the condition as noted above, the PRD_APP01_TESTER_0103 group is correctly defined in the Domain (using Auto generation) but there is no corresponding group in security manager so we confirm that the correct fix is to edit the name to match. If on the other hand, the Domain had the wrong name defined or was missing the group completely, those changes could be made as well.
Verification
Once we have corrected the group and have them login to confirm that this corrected the issue. They no longer see the error and checking the various places it is now as expected.
The group is listed when viewing the user's groups.
And no inconsistencies are found between security manager and domain
Note: We can ignore that *Agents is missing, this legacy group is not required in Domain Server.