Behavor differtent user Ise certificates

[athan1234]

Hello

Someone please explain the issue with Eap-Tls.

[Milos_Jovanovic]

Hi @athan1234,

How did you configure workstation? Have you hardcoded that it should use certificate or username/password? Have you hardcoded it to use user or machine identity?

Your last screenshot, ISE Authorization policy is not visible, so I don't see the condition you setup. Based on your successfull tests, and given both PEAP and EAP-TLS are successfull and a fact that same authorization rule is being hit, I would assume that authorization policy does not restrict one or another.

Also, in the authentication policy, Continue condition is normally used for MAB, not for 802.1x scenario.

Kind regards,

Milos

[athan1234]

Hello @Milos_Jovanovic , I appreciate your response.

I didn't put up the workstation in the department that set up the certificates and machines anthe they will  using Microsoft's Intune for deploy .

Although I have access to a machine for testing ( name prueba) I can change the workstation setup and see how it is configured. The previous time , I set up the workstation with use certificates and user and machine authentication. Maybe I should choose a user instead of a machine. Only a user certificate, not any machine certificates, have been configured by my client. What could therefore be the issue?

I will be able to make a test tomorrow. Please let me know if you want me to perform a particular test or if you want me to investigate the error. I can attach the test on the post 

[Milos_Jovanovic]

Unless you strictly define what you want to be permitted, there are no guarantees what will be used. For example, by default, Windows machine is using user or machine identity, depending if user is logged on or not. This way, you can't be sure what you will see and use in this scenario. Also, what is configured on one device is not neccessarily same thing that is configured on another device, so this might be a reason why you see both PEAP and EAP-TLS authentications. You need to define what exactly you want to use, and to configure workstation accordingly.

Kind regards,

Milos

[athan1234]

hi, @Milos Jovanovic
I agree with you completely.

my clients needs connect using user certificate authentication over EAP-TLS.
It will be deploy via Microsoft Intune.
I am first trying different domain users without intune deploy.
I can set up the ssid user cert and eap-tls authentication user.

I struggle to understand in various circumstances:

how is it possible for a user to connect to an SSID without a certificate using user domain credentials ?

On the ise logs, I notice EAP-TLS (MSCHAV2), which I have never seen before.
The concept is to connect using a trusted certificate no user domain name and password .

Other tester was the user's certificate, without a user domain and pasword , in this way I am able to establish EAP-TLS performance.

I occasionally find this message in the logs.

I'm reading this article right now as I consider configuring Windows Intune.

https://community.cisco.com/t5/security-knowledge-base/how-to-integrate-cisco-ise-mdm-with-microsoft-intune/ta-p/4187375

will i need to install the certificate in ISE?

Include DigiCert Global Root G2 on their list of reliable CAs.

[Milos_Jovanovic]

I believe it is due to Continue option you placed under 802.1x authentication rule. If user is not found, it would still proceed to authorization, and I assume something there is permitting him/her, regardless of authentication method. As already stated, this option is used only for MAB - if MAC address is not found, still proceed with authorization where redirection is happening.

Kind regards,

Milos

[athan1234]

Yes you are right .

I just changed it for reject .Is better reject  isen´it

[athan1234]

I just created a test.
I receive the same message with a certificate.

[Milos_Jovanovic]

Hi @athan1234,

On ISE, under Trusted Certificates, go and check if your internal Root/Intermediate CA has selected option that it will trust certificates on dot1x (don't have ISE in front of me right now, so can't say how exactly this option is called).

Kind regards,

Milos

[athan1234]

Hi @Milos_Jovanovic 

yes I guess this is the option you tell me

I'm checking everything
This ISE was operational two and a half months ago, therefore the incidence became apparent to me.
I can see that the certificate was no longer valid.

I lack background in certificates.
I created a new certificate, created a CSR, and sent it to the CA's management to be bound to the new certificate and imported into the system.

When I look at the expired certificate, I discover a wilcard *domain.
Befor I can see the EAP check, I can't tell who is at work.

I configured SAN   IP ise, domain resolution, hostname ise, and other settings in the new certificate I created.Perhaps that is the issue?

I attach both cerficates

EXPIRIED CERTIFICATE

 NEW CERTIFICATE

[Milos_Jovanovic]

