Using certificate OID's to authenticate WiFi users.
-
Monday, February 11, 2013 5:36 PM
Hello All,
I am trying to sort out some issues with certificate OID's in our PKI environment. The background is we are in production with our wifi using EAP-TLS. Everything is working great and has been for months. Some of our architects suggested that we could assign unique OID's to the certificates that would represent different parts of the organization. For instance, Human resources would have one OID, Claims would have its own OID, and so forth. It was then suggested that we could use NPS to check for these individual OID's using the "Allowed-certificate-OID" setting and then act upon them as we wanted, like putting them onto different VLAN's. So my first question is, is this even possible?
Our CA is provided by our ISP. I spoke to the CA admin there and he created a new TEST template and published it. I can validate the users are getting this new certificate and I see the OID he assigned on the "Detail" tab of the certificate's properties page. On the "General" tab
it shows server authentication, client authentication and then simply shows the OID number. Just the number... doesn't state what it's for.
On the "Detail" tab, the "EKU" field which shows the same purposes listed on the General tab and then once again on the "Application Policy" field.So, armed with the new certificate, I opened the NPS console and edited the "Network Policy". In the "Settings" tab, under the "Radius Attributes" heading, I added a new "Vendor Specific" attribute, selected "Allowed-Certificate-OID" and entered the new OID.
This did not work. Clients cannot connect. Log's show:
"The Enhanced Key Usage (EKU) extensions, section of the user or computer certificate are not valid or are missing. Rejected."
Which brings my second question... Does anyone see where this went wrong?
Thanks so much for any assistance!
Mike
All Replies
-
Monday, February 11, 2013 5:54 PM
Hi Mike,
NPS can check for AD group membership. Wouldn't that be much easier to check for your different departments? I also see the point with the OID if someone is not working for HR anymore but for Legal you have to issue a new certificate to the user. What is with users working for more than one department?
Sorry I could not help on the OID question but might I gave you good points for not doing it that way.
Regards,
Lutz
-
Monday, February 11, 2013 6:10 PM
Hi Lutz,
Excellent suggestion. Thank you! Actually, I was over-simplifing to make this easier to explain. It's more like inter-agency.
The idea is we have several agencies in the state and all are managed by the same provider.
All agencies are using the same CA, thus all have the same trusted root as we are all part of the providers AD forest.The concern is other agencies using the same EAP-TLS architecture would get at least layer 2 access to our WiFi when in our facility.
To mitigate this, the OID method was suggested. Each agency would have a unique OID and when they attempt to connect to WiFi, we would identify the OID and have NPS determine which VLAN to send the traffic.If OID's and NPS are not the correct components for this, perhaps another solution can be suggested? Im open to whatever you guys got!
Mike
-
Tuesday, February 12, 2013 2:41 AM
Did you still include the Client Authentication EKU in the certificate. You are performing client configuration, so you must include the Client Authentication OID and your custom OID. then you can use NPS to test for the custom OID as you designed
Brian
-
Tuesday, February 12, 2013 6:01 PM
In the properties of your Network Policy you can specify a value for Allowed-Certificate-OID under the Settings tab in section Vendor Specific. This OID is the OID from the certificate's purpose or usage attribute. If I am right you have the OID already in the right place in the certificate.
Hope that helps,
Lutz
-
Tuesday, February 12, 2013 8:27 PM
Okay all,
I figured this out. In case anyone else is having this trouble I will include the answer.
First, let me say this was user error!
When we were issued the new certificate the EKU field shows the following:
Server Authentication
(1.3.6.1.5.5.7.3.1)Client Authentication
(1.3.6.1.5.5.7.3.2)1.3.6.1.4.1.XXXXX.X.X.XX (1.3.6.1.4.1.311.21.8.XXXXXXXX.XXXXXXXX.XXXXXXX.XXXXXXXX.XXXXXXX.XXX.XXXXXXXX.XXXXXXX)
Obviously, the X's are actual digits.
So when we were given the OID from our provider, he wrote.. "Your OID is 1.3.6.1.4.1.XXXXX.X.X.XX
Naturally, this was the value I added to the Allowed-certificate-OID field. Turns out it's actually the value 1.3.6.1.4.1.311.21.8.XXXXXXXX.XXXXXXXX.XXXXXXX.XXXXXXXX.XXXXXXX.XXX.XXXXXXXX.XXXXXXX
Once I added this value, it started working. To validate, I changed the last digit to something else, it stopped working. I changed it back and it worked again so we are now working!
Thanks everyone for your help. It was just encouraging knowing I had other people’s eyes on this with me.
Mike
- Marked As Answer by LNI_IT Tuesday, February 12, 2013 8:28 PM
-
Wednesday, February 13, 2013 1:47 AM
Just so you know, you should remove Server Authentication from the certificates issued to the client. They are not acting as servers, they are authenticating as clients. you could be opening connections to the clients with this cert
Brian
-
Thursday, February 28, 2013 6:51 PM
Hi Mike,
Looking to achieve the same thing, but would like to know if the OID constraint you now got working, work as a replacement for having to use windows authentication in the connection request policy? Or you just combine them...?
/Adde
.png)
