Realm based host checker restrictions

[-red-_]

For the life of me, I cant seem to figure this out.  I am trying to create a sign-in policy consisting of 2 realms. The first realm will be slated for Windows machines, and enforce presence of AV and Firewall components. The second realm is intended as a fallback for everyone else, so if they dont have AV/Firewall software installed or a non-windows platform.. etc, I want them to end up at this realm.

Where I am running into a problem is essentially, users with AV/Firewall software still inadvertanly get an option for the fallback realm. Without any restrictions in place, they technically get both. I need to figure out a way to negate the AV/Firewall HC policy at the realm level. 

I can use custom expressions to achieve this at the role level, but I'm at a loss as to how to do this if I intend to do realm level enforcement.  I tried creating another HC policy consisting of All supported AV and firewall products, then under custom rules I attempted to find syntax that would essentially allow only if AV/Firewall checks failed. So far I'm not having much luck. Curious of someone is doing something along these lines, and if so, how. 

[filbert_]

Sounds like you are the right track with your last paragraph. I've used "NOT" in the custom policies several times.

Make a copy of your AV/FW Hostchecker policy then change it to a custom rule and put in;

NOT "Rulename1" OR NOT "rulename2"

Any Windows device that doesn't have the required AV and FW running should match this policy.

You're also going to need to add some dummy rules in that HC policy for the other OS. For example, add a version check for ios devices.

[-red-_]

Thanks for chiming in.

Took a bit, but finally realized that my problem wasnt the policy, but rather the test machine I was using. I completely overlooked the fact that it had 2 AV products loaded (and apparently active.)  So, the rule as written  was actually correct. 

Now I have to figure our why there is almost a 1 minute delay between the time the user enters the credentials and when the role mapping actually takes place. Policy trace shows the gap, but nothing in terms of an explanation as to why.