This section looks at what is new in the world of software (Operating Systems included) and how to take best advantage of what is out there.
An interesting issue that was discovered after deploying security certificates for Remote Desktop Authentication into the TPM of desktop computers and some (physical) servers, after go live with the security certificate clients could no longer connect with the error below being displayed in the Remote Desktop Services log on the server.
The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP: <IP ADDRESS>) has been disconnected.
After chasing many red herrings around cryptography, schannel implementation, and the likes the root cause seems to be an issue with the storage within the TPM itself – as a workaround the certificate can be stored in the ‘traditional manner’ instead. An ideal fix would probably involve a firmware upgrade on the TPM.
When setting up Passwordless security key sign-in Windows and attempting to sign-in to the first machine you have setup (although it could be any machine!) you may encounter the error:
Your credentials couldn’t be verified. (code: 0x000006d, 0x0)
This error message appears even though you can sign-in with the key to AzureAD and other web services.
The cause is likely to be the account you are testing with is a member of the Domain Admins (or a similar) privileged security group, I keep bumping into this one but can’t find the source article where I first read this. If I manage to find the article I’ll post a link!
UPDATE 31/01/2024: It appears there is a way to overcome this issue with a modification of Active Directory objects described at: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-faqs#fido2-security-key-sign-in-isnt-working-for-my-domain-admin-or-other-high-privilege-accounts-why
A bit of an odd one here (and has been reported to Ruckus as something that either needs clarifying or fixing) in that if you want to remove the requirement for CAPTCHA when self registering in a ‘out of band’ workflow block you need to configure your own SMTP server. Now that’s all fair however even with the server configured the disable option still doesn’t appear.
In this case it looks like you also need to disable (or configure yourself) the built in SMS server at Administration > System Service > Outbound SMS. With that set the disable option then appears in the drop down.
After a few years on hold it’s great to be back at CITC this time in the British Motor Museum. The video presentation covers a short (if speedy) introduction to Node-RED and it’s ability to integrate systems through their APIs.
Demo 2 is of note and shows how a user visiting a malicious website can have their internet access revoked until a helpdesk agent has a chance to clean-up their machine and then grant access again without even having to login to the firewall controlling that access.
A little treat that I hope will help someone at some point, for those with Palo Alto Networks Next Generation Firewalls (NGFW) and Aruba Instant Wi-Fi you can forward syslog messages from the controller to the NGFW and parse them with the profile below to map users to IP addresses.
There is plenty of information on syslog to User-ID at this link for those just getting started: https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring.html.
The text strings you will need are:
- User authenticated
AADSTS700016: Application with identifier <Entity ID> was not found in the directory ‘<Directory ID>’.
The fix here is easy – the GlobalProtect client injects a :443 at the end of the domain name which isn’t mentioned in the guide from Microsoft (https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/palo-alto-networks-globalprotect-tutorial) but is in the guide from Palo Alto Networks (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008U48CAE).
Interestingly the Reply URL doesn’t specifically require it (although mentioned in the Palo Alto guide) but either way easy to fix.
It’s been a while since posting and I do hope to sort that out but for now another quick mention of some work with Ruckus Cloudpath.
Although massively flexible in its design I’ve come into a few niche cases where administrators would like a single DPSK pool (which is bound to a single SSID) but where different users have different expiry dates on those DPSKs. Thus far I’m planning on interacting with the API via Node-RED to update these entries in the API as the provisioning process takes place – something for another blog post.
However for those who are just getting to grips with the API (using PowerShell in my case) I hope the short example in this GitHub repo can be of use: https://github.com/jamesfed/RuckusCloudpathAPI.
You may find that when doing decryption on a Palo Alto Networks Next Generation Firewall that images in Slack channels are not displayed or are only shown in a very low resolution – in addition images cannot be uploaded. When inspecting the HTTP error messages in your browser a 503 response may also be seen.
To top off the issue you may also see that User-ID isn’t mapping traffic from the Slack desktop application against the traffic which negates any User-ID based decryption exception you might have.
While helpful the Slack connection test tool at https://my.slack.com/help/test also doesn’t appear to throw any errors.
To fix this issue you need a decryption exception custom URL rule for the files.slack.com domain (which fixes viewing images) along with the base domain for your Slack tenancy (fixes uploads). This domain can be found by clicking the drop down in the top left corner of the Slack client.
If you have multiple Slack tenancies then you will need an exception for each one.
As always when making exceptions for your decryption policy please consider how it might degrade your ability to detect malicious usage of the network – in this case the sharing of files with unknown payloads.
For more information about Slack network usage visit: https://slack.com/intl/en-gb/help/articles/360001603387-Manage-Slack-connection-issues.
XML: The returned XML does not match the expected schema. (code: PE233) — JSON: The returned JSON does not match the expected structure (Invalid JSON.). (code: PE231)The cause is the default encoding from PowerShell is UCS-2 LE BOM as shown in Notepad++ below. The fix is simple in that when generating your REST configuration append -Encoding utf8 at the end of the Out-File command. I’ve also seen this apply to a few other situations when using PowerShell to output some form of text – in particular feeds for Palo Alto Networks Next Generation Firewalls.
It’s a bit of an odd situation but sometimes you might want to take information from a cloud service in this case Cortex XDR from Palo Alto Networks and drag it into an on premise logging service. This guide will have a look at how to get this log data in as well as parse it such that you can break out the individual fields in the log entry.
In looking at the documentation it appears that the logs are in the Comment Event Format (CEF) but are then wrapped up in syslog for transmission. Although Graylog can absorb CEF directly this additional layer of syslog means we have to take in the syslog and then send the event messages through a processing pipeline in Graylog to extract the CEF data.
So onto the guide – which assume you are familiar with the operation of the Cortex XDR management console and Graylog (shown version is 3.3), for simplicity the code snippet you’ll need is also shown below from GitHub.