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.

After how woefully lacking in detail for the novice in OS 10 switches the Dell documentation is below is a little snippet that can be used to configure your switches with what appears to be enough permission for PRTG (or a similar SNMP monitoring system) to keep an eye on them.

After entering configuration mode a readonly view with a base OID is set (I’d be grateful for some feedback on this!), then a group (prtg) is created to contain the user and defines readonly permissions, finally a user (prtguser) is created, assigned to the group (prtg) and the relevant password and privacy encryption strings set.

snmp-server view readonly included
snmp-server group prtg 3 priv read readonly
snmp-server user prtguser prtg 3 auth sha LONGANDSTRONGAUTH priv aes LoNGANDSTRONGPRIV
write memory

Logs from the FreeIPA server can be used with the Syslog receiver function of a PAN NGFW to send username to IP address mappings into User-ID and in turn be used to create policies based on the users identity. To extract the data from the logs you will need the parser shown below.

I could only find a log that matched up with a login (nothing for a logout) and it’s worth a mention that you may need to exclude some servers (like mail servers and file servers) from User-ID as you will see multiple logins from multiple users over a very short period of time.

In recently deploying the Captive Portal feature of a Palo Alto Networks Next Generation Firewall (NGFW) in testing we were finding Apple Macs take 120+ seconds to load the sign-in page. First thoughts jumped to the Apple Captive Network Assistance (CNA) feature not functioning correctly however this appeared to be a dead end. Some time and a few packet captures later showed that the Mac wasn’t even trying to reach out to the Captive Portal in a timely manner, after much head scratching the customer I was working with suggested that their Sophos Endpoint agent (Intercept X) might be the cause of this problem.

Disabling the agent didn’t seem to resolve the issue however uninstalling it did – the Captive Portal page appeared nearly instantly. In reviewing the packet captures again it was clear the Sophos agent was trying to reach out to a reputation service which was being blocked by the authentication profile on the firewall, it just took a really long time for the agent to stop trying and allow access to the Captive Portal.

To work around this issue the domains listed in the link below were added to an authentication bypass policy on the NGFW, with this in place the Captive Portal loaded promptly. If anything it makes sense to allow unauthenticated access to such services (including Windows Update and the likes) to ensure a client has the ability to update itself regardless of authentication status.

This presentation covers the MITRE ATT&CK matrix and it’s application in an Oxford or Cambridge College (or indeed any intuition) to gain increased awareness of exposure to cyber attacks and what can be done about them. Note, it looks like OBS captured the audio from the videos that wasn’t played back to the audience – sorry for talking over them!

My thanks to the CITC committee for the invite to return and present and I’m looking forwards to seeing everyone again in 2024!

  CITC 2023 Presentation (3.9 MiB, 5,174 hits)

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:

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:

The text strings you will need are:

  • User authenticated
  • username-([a-zA-Z0-9\_\.\@]+)
  • IP-([A-F0-9a-f:.]+)

When setting up a GlobalProtect Portal/Gateway with AzureAD you may find you receive the error message:

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 ( but is in the guide from Palo Alto Networks (

Interestingly the Reply URL doesn’t specifically require it (although mentioned in the Palo Alto guide) but either way easy to fix.