ICT_GUY

Another piece to the puzzel. So my work machine even after all the other fixes started to play up again with random wrong password. Removing it from the domain and now it works fine. So my thoughts are that it is to do with machine keys on the server being wrong. Perhaps when the server were not syncing. Who the hell knows. 😞 Also server 2025 will not let the rm ad sync to run, at least last time I tried to install it would randomly reboot every 5 minutes.

One of the things that came up was that although AES was enabled in the Kerberos encryption-type policy, klist was still showing RC4 service tickets Reset-ComputerMachinePassword -Server on my server 2022 DC pointing at my new server 2025 server. regenerated the correct keys and now klist shows aes is being used. Fun times.

I had to apply that tou our clients as well as the servers. Basicaly so they all agree on what encryption is acceptable.

Network security: Configure encryption types allowed for Kerberos Under computer config, windows settings, security settings, local policies/security options

I did have to put that gpo back onto the DC and BDC to inforce acceptable encryption between themselves and clients. Though the two issues I had were constant wrong password errors for users and replication failing between dcs. This was fixed with setting acceptable network encyption in group policy. Our set up was different in that one dc was server 2022. So they would sometimes be able to login and sometimes not. Using echo %logonserver% from a command prompt showed which DC was actually accepting authentication. So even when they had the correct password it would tell the user it was wrong. Rebooting theclient until the working DC responded worked.

Digging even further, removing the gpo to enforce which encryption to use put me back in the random password is incorrect issues. This is due to clients not being able to talk to the login server. So putting a GP onto the computer OU only to enforce the same settigns seems to have fixed that. My best guess is that when an update breaks AD syncing, then the GP that enforces authentication breaks so isn't applied to one of the servers. It then defaults back to another encrption type. By setting the encrption types as a local policy on each DC that should make it permanent. Fingers crossed things are working at the moment, don't tell microsoft or they will patch that for sure.

Well that was a rabit hole. The fix was to remove a group policy that set AES encyption on the domain controllers and Computers Then on each DC run secpol.msc and did the following. On the servers local security policy Network security configure encryption types for kereros and tick RC4_HMAC_MD5 and AES 128 and 256. The replication and group policy started working again. Clients are now happy no matter which DC they logon to or talk to. So much Fun!

I am thinking of removing AD from the BDC 2025 server and just use it as a file server for the moment. I have an older Server that I was using as a media server running server 2022 that I will promote back to a BDC. The specific error is that on some reboot clients can log in but not update group policy. Not all the time either, only some times. That error is that the domain controller is unavailiable. However dns works, permissions work for shares. Now server 2022 worked just fine before, the problems only started when I threw a new server 2025 into the mix. I will trouble shoot today again and then if I can't fix it I will be pulling the plug on having ad on server 2025.

Secure channel between the two dcs broke again. At the moment the choice is demote the 2025 machine, or keep fixing secure channel every few months. Great.

And I have server not working properly again. This time clients randomly it seems can't pull down group policies, it seems to have broken with a recent windows update. Some times the clients do work, sometimes they don't. Server 2025 isn't playing well with server 2022. When the logon server is the 2025 it seems to work, if it is the server 2022 server it breaks. Great fun all round TBH.

So what seemed to work in simple terms. Fixed time sync. Fixed the AD sync issues between the two servers. The GPO to force the right authentication across the domain. Then run a script to update all old computer and user accounts. So far it has worked. Obviously there a lot more to it, but that is the simple break down of what worked for me.

I did have to make sure time was syncing to a reliable source and the whole network was pointed at the PDC for time. If a reboot on the client sometimes fixes the issue thats what confirmed to me that it was an authentication issue. basically if it talked to the right server it would authenticate, if it talked to the other one it would give the wrong password error. In short I had to make sure all accounts were set to use the correct authentication, that was by using a powershell script. It was something to do with acconts created on server 2022 or earlier would have the inncorrect settings. The script reset these older accounts. Computer and user. If your group policies are set up correctly you should be able to set up a new test pc and a test account and that should work every time. As long as the servers are set to use the correct authntication protocol. It was a complete ball ache to be fair and I only fixed by leaning heavily into trouble shooting with chatgpt. In simple terms windows 11 and server 2025 default to the more secure authentication and throw a fit if either client or server uses a less secure method. Again it was one of those problems that was so far outside of anything I had ever trouble shooted before I still don't quite know exactly all of the process.

Well a server update might be to blame for most of my issues. https://www.bleepingcomputer.com/news/microsoft/microsoft-september-2025-windows-server-updates-cause-active-directory-issues/

