Hi Tom,
It sounds like you're wanting to achieve something similar to us, and is something I tried a couple of months back. In that you you have a common destination to control access to, from both identified users, and from standard networks (without identity being known)? However an Access-Role object and standard network object are not able to be used as sources in the same rule.
I had hoped/expected that as a workaround that we could define an Access-Role to represent the network source locations, by specifying only the network criteria, and leaving users and machines as 'any'. Thus then could include both the network-only Access-Role and identified-users Access-Role objects together in a single rule.
In my experience this didn't work.
The network-only Access Role did not match any of the IP addresses where identity was not known (eg. Linux PCs). Looking at pep/pdp queries I could see the network-only Access-Role was matched only to machines for which user or machine identity was otherwise discovered (by AD-Query or ID Agent).
No idea if this is supposed to work. I did log a support ticket from which it was suggested it should work - but is a discouraged method. It is intended that the network criteria is used as a filter for user or machine identities, but not intended to be used by itself. Though if this is the case I'm not sure why there is both 'Any user' and 'All identified users' (though I appreciate these can be used in combination with machine identities). I didn't have the capacity to troubleshoot further. So ended up just having two rules for each instance where this is required. One where the source is the Access-Role for identified users, and one where the source includes the standard network objects. Annoying to have to duplicate the rules like this, but seems to be the least headache, and is probably more reliable anyway (ie. no dependence on pep/pdp processes).
Not sure if this helps or is relevant to your situation.