Yes, the option I was mentioning is "Trust for client authentication and Syslog". As I can see, this certificate is issued by Sectigo, and used on you ISE server(s). Which certificates are you using on client side? Are those also issued by Sectigo, or you are using your internal PKI for that?

Expired wildcard certificate should be replaced at some point, but it is not what is messing your dot1x. As wildcard is tied to pxGrid and RADIUS DTLS, I don't think it is related to your current issue. Furthermore, wildcard certiicate can't be used for dot1x, as clients are not trusting it.

Kind regards,

Milos

[athan1234]

Hi thanks for you reply
You are correct; I should have realized that there was another certificate for internal PKI signed with the ise this certificate had a error .

My certificate is accurate, yet I continue to receive an error.

[Arne Bier]

The new cert looks good and to be honest, having the Admin and EAP signed by your internal PKI is often perfectly acceptable. Your expired cert was a public signed cert, and also contained a wildcard - this cert was possibly used elsewhere in the organisation. Wildcard certs and EAP typically don't play well together with Windows supplicants. I can't remember whether it's Digicert or some other CA ... with those guys you can apparently do wildcard EAP certs. But I would not bother with it. What you have looks good. I even put 3 year certs on my Admin and EAP, using internal PKI. Browsers and supplicants are happy with that.

The issue you face might be the Windows supplicant configuration. Is there a reason that you chose User Authentication and not Machine Authentication? Machine authentication is generally better because the machine gets connected during boot up, and will also stay connected when user logs out. The "user auth" in my opinion, does not require a network authentication to ISE. Rather let that be a Windows authentication to AD/Azure etc.

If you're using Intune, do you put machine certs on Windows computers?

[athan1234]

Hello @Arne Bier, I appreciate your response.it's plausible that the supplicant made the mistake.
I obtain with a other PC for good authentication.
The client informs me that all of them have the same configuration.
I've tested the boss' PC and several others, and the outcomes are always the same error.I asked the client to leave the wireless settings unattended ( without intune) in those PCs, and even though I was able to set everything up correctly, I still received the same issue.Regarding user authentication, my client has chosen to implement it i do not whywhat will transpire
I'm crazy.
Do you have any suggestions for the test?
I downloaded wireshark for capture packet wifi on the client computer, however i can no see any packet transmit.

Steps
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
15049 Evaluating Policy Group
15008 Evaluating Service Selection Policy
15048 Queried PIP - Normalised Radius.Ra
11507 Extracted EAP-Response/Identity
12500 Prepared EAP-Request proposing EA
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request (
ms)
11018 RADIUS is re-using an existing sessi
12502 Extracted EAP-Response containing
response and accepting EAP-TLS as
12800 Extracted first TLS record; TLS hand
12545 Client requested EAP-TLS session ti
12805 Extracted TLS ClientHello message
12806 Prepared TLS ServerHello message
12807 Prepared TLS Certificate message
12808 Prepared TLS ServerKeyExchange m
12809 Prepared TLS CertificateRequest me
12810 Prepared TLS ServerDone message
12505 Prepared EAP-Request with another
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing sessi
12504 Extracted EAP-Response containing
response
12505 Prepared EAP-Request with another
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing sessi
12504 Extracted EAP-Response containing
response
12505 Prepared EAP-Request with another
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing sessi
12504 Extracted EAP-Response containing
response
12505 Prepared EAP-Request with another
11006 Returned RADIUS Access-Challenge
11001 Received RADIUS Access-Request
11018 RADIUS is re-using an existing sessi
12504 Extracted EAP-Response containing
response
11514 Unexpectedly received empty TLS m
rejection by the client
61025 Open secure connection with TLS pe
11504 Prepared EAP-Failure
11003 Returned RADIUS Access-Reject

[Arne Bier]

The ISE Error detail gives a hint about the client perhaps not trusting the ISE EAP certificate. The clients MUST have all the CA certificates that were used in signing the ISE EAP System certificate installed.

Have you checked that all of the PSNs have the correct and expected EAP System certificate (signed by the PKI CA that the clients can trust? Each PSN can have its own EAP System cert ... if you have many PSNs then it's easy to not notice that at first glance)

As far as debugging goes, have you tried an ISE endpoint debug?  You can use the MAC address of a failing wireless client and then debug that in ISE. With any luck, the endpoint debug will also capture the client certificate, which you can then download and inspect. Unfortunately you can't verify how the supplicant was configured - but you might get a copy of the client cert.