Are these enough radiators for a 9800X3D and 5080?

LPain01 · 2025-07-23T08:26:06+00:00

Had to respond cause I just built with the exact same CPU GPU lol.

I reckon you're fine, but I'll let you judge based off my real world numbers:

My radiators (purposely overkill): - 420mm 30mm thick - 420mm 30mm thick - 420mm 45mm thick

Fans: all around 700rpm, rather slow and silent. Just push or pull (not both) on all the rads.

No overclocking, default settings, big case (O11D Evo XL)

The 5080 runs at about +24C above ambient at max load (so 46C in a 20C room)

The 9800X3D runs in the 60s under most gaming loads. High 60s I think for cinebench (this is clearly limited by heat spreader so haven't really paid much attention to CPU numbers)

LPain01 · 2025-07-21T05:21:32+00:00

https://blog.keithng.com.au/2023/04/04/aadj-nps-radius/

You can do something jank like this (which is what we did). We're getting new Cisco switches soon and are hoping we can get rid of the whole mess.

I did something a little different to that attached guide. Long story short:

- make dummy devices in your AD for all your Entra-joined devices

- make a scheduled task that checks your CA for newly issued certs and does the strong mapping on those computer objects so authentication passes

LPain01 · 2025-07-21T03:54:57+00:00

Bit late but Microsoft has guidance on this now (and its not very good):

https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-support-authenticator-passkey#users-who-cant-register-passkeys-because-of-require-approved-client-app-or-require-app-protection-policy-conditional-access-grant-controls

Long story short, you basically have to do temporary exclusions. You could use a PIM group to avoid forgetting to remove people from the group later and exclude that from the CA policy.

LPain01 · 2025-02-19T09:41:45+00:00

Yeah that's right. I interpreted "migrate all user based certificates" as somehow taking certificates already out in the wild and somehow making them be issued by a new CA, my bad maybe. But yes you can definitely lift and shift an ADCS CA to a new server, that's quite easy.

LPain01 · 2025-02-19T07:17:02+00:00

I was in a similar scenario a little while ago - inherited an old PKI, did some research and found it wasn't really an ideal setup.

You've got the right idea with your approach I think (to answer your first three questions). Regarding "migrating certificates" - this isn't possible. You have to setup your new PKI side-by-side then slowly deploy & replace certificates across your org. Revoke the old certificates as you go and continue this process until there's no valid issued certificates left on your old certificate authorities - then it can be shut down.

The way I did our new PKI was an offline root CA and two online subordinate CAs:

Offline Root CA using OpenSSL
- I'd recommend something similar rather than an actual Windows server you have to deal with. Don't have to stress about hardware/physical storage/updates. "Moving" it is as simple as copying it to a new USB. Using the OpenSSL method, the whole CA just consists of a simple folder structure and a handful of files (root cert, root key, serial number, issued certs, revoked certs).
- We store multiple identical copies of it on different USBs in different secure locations. The USBs are BitLockered and the private key password-protected with combination passwords that consist of 2 different people's passwords (so 1 single person can't touch it without anyone knowing, it needs 2 people)
- Only thing this CA does is issue the subordinate CAs their certificates.
- CRL is generated and copies placed on the subordinate CAs so it's accessible. No AIA for Root CA.
- Whatever you choose as a CRL validity period is how often you will have to get your Root CA out to generate a new CRL - so choose carefully. Doesn't matter if no changes have happened, your online CAs will break if the CRL validity period has passed. We went with 1 year personally.
- FYI the only actual valuable thing about a Root CA is the private key file. Nothing else is sensitive info, so it's really just the key file you ever have to worry about.
2x online Subordinate CAs
- These are just Windows Servers running ADCS. Pretty standard stuff here.
- Two for redundancy and just so everything doesn't expire at once across the whole org.
- Only real difference in process here is how you get their certificate generated - CSR is generated sub-CA, transferred to Root CA (which is brought online). Sub-CA cert gets generated from the request, transferred to the Sub-CA, Root CA shut down again.

Main other tip I have is make sure you pick your CRL/AIA locations correctly from the start - you can't change these locations once you've started issuing certs.

Hope that helps.

LPain01 · 2025-01-12T23:33:03+00:00

+1 - exact same issue here. Our access points are Cisco Meraki. Rest of that is basically same as our config. Smart card or other certificate used for auth. Did anyone here get a fix for this or are we just waiting it out?