This is where it gets tricky. I can only say what I did, and to be fair it was not a fun experience. I would use what I put as a place to start your research. I would say I think the issue was something along the lines of if the clients were talking to the 2022 server they worked if they authenticated to the 2025 server it just gave wrong passsword error. The group policy should fix it, it might take a couple of restarts. But again I am unsure why my two servers started not talking to each other. I was very close to removing the 2025 server as a BDC.

Excellent, not sure what went wrong on my network but it has been a lesson in why you never trust new ms products to be tested before deployment.

This is Generated as a summary from my trouble shooting. It is A.I. generated so use it as a guide. I would reccomend checking everything, more over use chatgpt 5 to trouble shoot with you. My servers had trust issues and wouldn't talk to each other. Fixing the machine password is what eventually fixed the issue. It was a long and involved troule shooting process on a live but broken system. Now my servers are replicating. Rebooting clients is a must after the fix. More over this is a sumary of what i did. Do not rely on it as a fix. Fix the secure channel between PDC and BDC (Domain Controllers) Who this is for: Any AD with at least two DCs (call them PDCNAME and BDCNAME) in domain CONTOSO.local. Run all commands elevated. Replace placeholders with real names. 0) Quick verification (both DCs) On each DC: nltest /sc_verify:CONTOSO.local NERR_Success = secure channel OK Anything else = repair that DC (start with the non-PDC DC) 1) Repair the non-PDC DC (BDCNAME) Do this on BDCNAME using a Domain Admin account (CONTOSO\DAUSER). Make sure Netlogon is running: sc query netlogon | find "RUNNING" || powershell -command "Start-Service Netlogon" Reset BDC’s machine account password (local secure-channel secret): runas /netonly /user:CONTOSO\DAUSER cmd netdom resetpwd /server:BDCNAME /userD:CONTOSO\DAUSER /passwordD:* /SecurePasswordPrompt Bounce auth services & clear Kerberos tickets: powershell -command "Restart-Service kdc -Force; Restart-Service netlogon -Force" klist purge Verify: nltest /sc_verify:CONTOSO.local You want: NERR_Success. 2) Cross-align from the PDC (recommended) Do this on PDCNAME (PowerShell), still as CONTOSO\DAUSER. $cred = Get-Credential CONTOSO\DAUSER Reset-ComputerMachinePassword -Server BDCNAME.CONTOSO.local -Credential $cred Restart-Service kdc -Force Restart-Service netlogon -Force 3) Replication sanity From either DC: repadmin /syncall /AdeP repadmin /replsummary repadmin /showrepl PDCNAME repadmin /showrepl BDCNAME Good = 0 fails and recent “Last success” on all partitions. 4) If repair won’t stick (fast checks) On the problem DC: DNS client points to DCs (not public DNS): Preferred DNS = the other DC’s IP Alternate DNS = 127.0.0.1 (or its own IP) Time in sync (skew < 5 minutes): w32tm /resync /force Ports reachable to partner DC: 88, 135, 389, 445, 464 (and 3268/3269 if GC). Test-NetConnection PARTNERNAME -Port 135 Netlogon/KDC running: sc query netlogon & sc query kdc No duplicate SPNs: setspn -X 5) One-liner summary for a teammate On the BDC, start Netlogon → netdom resetpwd /server:BDCNAME /userD:CONTOSO\DAUSER /passwordD:* /SecurePasswordPrompt → restart KDC/Netlogon → nltest /sc_verify:CONTOSO.local. (Optionally from the PDC, run Reset-ComputerMachinePassword -Server BDCNAME... and restart services.) Finish with repadmin /syncall and confirm 0 fails. That’s it. This fixes 99% of PDC↔BDC secure channel issues and gets replication moving again.

I have fixed mine now, secure channel was broken between the two domain controllers. Well that was fun 🙂 I think it was to do with applying the Gpo to the domain controllers. Something went wrong. Restting the machine pa Though I had issues with time sync, differening encryption level defaults with 2025 and 2022. Fingers crossed they are now talking to each other as they should have been.

Also check your ad replication. My two servers at the moment are not agreeing on which protocol to use to talk to each other. My server 2022 PDC and the server 2025 BDC are not syncing and it is causing a lot of issues. Now If i fix that this morning I will post what I did to fix it. At the mopment I am around 1 hours trouble shooting away from removing the ad role from 2025 completely. Also the RM ADSYNC applications were casing server 2025 to spontaneously reboot constantly. All in all remvoing the BDC role is probably where I will end up if I keep having issues.

