Article #: 9423
There is a scenario where BACKTRACK may prevent a user from successfully starting the program after login. The user gets a “No authorization for selected operation” error message after entering their user ID along with the correct password. When they press “OK” BACKTRACK closes. In essence, BACKTRACK completely shuts out the user from the application.
- The “Require User ID/Password to be entered when the program is started” feature is enabled (i.e. user must log into BACKTRACK when it is first started)
- User attempting to login belongs to a Security Group that does NOT have access to the default application at login. Note: you can see the default application at the top of the error message (see image below).
When BACKTRACK closes from a session, it remembers the current application selected by the user. BACKTRACK sets that application as the default application for use in the next session. The next time BACKTRACK is opened, it will attempt to access that default application.
The “No authorization for selected operation” error message, in this case, tells the user they do not have access to the application that BACKTRACK is attempting to launch. This can be confusing to the user since they may not be aware that BACKTRACK is trying to open an application where they lack access permissions, rather than an issue with the BACKTRACK application itself.
The user must belong to a Security Group that allows permissions for the user to access the default application. Otherwise BACKTRACK will not open for that user on that workstation.
Three recommended approaches to fix:
- Change the default application on that workstation
- Change the user’s Security Group to one what allows access to the default application
- Give the user’s Security Group access to the default application
Approach #1 – Change the default application
This can be done by logging into the workstation with a user who belongs to a security group. That user also has the correct access to the default application on that PC. After a successful login, the user then changes the application in BACKTRACK to one where the settings allow the original user access. Then, the second user closes BACKTRACK. This resets the default application back to one where the original user can access it. As a result, BACKTRACK will not stop the original user when they try to login next time.
Approach #2 – Change the user’s Security Group to one that allows access to the default application
You might use this approach if someone assigned the user to the wrong Security Group by accident. This requires a user who is able to open BACKTRACK on this or another PC and who can who change a user’s Security Group, The second user opens the original user’s record in BACKTRACK and changes the assigned Security Group to one with the required application permissions.
Approach #3 – Give user’s Security Group access to the default application
This approach makes the most sense if someone removed the Security Group access to the application by mistake. This method requires a user who is able to open BACKTRACK on this or another PC and who can change security settings for a user group. This second user will open the Security Group settings window and allow access to that application to all users in that security group. This is likely the least popular of the available options. One would assume that the lack of access for that security group was intentional. This will grant all users in that security group access to that application.
Issue Found: BACKTRACK v2015
If, somehow, the no users belong to a user group that can access the default application on any computers, then none of the options above will work. Each option requires that someone else must access BACKTRACK to make a change to either the default application, the user security group, or the permissions of the user’s security group.
In the case where a Security Group exists with access to the application (and no one can access BACKTRACK), the SQL administrator may be able to change user’s security group directly in the database. Contact EBI support for help with this. Directly changing the database can trigger catastrophic consequences to the BACKTRACK system if not done correctly.
In the case where no Security Group exists with access to the application and no one can access BACKTRACK, the SQL administrator may be able to change the permissions of the Security Group for the application directly in the database. Contact EBI support for help with this. Directly changing the database can trigger catastrophic consequences to the BACKTRACK system if not done correctly.
If you need further assistance, please contact us.