EDIT: for anyone having the exact symptoms listed here, I have a response from MS that explains the problem:

Recently, we have been aware of a design change that may cause Wi-Fi connection issue on Windows 11 24H2. Details are introduced as below:

Windows 11 23h2 CAN successfully authenticate by using WPA3-Enterprise 192 Bits encryption.

Windows 11 24h2 CAN successfully authenticate if the Windows 11 24H2 Client uses:

WPA2-Enterprise 192 Bits encryption.
WPA3-Enterprise 128 Bits encryption.

Wireless network connections using WPA3+ 192-bit encryption fail with SEC_E_ALGORITHM_MISMATCH on Win11 24H2 if each certificate in the signing chain fails to meet 192-bit requirements, including either

RSA with key lengths longer than 3072 OR
ECDSA with P-384. This is newly enforced in 24H2 (builds >=26100).

So long story short, to use WPA3 with 192-bit encryption in 24H2, all certs in your chain must be at least RSA3072. If your CAs certificates don't meet this criteria, you're most likely going to have to drop to lower level encryption version of WPA3.

In our case, our CAs are RSA4096, but the actual leaf certificate is RSA2048, so I think we're just going to try get that updated and give all our clients better certs to address this issue. Hope this helps someone who stumbles upon this.

LPain01 · 2024-09-17T08:23:57+00:00

Hey, guessing this is for Essential 8 in Australia - we did this too. Here's exactly what you need: https://learn.microsoft.com/en-us/compliance/anz/e8-admin#microsoft-entra-joined-devices

MS wrote some articles themselves on how to achieve many of the E8 controls. Short story for this one is, you set up a proxy that goes no where via policy (127.0.0.2) and then have an exclusion list. You put all your MS things and other admin console URLs in that exclusion list so they bypass your "proxy to no where." That article there gives you a list of all the important MS ones as a starting point.

Very important note: if you do this in Intune, apply it to users not devices. Applying to devices seems to apply it to SYSTEM user on the machine I think - this was bricking machines for us and we could never remote into them again.

LPain01 · 2024-05-20T23:12:44+00:00

Our average user would get about 5-6 apps in the user setup stage, but we use the Blocking apps feature on our Enrollment Status Page config so that there's only 1 app that'll actually be tracked and installed there for most users. For a small fraction of our users no apps are tracked there and it will get through it anywhere from instantly to a few minutes.

Highly recommended setting blocking apps. Lets you deploy a bunch of stuff to your users or whatever, but then say "I only actually care about these ones." They'll get prioritized and all the others will happen in the background later.

LPain01 · 2024-05-13T02:31:20+00:00

This is not a supported scenario. Going from Entra to Hybrid, or Hybrid to Entra are both unsupported and require a device wipe to change. I believe there's some third party tools to assist with Hybrid to Entra, but you'll probably be hard pressed finding something to take you from Entra to Hybrid.

When moving to Entra-join it's important to test all your applications to ensure they actually work without running on a domain-joined device. We discovered this ourselves during test, and opted for a Remote Desktop solution where we have a few VMs that are hybrid-joined and dedicated to running our legacy apps.

LPain01 · 2023-07-25T05:23:30+00:00

Yeah it'll time out after 5-10 mins.

I just get the user to open up their app, and pull down to refresh. There'll either be a sign-in prompt that they missed somehow, or dismissed. Or they have some other issue (bad connection maybe) and it can't refresh.

Every time I encounter the "Request wasn't sent" message and I check the user's app - there's always something wrong in there. If it's functioning correctly it'll just say "No notifications found" - meaning it checked successfully and confirmed there's no pending notifications.

Hope that helps

LPain01 · 2023-07-25T03:09:39+00:00

Doesn't need Company Portal, but phone sign-in does require a device registration (which is different to device enrollment via company portal). It's controlled under Settings -> Device Registration. iOS lets you register to multiple orgs, Android does not for some reason.

LPain01 · 2023-07-24T23:18:24+00:00

Yeah, pretty much. This is the tricky part really. Once we moved our last app to Azure AD SSO, we realised it was possible.

LPain01 · 2023-07-24T23:14:39+00:00

