Wireless ISE Certificate check for Domain Joined Computers?

[paddingtonbear]

I am SCCM/IT admin inside our work domain. And installing client(s) from scratch. All users have their AD profile linked with InTune Azure AD and apparantly from what ive read our Wireless authentication is Cisco ISE with EAP. Our network team has not specified any conditions or requirements in details on what the certificate used in the handshake is supposed to have other than

1). Certificate XY, should have Issued By: Root xyxy V2
2). Be valid and not expired
3). Then handshake will be made and authentication to Wi-Fi accessible.

So my questions are as followed. Since some clients that are portable devices come back to me. Where user telling that they are unable to access the corporate Wi-Fi (trusted network), not public. I then go to my work area, use gpupdate /force and most of the times this solves the issue.I been trying to determine any differences on a "working" portable device from installation, versus a "faulty" one where LAN connection works, and Wi-Fi (trusted network) does not. But can't seem to find any difference regarding the certificate(s) data.


Is this authentication certificate supposed to be queried by Powershell from the IntermediateCA folder, or LocalMachine\My* ?
And is there any noticable difference that i could use to see if the certificates are valid or needs to be re-checked by GPO. Before my machines are handed over to the user(s).

[Nancy Saini]

I would suggest checking live logs on ISE if you see any failed authentication for the scenario when users are unable to access the corporate Wi-Fi. If there is any issue with client certificate you should see that in the detailed authentication report on ISE.

If no authentication request is seen on ISE then check client debugs on the wireless controller.

[paddingtonbear]

Is it possible to do this through Microsoft Endpoint Admin Center, since i am not Server Admin. If there are people actually monitoring the RADIUS / EAP Live Logs - wouldn't they catched this issue by now. I find it odd in a severe way since this is hospital environment domain i'm at. Even though a simple GPO /force query with LAN network on the client(s) most often fixes this issue, it should not appear at all if someone did their monitoring correct and alert the infrastructure department and people below.

I will have to do a check today at work if any certificates after a client PXE/PE installation is revoked by the issuer, inside the CRL certificate location. And what gpresults is giving me after all GPO:s have ran with /force policy checks.

[briggsmitchell34]

Based on the information you have provided, it seems that the issue may not necessarily be with the authentication certificate itself, but with the clients' ability to access and properly communicate with the certificate authority (CA) to authenticate and join the wireless network.

To answer your first question, the authentication certificate is typically installed in the LocalMachine\My store on the client devices. However, it's important to note that the certificate should have been pushed out to the client devices through Group Policy (GPO) or a similar deployment mechanism.

To determine whether the certificate(s) are valid or need to be re-checked by GPO, you can use the Certificate snap-in in the Microsoft Management Console (MMC) to view the certificate(s) and check their validity. You can also use PowerShell to query the certificates in the LocalMachine\My store using the Get-ChildItem cmdlet. However, if the certificates were deployed through GPO, it's important to check the GPO settings to ensure that the certificates are being deployed correctly.

Additionally, it's possible that the issue with the Wi-Fi authentication could be related to the configuration of the Cisco ISE server or the wireless access points (APs) themselves. You may want to work with your network team to ensure that the configuration is correct and that the APs are properly communicating with the ISE server.

Overall, troubleshooting issues with wireless network authentication can be complex and require a multi-disciplinary approach. It's important to work with your network team and other relevant stakeholders to identify and resolve any issues with the network configuration, client devices, and certificates.

[paddingtonbear · Accepted solution]

@briggsmitchell34 
Today was a kinda stresful day with alot of information. But i managed to get in touch with one of our responsible SA users (Server Admins). But apparantly no one in our own network team or security department had access to Cisco ISE. This was outsourced to two people working as consults for another company apparantly, which i said to him sounded odd in my ears. How should we trust that someone else doing active log searches then, or even troubleshoot the live AP logs from ISE as frequent.

What we came up with though, was that:

1.) Not every installed client were added to the AD group Domain Workstations, as supposed to, when troubleshooting the Task Sequence logs and manually checking the Active Directory Groups using ADUC tool. Required manual adding + restart with ethernet and then computer would be able to login using the wireless AP in the room
2.) Certificates are located in CurrentUser\CA, instead of MY/Personal, using the recommended (MMC) snap-in tool

They assured that they would have a look into this, for the upcoming week(s) to see if they find anything else looking weird. So hopefully that could solve our user issues longterm. Meanwhile i added the RSAT toolkit to my workstation PC. And put together a script using the included Powershell module "Get-ADGroup" cmdlet to query our installations for both points that the day gave me.

I have access to
Active Directory
Microsoft Endpoint Manager
SCCM console
InfoBlox
and some personal Powershell modules ive created during my time here. But since i am just a technician/Client deployment admin in our team i feel like my work here is kinda overkill for my paygrade. So gramatic errors and technical terms may differ from reality so please have understanding.

[thomas]

You are doing all you can by trying to configure the Windows workstations with Intune MDM/MEM and/or GPO policies but ultimately it will not work until you know from the ISE admins what EAP protocol(s) are required for authentication (EAP-TLS, PEAP+MSCHAPv2, TEAP), whether they are for machines or users, and what credential types are expected (certificates, domain credentials, or passwords).

Once you know that, you may configure the wired & wireless windows supplicants for those protocols and credentials and push the profiles to your users. 

@Nancy Saini is also correct in suggesting you understand any ISE LiveLog errors from this to understand exactly why it is failing and any tweaks that may need to be made.