Security

hi, What is the difference between these two conditions in terms of evaluating succeeding conditions and enforcement? (rules evaluation is first-applicable)

VS

Assuming this is two separate potential setups and the actions taken match the descriptions given, the first option is going to result in a device that hasn't been profiled being immediately kicked off the network.  And since the device gets kicked off immediately, the device never gets profiled.

What you would normally want is for an unprofiled device to be allowed on, potentially in a restricted way, so that profiling by at least DHCP fingerprint can occur.  Then the profiled device action can fire and force the device to reauthenticate and proper policy to be applied.

Also, don't write policy around [Machine Authenticated] unless you just really like counting on the MAC address to no be spoofed.  If you want computer and user authentication, use TEAP.  If you want to validate the device as an allowed device on the network, use the management platform (Intune/JAMF/etc.) to do so and then take action based on that.  Your role mapping should be looking at the interesting points of who/what/why/where/when/how for the authentication session and then setting roles based on that.  You definitely want something more interesting than just "authentication was good".  Testing [User Authenticated] is redundant, if [User Authenticated] isn't present then you'd never get to the authorization state in the first place.

hi, What is the difference between these two conditions in terms of evaluating succeeding conditions and enforcement? (rules evaluation is first-applicable)

VS

Hi Sir, 

Can I copy the policy you used over [Machine Authenticated]? and an example for replacing [User Authenticated]?

Thanks

Assuming this is two separate potential setups and the actions taken match the descriptions given, the first option is going to result in a device that hasn't been profiled being immediately kicked off the network.  And since the device gets kicked off immediately, the device never gets profiled.

What you would normally want is for an unprofiled device to be allowed on, potentially in a restricted way, so that profiling by at least DHCP fingerprint can occur.  Then the profiled device action can fire and force the device to reauthenticate and proper policy to be applied.

Also, don't write policy around [Machine Authenticated] unless you just really like counting on the MAC address to no be spoofed.  If you want computer and user authentication, use TEAP.  If you want to validate the device as an allowed device on the network, use the management platform (Intune/JAMF/etc.) to do so and then take action based on that.  Your role mapping should be looking at the interesting points of who/what/why/where/when/how for the authentication session and then setting roles based on that.  You definitely want something more interesting than just "authentication was good".  Testing [User Authenticated] is redundant, if [User Authenticated] isn't present then you'd never get to the authorization state in the first place.

hi, What is the difference between these two conditions in terms of evaluating succeeding conditions and enforcement? (rules evaluation is first-applicable)

VS

I have little idea what you are trying to accomplish with this setup, nor do I have a setup that would be applicable to whatever you are trying to do.

If you provide some clarity around what is bein attempted, might be able to provide some guidance.

Hi Sir, 

Can I copy the policy you used over [Machine Authenticated]? and an example for replacing [User Authenticated]?

Thanks

Assuming this is two separate potential setups and the actions taken match the descriptions given, the first option is going to result in a device that hasn't been profiled being immediately kicked off the network.  And since the device gets kicked off immediately, the device never gets profiled.

What you would normally want is for an unprofiled device to be allowed on, potentially in a restricted way, so that profiling by at least DHCP fingerprint can occur.  Then the profiled device action can fire and force the device to reauthenticate and proper policy to be applied.

Also, don't write policy around [Machine Authenticated] unless you just really like counting on the MAC address to no be spoofed.  If you want computer and user authentication, use TEAP.  If you want to validate the device as an allowed device on the network, use the management platform (Intune/JAMF/etc.) to do so and then take action based on that.  Your role mapping should be looking at the interesting points of who/what/why/where/when/how for the authentication session and then setting roles based on that.  You definitely want something more interesting than just "authentication was good".  Testing [User Authenticated] is redundant, if [User Authenticated] isn't present then you'd never get to the authorization state in the first place.

hi, What is the difference between these two conditions in terms of evaluating succeeding conditions and enforcement? (rules evaluation is first-applicable)

VS