Like I said the A.I. isn't the best at getting things right first time. I did just ask it for a brief summary of around 2 to 3 hours trouble shooting. It messes up code like a champ. Thanks for spotting it.

This is the paid for chat gpt generated summary. With all such summarys it is not gospel but has all the info you need to trouble shoot it. I also made the 2022 server the PDC. The issues were with old accounts using out dated security. Root Cause Server 2025 enforces stricter Kerberos encryption policies by default. Older accounts (both users and computers) were still configured to allow RC4-HMAC or had no explicit encryption types set, so when authentication requests hit the 2025 DC, the tickets were rejected. The 2022 DC was still accepting them, which made the issue appear intermittent depending on which DC answered the request. 🧠 Diagnosis Using PowerShell, we listed accounts with missing or legacy encryption flags: Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq $null -or $_.msDS-SupportedEncryptionTypes -eq 0 } | Select Name, SamAccountName and similarly for computers: Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.msDS-SupportedEncryptionTypes -eq 28 } | Select Name, DNSHostName Accounts showing null, 0, or 28 were allowing RC4 or falling back to defaults. 🔧 Fix Set all accounts to AES-only: # For users Get-ADUser -Filter * | ForEach-Object { Set-ADUser $_ -Replace @{msDS-SupportedEncryptionTypes = 24} } # For computers Get-ADComputer -Filter * | ForEach-Object { Set-ADComputer $_ -Replace @{msDS-SupportedEncryptionTypes = 24} } (24 = AES128 + AES256 only) Create a GPO to enforce AES encryption: Path: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options Setting: Network security: Configure encryption types allowed for Kerberos Tick only AES128_HMAC_SHA1 and AES256_HMAC_SHA1. Link at the domain root. Run gpupdate /force and reboot test clients. ✅ Result After aligning all accounts and the GPO, authentication succeeded cleanly on both 2022 and 2025 DCs. Event ID 4769 (Kerberos Service Ticket) now shows encryption 0x11 (AES128) or 0x12 (AES256) — no more RC4 (0x17) tickets. 🧰 TL;DR Server 2025 won’t tolerate legacy Kerberos encryption. Clean up account encryption flags to AES only (24). Apply the AES-only GPO domain-wide. Verify via Event ID 4769 that all tickets use AES.

I fixed the authentication issue. It would randonly work and fail. I had a 2022 server as bdc and a 2025 PDC. Server 2025 enforces stricter Kerberos encryption policies by default. Older accounts (both users and computers) were still configured to allow RC4-HMAC or had no explicit encryption types set, so when authentication requests hit the 2025 DC, the tickets were rejected. The 2022 DC was still accepting them, which made the issue appear intermittent depending on which DC answered the request. Setting all accounts to AES for PCs and Users fixed the issues.

In my schools we havearound 40 boards. The older promethean ones, the ones that must weigh 70kgs or more. No lie two of struggle to move them. seem to have lasted 10 years with only a acouple of issues. Though they are definitely on their last legs. The new promethean boards last 5 years before the back light fails. We have tried to get someone to fix them but no joy, our local TV repair shop doesn't want to know. The main issue is that to cut prices they are not putting the same quaility displays in there. However the original boards cost £3k 10 years ago, the new ones £1k now. So all in all even though they don't last as long they are still much better value. They are also 4k displays.

What you will find is that the IR leds have a life span and teachers unless properly trained normally refuse to turn the boards off when they are not being used, so they are on all through the school day, lunch times, break times, after school. I find they tend to burn out around the 8 year mark. You can check for this using your phone camera. The phone camera has a sensor, I also made an ir led tester a while back. Just a ir sensor, transistor and a led that lights when the sensor detects IR. We use prometheran boards. Keep in mind though that the latest generation have a 5 year warranty and the back light lasts 5 years and a few months. Only £1000 for the board though. So £200 per year running costs. They also come with an android pc of sorts if that floats your boat. All of our teachers prefere teaching at the board for some things, at their pc for others.

I have only briefly looked over the requirements. Anyhow. We use RM safetynet which is looking more and more antiquated as time goes on. Yes it does a good job of filtering. However the alert system is a hell of a mess. As an example, if you include pornography on the alerts you get bombarded with false alerts due to ad farms being on the list. So either you don't monitor for pornography or you spend your entire day sifting through false positives. Hardly what you want either way. So my question is, what are other primary schools using, what do you recommend, and what sort of costs and setup am I looking at?

And I am having the exact same issue :-/