topic Cisco ISE 3.0 Agentless Posture - Status remains Not-Applicable in Network Access Control

Cisco ISE 3.0 Agentless Posture - Status remains Not-Applicable

ka2tik001 — Thu, 14 Oct 2021 10:29:24 GMT

We are currently doing setup for agentless posture on ISE 3.0. So far I have got all pre-requisites listed in Cisco guideline in place, however it seems to be not working. On the ISE agentless posture reports, it shows agentless script uploaded completed, but I don`t see agentless script being executed successfully on client, thus the endpoint is not showing any posture status in the radius live logs after 802.1x authentication

The endpoint have got below setting enabled so far :

- PSRemoting is enabled and Remote Server management through WinRM is allowed

- Local admin is set for client and same is allowed for remote server management

- Firewall is set to allow port 5985, Reachability between client and ISE seems fine

Now the posture process completes below steps successfully :

- Endpoint gets 802.1x authentication

- Agentless Posture option selected in authorization profile seems to be getting triggered upon 802.1x authentication

- ISE initiate remoteshell session on port 5985 and able to get in using local admin credential configured on ISE endpoint script.

- Admin certificate chain and script provisioning on client completes successfully and End point does receive "admin-script-formatted-xxxx.ps1" file

From this stage two problem starts :

1 - Script does not get execute on endpoint and the last log generated on endpoint "PostureScript xxx" output file remains - Script Provisioned Successfully, nothing beyond that.

2 - Sometime the script does get execute but ends further with "Curl Error code 35 Unable to download agentless posture with return code" & "curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline."

For point 1 - Not getting any clue what makes script to not get execute post provisioning on client

And for point 2 - CRL check failure or CRL server offline doesn't seems to be the actual cause, as from endpoint with manual checks to CDP - Certificate Distribution Path check for installed certificate i don't see any error and CRL validation complete successfully but same seems to be failing from posture script.

I have been trying and looking at guides all over along with tac but so far no luck. Has anyone got this issue with ISE 3.0 agentless posturing? Any suggestion or input for further troubleshooting would be highly appreciated.

Re: Cisco ISE 3.0 Agentless Posture - Status remains Not-Applicable

JALALUDDEEN A A — Wed, 10 Nov 2021 11:28:40 GMT

Hi ,

Anybody having the solution , i am facing the same issue

Posture status showing not applicable , however scrip showing uploaded completed

@ISE

Re: Cisco ISE 3.0 Agentless Posture - Status remains Not-Applicable

Kalipso — Fri, 14 Jan 2022 10:49:12 GMT

Hello,

I'm also trying to implement Agentless posture right now.

What I've figured out is that in the report "Agentless Posture" even when we have "Agentless script upload completed" it doesn't mean the script was executed.

You can check on the endpoint (windows) in the event viewer logs : Applications & Services Logs > Microsoft > Windows > PowerShell> Operationnal

The user is admin, but the excecution policy is blocking :

"Error Message = File C:\Users\admin_ISE\admin-script-formatted-105964.ps1 cannot be loaded. The file C:\Users\admin_ISE\admin-script-formatted-105964.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170."

Indeed we have an execution policy running for our Windows float that prevents the execution of an unknown script.

It seems that we cannot write over the default endpoint script in ISE ( powershell.exe -ScriptBlock {} )

, or sign it with an internal CA...

Still trying to bypass this as the GPO policy is not something I can easily change.

Hope this helped.