Objective

A client could not get on wireless. The project team had handed off the site, discovery docs were thin, and the engineer who knew wireless had left. I had to map what was there and get it working.

The site ran a multi-vendor 802.1X stack: co-managed FortiGate, HP ProCurve switches, Ubiquiti UniFi APs, Microsoft NPS tied to Active Directory, plus MAC filtering. No one had documented it.

Topology

[ Users ]──[ UniFi AP ]──[ HP ProCurve ]──[ FortiGate ]── LAN/Internet
                         │              │
                         └── 802.1X ───┴──[ NPS on AD ]──[ AD DS ]
                              MAC filter + user cert

The APs tunneled through the switches to the FortiGate. The FortiGate sent RADIUS requests to NPS, and NPS checked AD. If any link in that chain breaks, auth fails with no error.

Steps

1. Map what exists. I walked the UniFi controller, the switch MAC tables, the FortiGate policy, and the NPS console. No diagram existed, so I drew one as I went. I checked which SSID tied to which VLAN and which RADIUS clients NPS knew about.
2. Follow the auth path. I traced a failing client: association to 802.1X EAP to switch to FortiGate to RADIUS Access-Request to NPS to AD. I ran netsh ras diagnostics on the NPS host and watched for Access-Reject. I found a mismatched shared secret and a stale RADIUS client entry that still pointed at the old gateway.
3. Fix the secret and the client list. I corrected the shared secret on the FortiGate and on the UniFi RADIUS profile so both matched NPS. I added the current AP subnets as RADIUS clients and restarted NPS.
4. Test MAC filtering. Two test users still failed. MAC filtering was on, but the allow list lived in a different AD group than the one NPS queried. I moved the check to the right group policy and retested.
5. Document it. I wrote the first architecture doc for the site: VLANs, SSID to RADIUS mapping, NPS policies, AD groups, and where the secrets live. I left it where the next tech will find it.

Gotchas

• Shared secrets fail with no useful error. NPS sends Access-Reject whether the secret is wrong or the user is wrong. Check the secret first.
• NPS answers the RADIUS clients you list. I added the new AP subnet to NPS and auth started working. If you do not list the IP, NPS drops the request.
• MAC filtering hides behind 802.1X. If the AP shows connected with no internet, check the MAC allow list before you touch the firewall.

Takeaways

I solved this with no docs and no one to ask. I mapped the path, followed the wire, and wrote it down. You can do the same the next time you hit an undocumented stack. I did not know this mix of FortiGate, ProCurve, and UniFi before the ticket. I left it documented for the next person on call.

Environment: co-managed FortiGate, HP ProCurve, UniFi, NPS/AD. One day, no handoff.