Homekie**er's homelab journal

The Active Directory lab · Part 3 of 3

Designing domain-account Wi-Fi with 802.1X and NPS

An example of how Active Directory could decide who joins a wireless network, without handing out a shared password. It is a design I can test, not a setup I have deployed.

2 min readIllustrative example, not a deployed setup

I wanted a way to give a lab user network access without handing out a shared password. A shared Wi-Fi password says nothing about who joined: everyone who knows it looks the same. If the wireless network asked Active Directory instead, each connection would belong to an account.

This entry is a practice design. The access point, policy and accounts are examples, and every result below is the one the design should produce.

The parts of the conversation

Three roles are involved, and the standard names help:

  • The supplicant is the laptop or phone asking to join.
  • The authenticator is the access point. It does not decide anything itself; it holds the connection while it asks someone who can.
  • The authentication server is Windows Network Policy Server (NPS). The access point talks to it over RADIUS, a protocol built for exactly this kind of “should I let them in?” question.

NPS checks the account against AD DS and then evaluates its network policy, for example “members of the Lab Wi-Fi group, using a domain account, may connect”. This whole process is what 802.1X describes.

  1. Laptopasks to join the SSID
  2. Access pointforwards the request over RADIUS
  3. NPSchecks the account and the network policy
  4. AD DSconfirms the account and its groups
Illustrative design. The access point never sees the password check itself; it only receives NPS’s accept or reject. This path is about joining a network, which is a different question from which services an account may reach once it is on.

How I would test it

A design like this is only worth something once both answers have been tried. I would run two tests:

  1. A permitted lab account. I expect the client to connect, and NPS to record that it granted access (event 6272) with the name of the policy that matched.
  2. A guest account outside the group. I expect the client to fail to connect, and NPS to record that it denied access (event 6273) with a reason.

Then I would compare the client’s own log with the accept or reject event on NPS. If the two disagree, the problem is in between: the access point, the RADIUS shared secret, or the certificate the client is told to trust.

Keeping it separate from private access

It would be easy to draw this on the same diagram as Twingate and NetBird, but they answer different questions. 802.1X decides whether a device may join a network at all. Private access decides which service a person may reach once they are connected. I keep the two paths apart so neither gets credit for what the other does.

Takeaway: test an access design with two accounts, one that should get in and one that should not, and read both the client log and the NPS event. A design is proven by the refusal as much as by the success.

Further reading

Skills used

  • Designing 802.1X with RADIUS and NPS
  • Planning a test before deploying

All skills, grouped by what job postings ask for

Tools in this entry

Every tool and its documentation