johndball

Backed up the 2025 DCs with expired certs, although each DC had a valid (expires next year) cert in the personal store, but backed them up nonetheless and removed the old ones. Two more machines dropped out of the domain. It's not a terrible issue as everything here is QA or "mirrors production"... just some annoyed folks. Event logs on the two that just dropped out after making the change above was this: "This computer was not able to set up a secure session with a domain controller in domain [domain] due to the following: We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. ADDITIONAL INFO If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain." Same fix as last time too: airplane mode the WIFI, log in as local admin, turn on WIFI, disconnect from domain, wait 30 seconds, reconnect to domain, reboot. Everything is fine again. Cleaning up the old rules and settings helped slow down the tide of dropping devices, but hasn't solved it. Going to sit in the background and watch this thread because I'm out of ideas as well now.

Wanted to share a one week update: I had one more device drop off since these changes were made. I immediately grabbed the event logs and this timestamped error was thrown twice immediately preceding the user's attempt to login and the domain trust error showing up: "The client has failed to validate the domain controller certificate for [domaincontroller01]. The following error was returned from the certificate validation process: A certificate chain could not be built to a trusted root authority." DomainController01 is an AD-integrated certificate server so I'm wondering if there is additional authentication happening in the communication stream that is failing. From what I read in gabrielgbs97 's post, I suspect there is. Can anybody provide insight into ADCS for the root CA? Does Server 2025 change the way certificates are validated and should I roll the root CA server since the upgrade? It was last issued prior to the migration to 2025.

My client active directory trust issues stopped when I removed conflicting GPOs and restored the "default configuration settings" in AD Admin Center and the only custom settings were password length and complexity settings. I rebuilt the password length settings, removed conflicting GPOs, and all issues below (except issue 2 and 3) have resolved. TL : DR History: In-place upgrade on three DCs in my "production lab" from 2022 to 2025. This is a domain that was originally built on 2008 R2 and either migrated or upgraded from 2008 --> 2012 --> 2016 --> 2019 --> 2022 --> and now 2025. This means GPOs implemented in 2008 (R2) were still in place. Upgraded items: Three DCs moved to 2025. Raised forest function level. Raised domain function level. Extended schema for new LAPS recovery method. Added Windows 11 24H2 ADMX templates to Central Store. Issue 1: File transfers via network copy or in RDP sessions from jumphosts to the PDC emulator (DomainController01) would hang and fail. Updating GPOs from jumphosts via GPMC to DomainController01 would hang but ultimately succeed. Transfers, updates, and other tasks between DomainController01 and 02/03 would work fine. Repadmin showed no issues and test files or dummy files placed in the local SYSVOL folder on each domain controller would replicate instantly. Issue 2: Network state is in "private" mode and not domain mode. Appears to be a common problem from many server versions back, but this is the first time it bit me. Added Windows firewall rules for private connections using domain subnets. Issue 3: Maybe cosmetic only, but forest and domain function levels show "Unknown", but I confirmed the forest and domain functions levels via PowerShell are listed as level 10. Issue 4: Domain clients started dropping off the domain only after the upgrade to 2025 and the new LAPS recovery method was implemented. Workaround was to log in as local admin, disconnect from domain, wait about 60 seconds, rejoin to the domain, and reboot. For a production lab of about 30 machines using a MDM solution, this wasn't terrible. Issue 5: LAPS passwords displayed in the LAPS tool were out of sync with the password on the local client and what was shown via PowerShell. What I found this morning: When I opened ADAC, I received a popup stating "Active Directory Administrative Center cannot restore the custom configuration settings. The default configuration settings will be used." I clicked the OK button and went into the only custom setting I had which was a password length and complexity settings specifying 16 characters. The legacy GPO would only support 14 although in 2019 (or 2022, can't remember) another policy was added in the legacy GPO to allow more than 14. Regardless, I had conflicting password length and complexity settings and ADAC restored the default. I set this ADAC password policy back to what I had prior to the error, set the legacy GPO to not configured if set in ADAC, and ADAC was happy. I found other conflicting GPOs carried over from the 2008 R2 days including registry modifications for HTTP Auto Proxy, ciphers, etc. I went line-by-line through each of the security GPOs (three in total) and removed conflicting items or old items. One of the awesome things I started back in 2016 was adding a version number and date to the properties of each GPO and labeling each GPO with a version number in the name. I went to my notes and found the old settings. Setting rollbacks today in bold font are the new settings as of this morning: 1) Microsoft Network Client: send unencrypted passwords to third-party SMB servers: disabled; 2) Microsoft network server: disconnect clients when logon hours expire: disabled; 3) Network access: allow anonymous SID/Name translation: disabled; 4) Do not allow enumeration of SAM accounts and do not allow enumeration of SAM accounts shares: enabled; 5) ADMX LAPS under Admin Templates LAPS: set all policies to not configured and configured the new LAPS under Admin Templates --> System --> LAPS. It's only been a few hours, but like I mentioned above file transfers to the PDC emulator work fine and don't error out. Managing GPOs via GPMC from jumphosts work fine now. ADAC isn't erroring out. LAPS passwords checked from about a dozen machines are all in sync now.