M100875: Users do not have expected rights to access Deployment Manager

Symptoms

Access to many areas of the ManageSoft Deployment Manager reports and console are protected by access rights that are configured within Deployment Manager. When a user attempts to access a part of the system to which they do not have access, the following symptoms may be observed:

• When viewing a web-based report, the following error message is shown:

  Access Denied

  The user domain\username is not permitted to view report ReportName

• No devices appear under the Discovery and Adoption node in the administration console and options available under that node are disabled.
• When viewing information under the Policy node in the administration console, options to manipulate policies are disabled and the display area in the right hand side of the console reports the following:

  The current user does not have permission to modify policies.

• When invoking the Assign Rights wizard, the following error is reported:

  The current user does not have the required access to assign rights. No permission has been assigned to allow the current user access to this resource.

Cause

There are a range of possible root causes for access rights not being configured as expected. Some common scenarios are:

• Default rights for the MGS Report Users and MGS Administrators security groups may not be configured in a new installation of Deployment Manager if the CN of the installing user is different from their SAM account name (login name). For example, if the installing user account's in AD has a CN of "John Smith" but a SAM account name of "jsmith", default rights will not be configured. This situation will typically cause the Right table in theManageSoft database to be empty after installation. The Right table stores information about configured access rights; an empty table indicates that no access rights have been configured.
• Correct operation and checking of access rights based on AD security group memberships relies on successful operation of the policy merging process. If the policy merge process is failing or has not been executed since changes were made in Active Directory, rights based on updated group memberships will not be recognized.

Troubleshooting and Resolution

The following steps are suggested for troubleshooting and resolving access rights problems resulting in the symptoms described above:

1. Reconfigure default access rights

   The SQL scripts attached below can be executed using SQL Server 2005 Management Studio orSQL Server 2000 Query Analyzer to reconfigure default access rights. This will be necessary for installations affected by the user CN/SAM account name issue described above. KB100875.sql will fix the deployment manager report rights, and spmReports.sql will fix the security manager report rights.

   If the script is to be used with a Deployment Manager installation that has been configured with customized names for the MGS Administrators or MGS Report Users security groups, the group names specified in the script should be modified appropriately.

   Running this script will often be sufficient to resolve access rights problems without needing to proceed with any of the following steps.

2. Review AD group memberships

   Ensure that the user is a member of the relevant AD security groups that should grant them the expected level of access to Deployment Manager. Typically users should be a member of the MGS Administrators or MGS Report Users security group.

3. Ensure successful policy merge

   After making any change to AD that may affect group memberships, the policy merge process must be successfully executed in order for Deployment Manager to identify and recognize those changes. This process is typically executed daily at 12am by the Merge ManageSoft policiesscheduled task; check that the Microsoft Task Scheduler shows that this task has run recently with a value of 0x0 (meaning "success") shown in the Last Result column.

   The policy merge process can be executed manually to generate a diagnostic log using a command line such as the following:

   "C:\Program Files\ManageSoft\Reporter\polmerge.exe" -RaV5 >polmerge.log

   Once completed, the final line in the polmerge.log file will indicate whether the process succeeded or failed. If the process failed, this log will be enable ManageSoft Support to assist with further diagnosis and problem resolution.

4. Review recognized group memberships

   The following SQL query can be executed against the ManageSoft database to confirm the groups in which the identified user has been recognized as a member (replace "jsmith" with the appropriate user SAM account name in this query):

   SELECT g.GroupCN, g.GroupID, u.UserID, ou.OU
   FROM [User] u
    INNER JOIN Member m
     ON m.TargetTypeID = 2
     AND m.TargetID = u.UserID
     AND m.MemberMode = 1
    INNER JOIN [Group] g
     ON g.GroupID = m.GroupID
     AND g.GroupType IS NOT NULL
    INNER JOIN SDOU ou
     ON ou.OUID = g.GroupOUID
   WHERE u.SAMAccountName = 'jsmith'

   Confirm that this query shows the user as being in all expected groups. If any groups are missing compared to what is configured in AD, this suggests that the policy merge process was unable to pick up all the expected information from AD.

5. Review Deployment Manager access rights configuration

   Granular rights for accessing various parts of the Deployment Manager reports and console can be configured in the Assign Rights wizard available from the Manage access rights... option on the right-click context menu on the root ManageSoft node in the administration console. If you are able to access this wizard, you can use the wizard to review configured access rights to ensure that appropriate rights are granted to groups.

Status

The problem with default rights not getting configured if the CN and SAM account name of the installing user differs has been identified by ManageSoft as a defect affecting Deployment Manager releases up to and including 7.9.