I received this email the other day:
"I went through your article regarding NAC, and would like to ask you one question more to the part of the topic, which was not mentioned. When we internally discussed the possibility of implementing VLANs, we found out that we cannot find suitable solution for 802.1X authentication."
"The problem of VLanned scenario with 802.1X authentication is that if there is newly coming (imaged) PC, which was not previously member in the Active Directory, and it comes to VLAN for unmanaged PCs (as it does not have certificate to get access through the secure switch), it can never get through (because in order to get through it should have received the certificate in the process of its adding to the AD). So we are moving in the circle."
"At this moment, I can't see any safe solution - because opening AD controllers to the restricted VLAN doesn't seem suitable to me, however I don't see at the moment any other way how to (automatically, using certificate renewal process) deliver certificate for an on--going process of granting access."
Coincidentally, I had run into this very issue while building out my test network for an upcoming NAC review. Like the writer of this email, I too had computers that I needed to join to Active Directory and receive a computer certificate, but I had already enabled 802.1X on the switches. Without a way to authenticate to the switch and subsequently get an IP address, I was stuck.
I had three options, recable the devices into a switch that had 802.1X disabled. That would have worked, but I hate moving cables around because it just leads to tangles. I could have disabled 802.1X on the switches, but I just configured them for 802.1X. I hate going backwards almost as much as I hate moving cables around. My final option, and the one I used, was to login to the network using a username and password, join the computer to the domain and request a computer certificate. Problem solved.
This translates into a production environment easily. Microsoft's Internet Authentication Service (IAS), aka a RADIUS server, supports multiple profiles, so I created one profile that used PEAP for certificate authentication and another policy for username and password authentication. In the latter policy, I restricted logins to a specific user group that I called Provisioning. When I created a new host, I could login using an account that belonged to the Provisioning group and I could complete the host installation. For newly provisioned hosts, I would recommend simply connecting hosts to a non-802.1X switch that is separated from the rest of the network but can still access the Active Directory. Once the hosts are provisioned, they can be placed anywhere.