10-18-2023 06:35 AM - edited 10-18-2023 08:31 AM
Hi, all.
We are having a little trouble using the correct operand in an authorization condition, here is what we are trying to accomplish:
In our 802.1x environment, ISE is profiling all devices, including the printers.
Up untill now, all printers (different vendors) are authenticated using MAB (because the "old"printers are not able to carry a certificate), identified by profiling and if correctly identified, authorised into the printer vlan.
Now it has been decided to get rid all the old printers and replace them with new models (by Xerox) that are capable of carrying and using (internal) certificates to authenticate with EAP-TLS and NOT use MAB !!! Great idea !!
However, this creates the small problem of "onboarding" the printers, since they neither have an internal certificate, nor 802.1x enabled when they arrive. To do that, they need to be given temporary access to the network so that the new printers can be discovered (SNMP) by the Xerox Management server and have the certificate put onto them ....
We try to build that "onboarding process" by using the profiling feature of ISE, in the following way:
When the new (and unknown to ISE) device gets plugged into network, the first thing ISE learn about it is the MacAddress.
The MacAddress then gets assigned to the EndPoint Policy:
Xerox-Device
At this point we try to give the device RESTRICTED Access using MAB for Authentication and a specific DACL which only allows common network services (like DHCP, DNS, SNMP, etc.) and access from and to the ISE deployment (for NMAP scanning, etc.).
To achieve this we try to use the EndpointPolicy attribute in the Endpoints dictionary:
When this restricted (Phase1) access is given to the device, it will be NMAP scanned by ISE after it has requested a DHCP IP address, ISE will also evaluate parameters from that request.
After all these parameters have been evaluated, the device has been reprofiled with more detail now, it is no longer just a "Xerox-Device", it has been recognized as a Xerox-Printer or even a Xerox-Altalink-Printer:
Like this:
or this:
As you can see in the pictures, the Xerox Endpoint Policies are nested, meaning a device profiled as Xerox-Printer or Xerox-Altalink-Printer also has the Xerox-Device in that complete policy name ....
We tried to make good use of that, by inserting another "onboarding" phase 2 into the process, like this:
Phase 1:
- Device profiled as Xerox-Device (via Mac)
- gets authenticated via MAB (using the EndPoint:EndPointPolicy EQUALS Xerox-Device attribute in a condition)
- restricted access to network services and ISE only
- Device request DHCP, is nmap scanned
- very short Reauth-Timer (minutes only)
Phase 2:
- Device is re-profiled as Xerox-Printer / Xerox-Altalink-Printer
- gets re-authenticated via MAB (using the EndPoint:EndPointPolicy EQUALS Xerox-Device:Xerox-Printer attribute in a condition)
- restricted access to network services, ISE and Xerox Management Server
- 2 hours Reauth-Timer (time to discover and configure the device)
- Device gets discovered by Xerox Management Server, gets internal certicate, gets configured for .1x/EAP-TLS
Both of the stages are referenced in one authorization rule:
And here is the problem:
No printer device will ever reach the Stage 2-Rule, because the condition of phase 1 (EndPoint:EndPointPolicy EQUALS Xerox-Device) always catches, no matter if the device has already been profiled more detailed !!!!!
Why might that be ?? I thought, that the operand EQUALS only hits, when EXACTLY the same EndPointPolicy String is present ... ???
Here it seems that EQUALS also means CONTAINS ....
Which operand is correct here ???
ISE 3.1, Patch 7 btw.
Rgs
Frank
10-18-2023 07:15 PM
Nope - both Phase 1 and Phase 2 contain Xerox-Device - so you have to use Boolean Logic instead:
Put the more specific Profile Rule ABOVE the less specific Rule. That will make sure that Phase 2 devices get matched first if exists, and if not yet Phase 2, the next rule is evaluated and will always match if at least Xerox-Device is the current endpoint profile
ciao
Arne
11-02-2023 05:19 AM
I get the "more/less specific thing, but we used EQUALS in the rules, not CONTAINS:
EndPoint:EndPointPolicy EQUALS Xerox-Device
in Phase 1 rule and
EndPoint:EndPointPolicy EQUALS Xerox-Device:Xerox-Printer
in Phase 2 rule .....
That should be matched EXACTLY, shouldn't it ???
Rgs
Frank
11-02-2023 05:16 PM
You're right @Frank Lothar Weber - the EQUALS is an absolute (literal) match. If you have an endpoint that definitely has "Xerox-Device:Xerox-Printer" then I would also expect the first Rule to be FALSE, and advance to the next rule, which would be a TRUE.
The only mystery now is to see how you defined those Conditions - can you screenshot those for us? I don't like using compound conditions unless it's a condition I re-use elsewhere. If the condition is unique, then IMHO, all it's doing is making the ISE Policy more unreadable, because you have to go hunting to find the details. Yes, the name says it all, but that is just syntactic sugar - it's not helpful in understanding and proving the correctness of the condition.
11-03-2023 08:21 AM - edited 11-03-2023 08:23 AM
Well, the conditions are like this:
Stage 1:
Stage 2:
11-06-2023 03:15 PM
> Put the more specific Profile Rule ABOVE the less specific Rule.
Did you try this like @Arne Bier suggested? Try the specific match first (I know you are using EQUALS but try it - it cannot hurt at this point). Sounds like a bug for TAC.
11-07-2023 01:44 AM
Yes, I did that, no difference ....
11-02-2023 08:07 AM
Have you tried using the "In" operand rather that EQUALS/CONTAINS?
hth
Andy
11-07-2023 01:45 AM
Did that, too ....
11-03-2023 03:45 PM
I reproduced this in the lab (ISE 3.2 patch 4) and you are right. It always matches the Xerox-Device - LiveLog Details tells you what it matched on, contradicting its own Policy Set programming.
But the Policy Set is told to check the EndPointPolicy - which is Xerox-Printer.
Even in the Context Visibility, the EndPointPolicy is clearly shown as Xerox-Printer, and not Xerox-Device.
11-04-2023 07:09 AM - edited 11-04-2023 07:11 AM
Ok, thanks, that spares me upgrading my ISE3.1P7 to 3.2 next week and check if it might be working there .....
Can this be a bug ?? Somebody must have encountered that before ....
If not a bug, what are we doing wrong ... ???
Rgs
Frank
11-04-2023 03:01 PM
I think it's a bug. I can't find any other Dictionary to use in the Rule to match against Xerox-Printer. The only other one would be Logical-Profile, which is not what we want or need.
I ran an Endpoint Debug. I could not see anything there. Then followed the advice from this great resource to enable DEBUG for Rule Processing. It makes some nice logs but I have to guess my way around - this is a case for TAC/Dev to explain to us. From the below, I think the flawed decision is made during this comparison.
The LHS (Left Hand Side) is the Xerox-Device:Xerox-Printer
The RHS (Right Hand Side) is Xerox-Printer.
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Evaluating Condition with id - 90083b15-a44d-498f-afc2-036e50228389 - LHS operandId - 6d8c6e60-8bff-11e6-996c-525400b48521.6d954800-8bff-11e6-996c-525400b48521, operator EQ, RHS operandId - 44031480-8c00-11e6-996c-525400b48521
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- LHS VALUE is being evaluated to :: [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521]
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.ConditionUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Condition lhsoperand Value - [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521] , rhsoperand Value - 44031480-8c00-11e6-996c-525400b48521
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Evaluation result for Condition - 90083b15-a44d-498f-afc2-036e50228389 returned - true
Detailed debug below. I would raise a TAC case
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- evaluate policies by RANK order.
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.PolicyUtil -::::- 36545b50-959c-43e9-b840-4b954d38fbca :: be92357a-2076-4e6d-a780-807eebe89604authorization
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.PolicyUtil -::::- [1c8c3acb-a3ed-4c66-aca7-226fd4eb8c01, d706aac3-8b48-4f16-a04d-a03c5b5ce01d, ed9f3483-200d-4201-9ace-9c077906be86, cf61e74f-41d3-44f1-9f95-049460b743b3, d4a79a53-efa2-4ae1-b0bf-7f71afe25df1] :: 5
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.PolicyUtil -::::- 0
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- policies size in FirstApplicable - 5
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ________________ policy 1c8c3acb-a3ed-4c66-aca7-226fd4eb8c01 from cache in FirstApplicable - com.cisco.cpm.policy.cache.proxy.PolicyProxy@5cc23b87
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ________________ policy d706aac3-8b48-4f16-a04d-a03c5b5ce01d from cache in FirstApplicable - com.cisco.cpm.policy.cache.proxy.PolicyProxy@1b2e3b0b
2023-11-05 07:33:38,582 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ________________ policy ed9f3483-200d-4201-9ace-9c077906be86 from cache in FirstApplicable - com.cisco.cpm.policy.cache.proxy.PolicyProxy@1c4de482
2023-11-05 07:33:38,583 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ________________ policy cf61e74f-41d3-44f1-9f95-049460b743b3 from cache in FirstApplicable - com.cisco.cpm.policy.cache.proxy.PolicyProxy@491d69c5
2023-11-05 07:33:38,583 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ________________ policy d4a79a53-efa2-4ae1-b0bf-7f71afe25df1 from cache in FirstApplicable - com.cisco.cpm.policy.cache.proxy.PolicyProxy@4ce6d62
2023-11-05 07:33:38,583 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ___________ policysets after sort in FirstApplicable - []
2023-11-05 07:33:38,583 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- sorted size in FirstApplicable - 5
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Evaluating rule - <Rule Id="e6275e43-fd1f-42e9-b5a4-8467496a9c5a">
<Condition Lhs-operand="6d8c6e60-8bff-11e6-996c-525400b48521.6d954800-8bff-11e6-996c-525400b48521" Operator="EQ" Rhs-operand="44031480-8c00-11e6-996c-525400b48521"/>
</Rule>
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,586 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Getting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Evaluating Condition with id - 90083b15-a44d-498f-afc2-036e50228389 - LHS operandId - 6d8c6e60-8bff-11e6-996c-525400b48521.6d954800-8bff-11e6-996c-525400b48521, operator EQ, RHS operandId - 44031480-8c00-11e6-996c-525400b48521
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- LHS VALUE is being evaluated to :: [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521]
2023-11-05 07:33:38,590 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.ConditionUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Condition lhsoperand Value - [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521] , rhsoperand Value - 44031480-8c00-11e6-996c-525400b48521
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Evaluation result for Condition - 90083b15-a44d-498f-afc2-036e50228389 returned - true
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Setting Result for Condition: 90083b15-a44d-498f-afc2-036e50228389 : true
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Rule evaluation complete rule - e6275e43-fd1f-42e9-b5a4-8467496a9c5a , result - true
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: result after rule d649246f-5e43-4bec-9354-7548e76a05f8 evaluation true
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- BYOD Registered flag found from EP as false
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- Dictionary Attribute = EndPoints.EndPointPolicy
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- obj value provided from env map is :: 0
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- val value provided from obj map is either null or not equal to 1 and returns false
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.impl.ExecutionContext -::::- License Bit flag set to 1027
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- Clearing all the unknown valued dictionary attributes
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- key is EndPoints.EndPointPolicy value is [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521]
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- transformer map has 1 of elements
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- time taken for audit log transformation is 0 ms
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.RuleUtil -::::- transformed value is [bb81b0a0-4fbf-11ed-a871-0050568f5811, 44031480-8c00-11e6-996c-525400b48521]
2023-11-05 07:33:38,591 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: PolicyGuid: cf61e74f-41d3-44f1-9f95-049460b743b3 - ResumeContextMap : {90083b15-a44d-498f-afc2-036e50228389=true}
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: 88777a74-0059-4755-a9b1-1bb67f781dab evaluated to PERMIT(1)
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- policyGUID in context is :: null
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] policy.eval.alg.pc.FirstApplicablePCAlgorithm -::::- lastmatched policy guid is :: cf61e74f-41d3-44f1-9f95-049460b743b3
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.utils.PolicyUtil -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: Combining results from policySet - be92357a-2076-4e6d-a780-807eebe89604authorization Combining Algorithm - FIRST_RANK_MATCH(3)
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.async.cache.RequestsCache -::::- Deleting ExecutionContext from RequestsCache for sessionID: ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.impl.ExecutionContext -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE: ExecutionContext added to response queue
2023-11-05 07:33:38,592 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.impl.Engine -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE : ** License Info ** : 1027
2023-11-05 07:33:38,597 DEBUG [PolicyEngineEvaluationThread-15][[]] cpm.policy.eval.impl.Engine -::::- ac1683ae4rITUowIFLJKFFrkzZdToqXQ/7wDPZFNME31Uco_GQE : Response after PE 2.0 processing
<Response>
<Results>
<Result Decision="PERMIT">
11-05-2023 05:48 AM
Hi, Arne.
I have already tested the rules using LogicalProfiles for Stage1 and Stage2 before, same result, doesn't work either ......
Will talk to the customer about opening a TAC case .... Stay tuned
Rgs
Frank
11-05-2023 12:45 PM
Good luck @Frank Lothar Weber ! Perhaps the Profile concept is slightly different to comparing, say, a literal string (like a "username A" EQUALS "username B") - I am assuming that ISE is performing a logical short-cut and inferring that since Xerox-Printer is derived from Xerox-Device, that therefore the endpoint equals Xerox-Device (even though its Profile is more specific - but who cares - its ancestor is Xerox-Device, so it's part of that Family). In this case, perhaps the EQUALS is performing a group membership operation, and not a literal comparison.
11-06-2023 12:50 AM
Hmmm ..... what might happen when the parent of "Xerox-Printer" is set to "none", the ancestor/family relations are removed ???
Rgs
Frank
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide