Different rules for different people sounds simple until the firewall asks an awkward question — how do I actually know who this traffic belongs to? There are three answers, and they are not equally strong.
Every Policy Manager rule is only as good as its condition — the test that decides which policy a session belongs to. In the video, users are assigned by IP address or MAC address, which is the right starting point for a small network. But there is a third, stronger condition — username — and each of the three fails in a different, predictable way. Picking the wrong one is the number one reason a policy setup works on demo day and quietly stops working a month later.
| Condition | What It Really Identifies | Where It Breaks |
|---|---|---|
| IP address | A device's current network address | DHCP hands the address to someone else |
| MAC address | A network card's hardware ID | Phones randomise MACs; MACs can be spoofed |
| Username | The actual logged-in person | Needs Directory Connector and a directory |
Matching by source IP address is what most small offices use first: the HR manager's PC is 192.168.1.50, so a rule sends that address to the HR policy. It works perfectly — until the address changes. If your DHCP server leases addresses freely, that PC may come back tomorrow as 192.168.1.87, silently fall into the default policy, and the user reports that "the internet changed". The fix is part of the method, not an extra: give every policy-matched device a static IP or a DHCP reservation so the address the rule expects is the address the device always gets. IP ranges also work well for whole groups that live on their own subnet or VLAN, such as a computer lab.
A MAC address is burned into the network card, so it survives DHCP changes and follows the device from address to address. For fixed office desktops and printers, it is a dependable condition. Be honest about its two weaknesses, though. First, it identifies a device, not a human — anyone who sits at that PC gets that PC's policy, including its extra permissions. Second, modern phones and laptops randomise their MAC address on Wi-Fi for privacy, and a determined user can spoof one. Use MAC matching for hardware you control; do not build a security boundary for guests or students on it.
Matching by username is the only condition that follows the person from device to device: log in as a teacher anywhere and the teacher policy applies. On this platform it is powered by the Directory Connector app, which links the firewall to your Active Directory or similar directory and learns which user is logged in at which address. That is a bigger commitment — you need a directory, the connector configured, and it is another subscription app alongside Policy Manager itself. For a school or office that already runs a domain, it is usually worth it. For a five-PC office with fixed desktops, IP reservations honestly do the same job for free.
IP, MAC and username are the identity conditions, but rules can also match on things like time of day and day of week — the classic school example is relaxing a policy during lunch break — plus the interface the traffic arrived on and the destination. Combining conditions narrows a rule: source address and time means both must be true. Every condition you add makes the rule more precise and also easier to accidentally make so narrow it never matches at all. When a rule mysteriously does nothing, read its conditions one by one before assuming the policy itself is broken.
Start from what you are protecting. Fixed desktop PCs in departments — IP reservations or MAC, either is fine. A lab or classroom of identical machines — one rule for the whole subnet. Staff who move between machines — username via Directory Connector, or accept that the policy follows the desk, not the person. Guests and personal phones — do not try to identify them at all; let them fall into a strict default or guest policy by design. The method is right when its failure mode is boring: if an address changes or a MAC randomises, the device should land somewhere safe, not somewhere privileged.
The video assigns users by IP and MAC address step by step — after this page, you will know exactly when that is enough and when it is not.
▶️ Watch Full VideoMost often its IP address changed. If the rule matches an address and DHCP later gives that address to another device, the policy effectively moves house. Give matched devices a static IP or a DHCP reservation so the address is guaranteed, then re-test.
Yes. A rule condition can be an address range or a subnet, which is the cleanest way to handle a lab, a classroom or a department that sits on its own network segment. One rule then covers every device in that range, including replacements.
For username conditions you need the Directory Connector app and a directory it can read, such as Active Directory. Without it, the firewall simply does not know who is logged in where, so stick to IP or MAC conditions — they cover most small networks honestly well.