Environment
Verastream Host Integrator
Situation
Authorization failure errors may occur as described below:
- In Administrative Console (version 7.0 or higher), after entering valid user name and password credentials, you may see the following error:
- In version 6.6 or earlier, if security has been enabled in Administrative WebStation, and you subsequently attempt to log into Administrative WebStation with a valid userid and password, you may see the following error:
- If security has been enabled on your session server (or domain, in version 6.6 or earlier), when the client application makes a connection with valid user name and password arguments, the following error may be returned:
[3041] Authorization failure for security profile User.
- You may see errors similar to those above when using other tools to connect to the session server with credentials, such as:
- Design Tool, when deploying a model
- activatemodel or deactivatemodel commands, to deploy or un-deploy a model package
- Web Builder, when retrieving model metadata
- Standalone Log Viewer utility (version 6.6 or earlier) or logexport command
- Model Variable Management API (com.wrq.vhi.sconfig), when your code makes an open() call
Resolution
To resolve this issue, complete the following steps:
- Verify the local OS group (or LDAP user or group, in version 7.0 or higher) has been added to the appropriate security authorization profile.
Version 7.0 or higher: In Administrative Console, click Perspective > Management > Authorization.
Version 6.6 or earlier: In Administrative WebStation, click Host Integrator Setup > Security > Profiles.
For more information about authorization profiles, see KB 7021567.
- When using groups, verify the user is a member of the group (using tools in your operating system or LDAP directory server).
- If you are using a local OS group, and the Verastream Management Server (version 7.0 or higher) or AADS (version 6.6 or earlier) component is running on Linux or Solaris, do one of the following:
- Run the following command to make the group one of the user's supplementary groups stored in the /etc/group file:
usermod -G <group> <user>
where <group> is a non-primary group (for example, vhiadmins or vhiusers) which was added to the authorization profile in step 1 above. Repeat this step for each user.
- If you wish the group to remain the user's primary group only (stored in /etc/passwd file), the group and user must have the same name. For example, the "vhiadmin" user can be a member of a "vhiadmin" group.