Agreed. In this approach, HC not running is the same, functionally, as not passing the HC policy since both will result in the user getting limited access. This can be confusing to the user - they don't know if its a compliance issue or a software issue.
There are a couple of way to deal with this. One approach is to create three roles - full access for compliant user, partial access for non-compliant users, and informational for HC not running users. Create a HC policy that detects any running process to differentiate between the non-compliant users and those that can't run HC due to software issues. Add a role mapping rule to match the 'any process' HC rule and map to the limited access role and have the default role mapping rule map to the informational role.
You further can enhance this by enabling the HC remediation notices to inform the user that fails compliance why they failed compliance. To do this requires a slightly different configuration.
- the first role mapping rule should match the 'any process' HC policy and map to the full access role with no Stop.
- the second role mapping rule should match the 'any process' HC policy but not the compliance HC policies and map to the partial access role.
- the third role mapping rule should not match (!=) the 'any process' HC policy and map to the informational role.
In addition, the compliance HC policies should be made a requirement on the full access role at the role level.
Using this approach
- compliant users map to the full access role only
- non-compliant user map to the full access role and the partial access role; but because the full access role requires the compliance HC policies, they will get the remediation notice and only the partial access role will be applied.
- those that can't run HC get the informational role only.
