I am not sure if you have reviewed the wired authenticaiton tech note, although they do have some additional provided info that may be helpful.
https://arubanetworking.hpe.com/techdocs/NAC/clearpass/platform/wired-policy-enforcement/
As there are also a few things to be aware about. There is a difference between "Mac Auth" and "Allow All Mac Auth". Mac auth requires a mac address to be present in the list to return a radius accept. Only radius attributes can be returned when an accept takes place. A radius reject will result in a failed authentication session on your NAD. Based on your timers and config of the NAD, the radius will most likely keep retrying until the port is disconnected. Its not uncommon for mac-auth deployments to use "Allow All Mac Auth" and use the "Endpoints DB" in the authentication source. When allow all is used, you can send a radius accept message back to your NAD with radius properties when a condition is not meet in clearpass. Some use cases would be to return a role or vlan that would essentially isolate your client.
If you change vlan's on mac-auth post dhcp on client. You may have to perform a port bounce. I try to stay away from changing vlans with mac-auth as it adds complexity. If you want to deny or block traffic for a client, it does not matter if a client gets dhcp or works. I would generally recommend allow all and to provide in unwanted experience vs use a reject. When using a reject your clearpass logs will be filled with failures and depending how you look at the data you could think this is a negative experience with the box.
If you use the GDR you can perform authorization on this to fetch attributes. You can use a guest user role or other properties form the GDR. I have used custom sql queries to return data. It may not be supported by TAC as its custom but there is no reason why it cant be used if you understand what you are doing. The role mapping area is where you would fetch data for authorization normally. If the mac is in GDR return role [x]. In the enforcment you can look if role [x], [y] is present and return a role. If those conditions are not present then return an unwanted experience.
Based on the screenshots this is what I would perceive without knowing anything more then what was shared.
- authentication -> will only return an accept if in the list otherwise a reject
- enforcement tab -> I would not use evaluate all as it can get complex and confusing fast. your default action is "allow all" and your only rule is "allow all". This has no logic applied and you will just return accept to anyone who gets that far.
- Role Mapping Policy -> Not sure if this is in the service. You are also doing authorization so this will require the device to be fingerprinted in endpoints before you can perform authorization on it. Anytime you want to fingerprint you need to get dhcp helpers to clearpass before rejecting the user or disabling them in a role that does not permit dhcp. Typically the role you give this will then be used in logic in the enforcement.
- Enforcement Policy -> Your rule should look for GRP_ThinClients. Your default role should permit an option so you can perform dhcp profiling by clients. This way when the client first comes on with no fingerprint, it will fingerprint perform a timeout (number of ways to do this), and then reauth with fingerprint info. Just keep in mind the endpoint caching is default to 5 minutes. I typically use radius session timeouts for 315 seconds so the client will come back on 15 seconds after the cache expires.
- Enforcement Profile -> This is typically an action in the enforcement policy. Its not applied. Your action is radius accept, and you are sending an Aruba radius attribute "Aruba-Device-Mac-Address" with an attribute that was dynamically expanded. Not all radius attributes are intended for being returned. Typically in the enforcement you would return items like a role, vlan, user-name, etc.
Original Message:
Sent: Jul 28, 2026 04:01 AM
From: AM-il6358
Subject: MAC Authentication with Host List
yes of course, its only for a lab after this i will connect the AD with Clearpass and i will give access with the AD, but i need to make some labs just to learn the clearpass.
Original Message:
Sent: Jul 25, 2026 11:36 AM
From: JK-90898a
Subject: MAC Authentication with Host List
I would generally recommend a better solution. I would also agree that the guest repository is probably the most beneficial place to do this work.
There are to many devices have virtual mac/ private mac's. It has really become the norm on most modern OS that I see. I don't even like relying on a mac as any source of truth outside a temp placeholder. The assumption should be it could change tomorrow. The concept of static mac remind me of the mid 2000's. Not to mention its easy to obtain a mac and spoof it.