I would like to create a rule that matches on MAC auth, with a End-System and Device Type group set.
There is an initial issue with doing that in that the MAC auth takes place before the end-system has had a chance to get an IP address from the DHCP server and therefore no fingerprint to use in the Device Type match.
Now I believe the answer to this was to create a rule that allows MAC auth, then another rule that tested against the device type once it got an IP address from DHCP?
Issue is I’m not clear on the process, what triggers the re-auth to re-run through the NAC rule engine (believe that has something to do if the end-system receives a new bit of information?), and how the NAC and Policy Roles and Rules would be laid out to achieve this?
Be grateful for any advise?
Many thanks in advance
Best answer by Ryan Yacobucci
You got it. The answer is to create another rule that allows MAC auth below it with a different profile.
“Device Type” information is information that is learned from a DHCP packet, so it’s not available to be evaluated on the initial authentication of the device.The client needs to be authorized into a profile/Role that allows DHCP, then DHCP packet then gets to the NAC and then NAC learned the device type information.
The process that triggers reauthentication is that when the hostname/device type family information is updated the NAC performs an “internal” reauthentication evaluation because of the field change. It re-runs the rules engine evaluation to determine if the new information will result in a rule change. If it determines a different profile is returned based on the new information the NAC reaches out with the re-authentication request.
So DHCP packet is received.
NAC identifies there is a hostname or device type/device family change AND there’s a rule that matches on this criteria so it runs a rule engine evaluation
NAC identifies different profile returned based on new information
NAC reauthenticates the device and it pops into the new rule.
If the DHCP packet is not received because the client hit a deny all rule because of the initial rule miss you can see why the rest of the process doesn’t work. This is the reason for the “placeholder” rule when it comes to “learned” or “after the fact” information like device family or hostname (LDAP host group rule)
Let me know if this helps.