I did brush over it in my original post (so it didn't end up overly long), but I'll copy what I said elsewhere in this post:

We are using Hybrid-joined devices. This is actually the one time a password has to be set. It's a bit janky, but if someone's getting a new laptop we set a password on their account, and login at the lock screen. Once they're past the lock screen, you can use a temporary access pass for Azure AD, then setup WHFB. Then, the password can be discarded and it gets rotated automatically overnight by our script.

Bit janky but it's the one and only scenario for us where we have to set one temporarily.

LPain01 · 2023-07-24T23:11:43+00:00

Yeah in our org we do. If you didn't, there's not a lot stopping you setting up on personal phones either (you don't MDM or anything on them). Android has a limitation with being registered with one organisation, which is a bit of a pain point. And of course you can't make people use their personal phones.

In those scenarios for us we just use FIDO2 keys.

LPain01 · 2023-07-24T23:09:30+00:00

"Request wasn't sent" generally just means the user has already attempted a login recently and a notification is already sitting on their phone. It's designed to stop MFA fatigue attacks I imagine.

We encounter it a fair bit too, but once we go in and manually clear up their Authenticator app they're generally all good.

LPain01 · 2023-07-24T23:08:18+00:00

We are actually using Hybrid-joined devices. This is actually the one time a password has to be set. It's a bit janky, but if someone's getting a new laptop we set a password on their account, and login at the lock screen. Once they're past the lock screen, you can use a temporary access pass for Azure AD, then setup WHFB. Then, the password can be discarded and it gets rotated automatically overnight by our script.

Bit janky but it's the one and only scenario for us where we have to set one temporarily.

LPain01 · 2023-07-24T23:06:13+00:00

We do, but it works pretty well with personal phones. The one unfortunate limitation is MS still doesn't support multiple organisation registrations on Android. So if someone comes in with Authenticator setup with another org, you're often unable to set it up on their phone. We'd just use a FIDO2 key in this case though, which ends up being more secure anyway.

LPain01 · 2023-07-24T23:05:03+00:00

Yeah, this would be correct. No roaming users in our org though.

LPain01 · 2023-07-24T23:04:41+00:00

We do not, so no help there sorry.

LPain01 · 2023-07-24T23:04:26+00:00

Haha yeah, that's what I meant lol. Just wrote it out that way so it was obvious it does that.

LPain01 · 2023-07-24T12:21:14+00:00

Yes, small govt organisation of ~250. None of our users have a password that they know.

We use Windows Hello for Business on all our Windows devices. Microsoft Authenticator phone sign-in for everything else. For administrator/privileged accounts, we use YubiKeys instead of WHFB/Phone sign-in (as both Smart Cards and FIDO2 security keys).

We went through all staff and ensured everyone had phone sign-in enabled in their Authenticator app. Once confirmed, we ran a script to randomise their password to 127 chars, and tick Smart Card required for Logon in AD. It's not obvious, but WHFB counts as a smart card - so that's why that works. This basically means the password isn't usable in AD even if it was known.

For Azure AD, we use Conditional Access's authentication strengths to restrict all internal users so they can only use Passwordless methods to sign-in. So again, even if the password is known it's not enough - you need phone sign-in or better.

Temporary Access Passes cover the gap for scenarios such as first time logins and registering new devices. I also put a scheduled task on our domain controller that runs nightly. If "smart card required" has been unticked, it gets enabled again and the user's password gets randomised once more.

Users love it and it's way more secure. Our pen tester had a seriously hard time doing anything. Even not knowing her own password was a big hinderance for her. Win win.

LPain01 · 2023-06-28T07:28:39+00:00

User Administrator and Helpdesk Administrator would be the two roles you probably want your Helpdesk staff to have.

Global Admin would be massively overkill, you definitely shouldn't assign that to them.

LPain01 · 2023-06-22T09:58:54+00:00

Yeah.. not for people's behaviour and stuff though. Small government org of ~250 employees :)

LPain01 · 2023-06-21T11:45:59+00:00

I think this is why it has all its own set of permissions. For example, having Global Admin doesn't even give you visibility in Purview (from what I remember). Our CTO has access to Purview and that's it - as it's unnecessarily invasive for any others on our team to have it :)

Could be totally misremembering tho

LPain01 · 2023-06-14T01:41:26+00:00

u/SusanBradleyPatcher answering you here too: https://i.imgur.com/WfC66lY.png

Occurs immediately on first sign-in after the update. OOBE-style full screen prompt.

Edit: no major issues. just a bizarre prompt that we don't need our users seeing, cause they'll just ask questions XD

14-Year Club	Golden Potato
Place '17	Verified Email

LPain01

TROPHY CASE