I'm wondering if anyone else has overcame the issue I'm about to describe.
We are happily using ACS 4.1 to authenticate wireless PEAP clients to an external Windows AD database.
We do have machine authentication via PEAP enabled, but at this time we are not using Machine Access Restrictions as part of the external database authentication configuration.
The clients (we care about) are using the native XP ZWC supplicant and are configured to "authenticate as machine when available".
The passed authentications log does successfully show the machines authenticating.
We only want to permit users on our PEAP protected WLAN if the machine they are using has an account in the domain (and they are a Windows XP box - the currents standard corporate image).
In a testing lab, we enable Machine Access Restrictions, with the access mapped to "No Access" if there is no machine auth, or if machine auth fails. If a machine is shut down and boots fresh, or if the logged on user chooses to logoff while on that WLAN - we see the Windows box sends its machine authentication. As I understand it - a windows XP box will only attempt to authenticate as a machine when a user logs off, or upon initial boot.
In our environment (and I'm sure many others) - if a user comes into the office and docks their laptop and is attached to the wired LAN and boots or logs on - the machine maybe authenticating - but it is authenticating directly to the AD as our wired LAN is not using 802.1x or ACS radius.
So the user maybe logged on and working on the network - and then choose to undock which activates the wireless.
The problem then - the machine does NOT attempt to authenticate as a machine and only processes the user credentials - which get passed onto ACS vial the WLC - and when MAR is enabled with the No Access mapping for no machine auth - the user auth obviously fails.
Has anyone seen / over come this ?
Our goal is to enforce that only standard XP imaged machines get on the wireless PEAP network (where the configuration is maintained by GPO).
This may not answer your question, but might help with the problem. Why not set your machines for machine only (aka computer only) authentication? This is something you can enforce via an Active Directory GPO (along with other wireless settings that might make your life easier if the user isn't changing them).
Thanks for the suggestion Robert. Unfortunately, I don't think thats an option for us for a few reasons.
Our ITSec policy won't permit it - we need the usernames/identity of people logging in, and without dot1x on the LAN ports, windows would still not send the machine auth when the user undocks.
I think the core element I am challenged by is the method Windows chooses to send a machine auth (only at boot, or logon/logoff).
I'm not 100% sure that we're on the same page, so forgive me if I ramble a bit:
The 802.1X auth is a separate process from the user auth against AD when logging in. If you set the 802.1X for machine auth (for wireless, wired, whatever), that will have no impact on the requirement for the user to enter their Windows logon credentials to get access to the machine. The 802.1X authentication is just to get a physical network connection (i.e. - the IP address). The user's AD credentials are still used/required for access to any AD-aware resource on the network (Exchange, SharePoint, file shares, etc.).
You have touched on an item that I am particularly interested in implementing. I would like to know some things about Computer-Only Authentication with Active Directory. Is this feature something that you can just turn on and it works on machines that are already on the domain, and rejects any machine that isn't?
I guess to ask a different way..... I'm trying to implement 802.1x and MAB in a lab environment. I'm interested in using computer-only authentication for the workstations that connect to our network for the 802.1x portion. I've read the KB article that you posted, and I wonder if this GPO will require that I populate the AD server with any individual machine credentials (i.e. Machine1, Machine2, Machine3, etc.) and if so, then how? Or, does the AD server simply check to make sure that the machine is a member of the domain and if it is authentication is deemed successful?
And if you have any useful information on how I may be able to use AD for MAB as well, I'd LOVE to hear it.
All machines joined to your domain already have credentials (the computer object actually has a password). If you are using PEAP, then enable machine auth on the RADIUS server, and enable machine auth on the computers, and you're good to go. If you want to use EAP-TLS, then you'll also need to have each machine enroll a machine (aka computer) certificate.
That's great! A couple of questions though:
Finally, do you happen to have any info I could use regarding setup of MAB that makes life as easy as this (or not), that would be STUPENDOUS!!! Thanks for letting me pick your brain, Man.
Never mind on the question about the schema. Testing shows that I do need to get that part done.
I approached my Window guys to see how difficult it would be to extend this schema, and they said that it wouldn't be difficult at all. But, the guys are asking me if I have a program that would implement and extend the schema. Would you happen to know what they are talking about? The configuration in the MS knowledge base article looks simple and straight-forward enough, but they seem to need something different.
Also, I am running both PEAP and EAP-TLS for Machine Authentication on the ACS server so I can test Windows logon creds for authenticating the machine as well as using domain information for Comuter-Only Authentication as well. When I set up the supplicant to forward Windows logon creds to the server, it works like a charm, but I'm having no luck when I attempt to run Computer-Only Authentication. I think that if I do this, no matter how slick, the EAP-TLS will need a certificate to validate, which I'm not interested in implementing. If I move forward with Computer-Only Authentication, will I need to disable EAP-TLS so that it doesn't break the PEAP authentication?
Here's the only thing I could find on extending the schema (I'm not a schema expert):
If all of your clients are Windows machines, it's easier to stick with PEAP for machine auth, user auth, or both. However, your RADIUS (ACS) server should have a certificate that the clients trust. You can configure the clients to ignore the RADIUS server cert, but then your clients will trust any network that looks/works like yours. Get a cert/certs for your RADIUS server(s).
You can have PEAP and EAP-TLS configured on your ACS server without causing problems for your PEAP clients (be aware that most of my experience is with 4.1/4.2. Earlier versions may not work the same way). Your comment about what you're testing is confusing me. Let's say you have (only) PEAP configured for machine auth on both the client and the ACS server (no user auth is configured on the client, or in ACS). Your client will offer it's machine account AD credentials to the ACS server in order to authenticate to the network. Those credentials will be validated against AD by your ACS server, and then the machine will get an IP address and connect to your network. Once your machine is on the network, and a user tries to log on, then the user's AD credentials will be validated against AD (without any involvement of ACS). You should not need PEAP and EAP-TLS together. Both are used for the same purpose: 802.1X authentication for network access. PEAP only uses AD to validate machine credentials (or user credentials), because you configured your ACS server to use AD as a user database for validating 802.1X credentials. You could just have easily used PEAP on the client side, but told ACS to an LDAP connection to a Linux box with a user/machine database. Validating credentials for network access (802.1X) is not the same thing as authenticating to AD for server/printer/email/whatever access. I wish I could explain this better...
Actually, you're explaining it tremendously well, but keep in mind that in the world of 802.1x, you're talking to a complete NOOB. I'm still ironing out what works and what doesn't when it comes to architecting this deployment, and I just needed someone to put it to me simpler.
As far as the certificate goes, the first thing I did was install a self-signed cert on the ACS server when I started this work. I figured that would suffice at the time. But if I'm using PEAP, I won't need to enroll the clients like with EAP-TLS, right?
The thing with PEAP and EAP-TLS configured together was server-side only (sorry about the confusion). In working with this since my last post, I realized I didn't need them both on the server, so I' dropped the EAP-TLS and went with PEAP on the machine supplicant and the server. It seems that all I have left to do before I can test this is to get the schema extended on the AD server then test authentication.
Oh, and I understand the concept thusfar, it's just the implementation method that was killing me.
The reason I want to use Computer-Only Authentication in the first place is because I didn't want to deal with DHCP timeouts if the users didn't immediately logon when they power on their machines. I wasn't exaclty impressed with modified open mode which would require punching access holes for authentication using ACLs either.
I figured Computer-Only Authentication would grant network access before the user ever entered Windows logon creds, which would remove the DHCP timeout issue and it would be more transparent.
About the only other thing I think you need to worry about is having your clients trust the certificate from the ACS server. You want your clients to check the certificate of the ACS server during the authentication process (in Wireless Zero Config, that's the "Validate Server Certificate" option in the network card's authentication properties for your SSID). The trick is in how to tell your machines that they can/should trust the ACS server's certificate. I'm not an expert in these areas, but I think there are several ways to do this:
- Use something like SMS (maybe a GPO) to update each client's certificate store with the ACS server's cert. Google will help you out with this option.
- Have each user manually accept the cert the first time they connect to the wireless network. Windows will prompt the user, but user's typically ignore the prompt and then call the help desk when they don't get connected.
- Install a new certificate on the ACS server that comes from a 3rd party provider that is already trusted by your clients (like Entrust, etc.). This is a recommended route as it usually involves the least amount of work
Did you ever get this resolved?
I am working on the exact same authentication policy. I need machine authentication againast AD for all of our users; wired, wireless and VPN/ASA.