cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12532
Views
41
Helpful
5
Replies

User and Machine Authentication with PEAP and EAP-TLS

Hi Experts,

 

I'm new to ISE and I've gone through the docs of User and Machine Authentication which provides different set of access to the PC (when no user logged in with machine auth) and the complete access to the users (with user auth) enabled.

 

Also, PEAP is used as the outer-tunnel while MSCHAP-V2/EAP-TLS are used as inner tunnel, depending on the supplicant configuration.

 

My query is, where the PEAP (with MS-CHAPV2/EAP-TLS) or only EAP-TLS comes into picture.. Is it when the computer waiting for the user to enter (CTRL+ALT+DEL) or once the user enters their credentials to login to the domain...?

 

If i'm not wrong, if it happens before user tries to login, how does the computer will know, that I've this cert in my trusted store to trust this EAP cert from ISE to form the outer-tunnel...?

1 Accepted Solution

Accepted Solutions

Non-Windows operating systems do not have native capabilities to join AD domains and do not really have the Computer/User space separation like Windows. You can use PEAP or EAP-TLS for authentication via 802.1x, but there is no machine account in AD, so you're limited to user auth.

Mac OS uses Profiles to install certificates and trust chains as well as configure the supplicant settings. A common enterprise approach is to use EAP-TLS for 802.1x and use an MDM (like JAMF Pro) to configure and deploy the necessary profiles and enrol the user certificates against the internal CA. The user credential in the certificate can then be checked against AD during authentication to ensure it is a valid user.

View solution in original post

5 Replies 5

Colby LeMaire
VIP Alumni
VIP Alumni

When you configure the Windows native supplicant, you can choose to do machine only, user only, or machine OR user authentication.  Assuming the default of machine OR user authentication, it depends on what state the computer is in.  When the machine boots up, it is in the machine state and will only send the machine credentials.  If using PEAP MS-CHAPv2, this would be the machine's AD username/password that is created automatically when the computer joins the domain.  If PEAP EAP-TLS, then that would be the computer's identity certificate.  As soon as the user logs in to the machine, the computer switches to user state and will send the user's credentials.  Either the user's username/password (MS-CHAPv2) or the user's certificate (EAP-TLS).

 

Hi Colby,

 

Thanks for the reply and I'm able to gain more clarity on how it works.

Final one. When the PC boots up , the PEAP outer tunnel is established, how does the PC trusts the Radius certificate when is having limited access and waiting for the user to enter CTRL+ALT+DEL.

Could you please let me know what's happening behind the scenes.

There is a good write-up that was done by one of the ISE Technical Marketing Engineers that describes how this works. It's a bit old now, but still relevant as the Windows behaviour has not changed.

Machine Authentication and User Authentication

 

 

Hi Greg,

 

Thanks for sharing it. 

 

There is a unique password which gets created between the machine and the AD. This is used to identify the machine which is called as 'machine auth'.

Is there any other way we could achieve the same result of Machine and User creds in the non-windows OS (like MAC). I believe TEAP is supported only from ISE 2.7

 

It may be a dumb question, looking for the assistance :)

Non-Windows operating systems do not have native capabilities to join AD domains and do not really have the Computer/User space separation like Windows. You can use PEAP or EAP-TLS for authentication via 802.1x, but there is no machine account in AD, so you're limited to user auth.

Mac OS uses Profiles to install certificates and trust chains as well as configure the supplicant settings. A common enterprise approach is to use EAP-TLS for 802.1x and use an MDM (like JAMF Pro) to configure and deploy the necessary profiles and enrol the user certificates against the internal CA. The user credential in the certificate can then be checked against AD during authentication to ensure it is a valid user.