Ignore expired secrets named CWAP_AuthSecret if Azure Application Proxy is used.

[zimmermannb]

Hi,

we are using that extension and it is working great, many thanks for that 👍👍.

We noticed something that could be impoved:

When an Application is published using the Azure-AD-Application-Proxy, three client secrets are created for the App-Registration, and usually one of them is expired. The Microsoft Documentation clearly states that this is expected and the expired secrets should not be deleted.
The CheckMK-Plugin does generate a warning for this situation, cause one of the secrets is expired.

It would be great if the Plugin would ignore the oldest secret named "CWAP_AuthSecret" as along as there are two more "CWAP_AuthSecrets" that are still valid.

Here are some more details for reference:

https://www.reddit.com/r/AZURE/comments/p9uk2d/azure_app_proxy_registration_expiring_client/

https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-faq#can-i-modify-an-application-proxy-app-from-the---app-registrations---page-in-the-microsoft-entra-admin-center-

[CLiX-1]

Thank you for your feedback!

There is another app with similar behavior. Microsoft creates an app registration for Power Virtual Agents (Bots) and each app has 4 auto managed certificates.

I think it would be the best to ignore these apps completely.

Actually you can disable the service with the rule „Disabled services“, but I will check if I can disable the discovery of these kinds of app registrations.
I think every Entra App Proxy app should have a tag „WindowsAzureActiveDirectoryOnPremApp“ and Power Virtual Agents should have a tag like „power-virtual-agents-“.

[zimmermannb]

Yeah of course we can disable specific services but we do have ~1000 app-registrations, which makes it hard to select them individually. If the Services could get a Tag if they are a Bot or a Published App we could disable them based on a Rule.

[CLiX-1]

I've uploaded a new version of the plugin (v1.2.1).
With this version it is possible to set an exclude list for secret and certificate names (descriptions) as RegEx.
You can create a rule with the name "CWAP_AuthSecret$" and assign it to your host. All secrets with this name will not be used to calculate the credential expiration time.

Would you test the new version in your environment?
After uploading and activating the new version, you may need to restart the monitoring core (cmk -R). In my environment this was not done automatically.
If it works fine, I can upload it to the Checkmk exchange.

I think with this option we have the most flexibility to exclude specific credentials or all like the Entra App Proxy secrets.
Excluding the whole app could be dangerous because this app can be used as an app proxy and other API access.

[zimmermannb]

We did update the Plugin and it is working partially. The dispalyName is read by CheckMK and also the Rule to filter for those does work. 👍👍

Unfortunately it did not work for our usecase as it turns out Azure is sometimes using the field "displayName" and sometimes the field "customKeyIdentifier" which has the displayName Base64-Encoded.

So far I've identified 3 different cases.

	#Case 1: only customKeyIdentifier is used base64Decode(Q1dBUF9BdXRoU2VjcmV0) = CWAP_AuthSecret
	# UI shows: "CWAP_AuthSecret"
	"passwordCredentials": [
		{
			"customKeyIdentifier": "Q1dBUF9BdXRoU2VjcmV0",
			"displayName": null,
			"endDateTime": "2025-08-31T12:18:41.6790422Z",
			"startDateTime": "2024-08-31T12:14:41.6790422Z"
		},
		{
			"customKeyIdentifier": "Q1dBUF9BdXRoU2VjcmV0",
			"displayName": null,
			"endDateTime": "2025-03-31T01:26:14.3904675Z",
			"startDateTime": "2024-03-31T01:22:14.3904675Z"
		},
		{
			"customKeyIdentifier": "Q1dBUF9BdXRoU2VjcmV0",
			"displayName": null,
			"endDateTime": "2024-11-28T07:54:43.3592889Z",
			"startDateTime": "2023-11-29T07:50:43.3592889Z"
		}
	],
	
	#Case 2: both values are different base64Decode(dW5hdHRlbmRlZGxvZ2lu) = unattendedlogin
	# UI shows: "CN=AAD_unattended_2023"
	"keyCredentials": [
		{
			"customKeyIdentifier": "dW5hdHRlbmRlZGxvZ2lu",
			"displayName": "CN=AAD_unattended_2023",
			"endDateTime": "2024-02-17T03:03:52.1722606Z",
			"startDateTime": "2023-02-17T03:03:52.1722606Z",

		}
	]
	# Case 3: only displayName
	# UI show: test22 and test11
	"passwordCredentials": [
		{
			"customKeyIdentifier": null,
			"displayName": "test22",
			"endDateTime": "2025-04-27T07:44:26.323Z",
			"startDateTime": "2024-10-29T07:44:26.323Z"
		},
		{
			"customKeyIdentifier": null,
			"displayName": "test11",
			"endDateTime": "2025-04-27T07:44:03.844Z",
			"startDateTime": "2024-10-29T07:44:03.844Z"
		}
	]

Would it be be possible to also expose "customKeyIdentifer" to checkmk so we can also use those values within the rule?

[CLiX-1]

It looks like for certificates (keyCredentials) the customKeyIdentifier represents the thumbprint of the certificate, but not always. I saw a certificate with invalid data (Microsoft Assessments). The UI shows "Thumbprint not available". It looks like customKeyIdentifier and displayName are always filled with data.
For the plugin I use displayName if available for certificates now.

And for secrets (passwordCredentials) the customKeyIdentifier contains the description like the displayName.
So for secrets only one attribute is used and the other is null. The UI takes one of the two attributes as description.
For the plugin I do the same now. displayName is used if available. Otherwise it uses the customKeyIdentifier if available.
I had a problem with the base64 string from the SharePoint Online Client Extensibility Web Application Principal application. There was no readable data. There's no readable data in the UI either. I ignore these errors and do not show any description.

Please check out the new version 1.2.3.

Thanks!

[zimmermannb]

Now it works perfectly and we are able to exclude CWAP_AuthSecret from the checks. Thans for providing the update. Really appreachiate your support.