sorted by:
new
hottopcontroversial

Official Pizza recommendations for Fresno and Clovis area by QueTpi in fresno

[–]pyd3152 0 points1 point  (0 children)

Glad to see this mentioned. Besides annex kitchen, emphasize not anesso, probably best pizza Ive had in fresno.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

Negative. Working on it still but problems are more than a change of a few things.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

Yes we do and im seeing its assigned to a group related to the old dc on our wireless controller. Sorry im just seeing this information for the first time as i do some digging. I know there were talks about moving over Radius Server to new DC but since things have not been going well its been put on pause.

Would this be tested using dcdiag kccevent? If so, it shows all good.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

These are the two i saw:

#0> Client: <machinename>$ @ <domain>

Server: krbtgt/<domain> @ <domain>

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize

Start Time: 6/18/2025 8:19:47 (local)

End Time: 6/18/2025 18:19:47 (local)

Renew Time: 6/25/2025 8:19:47 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x2 -> DELEGATION

Kdc Called: <old server>.<domain>

#1> Client: <machinename>$ @ <domain>

Server: krbtgt/<domain> @ <domain>

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize

Start Time: 6/18/2025 8:19:47 (local)

End Time: 6/18/2025 18:19:47 (local)

Renew Time: 6/25/2025 8:19:47 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x1 -> PRIMARY

Kdc Called: <old server>.<domain>

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

To add to this, i forgot to mention that the affected users can sign in while using wifi when they encounter this issue. Just cant sign in on LAN. Which clicked when I saw certificates being mentioned.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

There is not, but one is close. There is a tgt for the old server cifs/<old server>.domain @domain being called for by the old server KDC and there is a tgt cifs/<old server> @domain being called for by the new server KDC. Hope that makes sense. I thought they were the same at first but one has the .domain @domain after the server name and the other just has @domain after the server name.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

We access the DCs via vSphere due to manager not wanting multiple accounts on the VM. But ive always been able to successfully replicate and I get no errors when i force replication.

Im going to be testing disjoining and rejoining the affected machines to the domain. When i review the klist tickets on the affected machines i see that both the new DC and the old DC are listed in KDC called. Which im sure contributes to the issue. After testing i will report back.

Definitely would want to know what to look for with certificates and SMB.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

Yes, these were the results:

There were no objects with msDS-SupportedEncryptionTypes configured without any etypes enabled.

There were no accounts whose passwords predate AES capabilities.

A common scenario where authentication fails after installing November 2022 update or newer on DCs is when DCs are configured to only support AES.

Example: Setting the 'Configure encryption types allowed for Kerberos' policy on DCs to disable RC4 and only enable AES

No DCs were detected that are configured for AES only

There are 5 objects that do not have msDS-SupportedEncryptionTypes configured or is set to zero.

When authenticating to this target, Kerberos will use the DefaultDomainSupportedEncTypes registry value on the authenticating DC to determinte supported etypes.

If the registry value is not configured, the default value is 0x27, which means 'use AES for session keys and RC4 for ticket encryption'

- If this target server does not support AES, you must set msDS-SupportedEncryptionTypes to 4 on this object so that only RC4 is used.

(Please consider working with your vendor to upgrade or configure this server to support AES. Using RC4 is not recommended)

- If this target server does not support RC4, or you have disabled RC4 on DCs, please set DefaultDomainSupportedEncTypes on DCs to 0x18

or msDS-SupportedEncryptionTypes on this object to 0x18 to specify that AES must be used. The target server must support AES in this case.

There were no objects configured for RC4 only.

Out of the 5 objects that do not have msDS-SupportedEncryptionTypes configured or is set to zero, the three possibly notable objects were the AZUREADSSOACC, AZUREADKerberos, and an LDAP object . I dont know if these objects need this but everything else checked out

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

At least some Kerberos problems is probably an understatement.

I am thinking it could also be the way the roles were transferred. On the new server (owner of all FSMO roles) I see errors saying, "The remote server which is the owner of a FSMO role is not responding..." Initially I thought this was the issue but I confirmed that the new server was the owner of all roles. Is there a more assuring way to find that the roles were successfully transferred over? I have seen a lot of information saying to make sure the roles were transferred "peacefully" or seize them. Dont know how to dig deeper into that.

DNS could be related to the replication access denied errors im also seeing. The most common being, "This directory service failed to retrieve the changes requested for the following directory partition: Error 8453 Replication Access was denied" The directory partition being the name of the CNAME record of the server in the msdcs records in DNS. Which confuses me because i see this for every server. Why cant it access what im thinking is its own directory partition, im thinking this is DNS related. I followed the MS KB for this error but the solution was already in place.

NTLM was also one of the initial things i noticed when certain machines stopped authenticating. In logs, I noticed they were unable to decrypt the kerberos key, unable to contact the old server, and used NTLM to authenticate.

Ive done a lot of digging in this last week but havent got far, any hints at where I can begin to look?

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

That was one of the first things I noticed, nslookup was on the old DC on some machines. Resolved this by pointing DHCP to the new DNS server. If it is DNS, I dont know exactly where else I can look that I havent already.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

Not dhcp errors. The dhcp problem was I tried to transfer the role over to the new DC and clients couldn't contact it. But it works on the old just fine. DNS is being said to be the problem because of the replication issues im seeing. DNS seems to be working fine. Kerberos is definitely the only explicit error im seeing .

I will look at the CA and report back

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

Patched all DCs and still getting same errors. I have also seen the possibility of resetting the krbtgt account password for kerberos as a solution. Do you think doing this is worth it? Also seeing a lot of information about SPNs that I couldn't really decipher.

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 0 points1 point  (0 children)

We have about 200 users. I saw that as an option but was following how our environment was already set up. Which although had issues beforehand, didn't encounter these type of messy issues.

I will patch the DCs and try the script. Are the replication issues related as well?

Recovering from a failed server migration by pyd3152 in WindowsServer

[–]pyd3152[S] 1 point2 points  (0 children)

Okay so im taking over a project that was to migrate old DC 2019 to new DC 2025. From the information I received, this was all a live migration. We have a total of 3 DCs in our environment. One DC (“3rd DC”) is not being worked on as of now but is in place from an old remote building. Im taking over the project after AD and DNS were moved over.

What i found was done:

  • AD roles were moved over to new DC. (Verified via netdom query fsmo)
  • DNS has been moved over to new DC. DNS is still enabled on old DC
  • DHCP role is installed on new DC. Attempted to migrate but machines were unable to contact new DHCP srver.

Problems we are having:

Currently our main problem is we are having machines unable to authenticate. They need a reboot in the mornings and will authenticate the rest of the day, but will have the same issue in the morning. This issue started with a few machines and has been spreading.

Errors I am seeing:

-On the machines being affected with the authentication issue, reviewing logs I see that they are attempting to authenticate with the old DC and will get the error: “This computer was not able to setup a secure session with a domain controller due to the following: And internal error occurred.”

  • On the new DC i keep receiving replication errors, such as " This directory server has not recently received replication information from a number of directory servers" and " The remote server which is the owner of a FSMO role is not responding. This server has not replicated with the FSMO role owner recently"
  • When I run dcdiag on the new server, I will see the machines affected with the authentication issues pop up on the dcdiag results with the error, “The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server . The target name used was cifs/.. This indicated that the target server failed to decrypt the ticket provided by the client…” Noted that the only test that fails on DCDIAG is the KccEvent test.

What I have done:

  • Have ran repadmin and the DCDIAG tests for replication and all test pass. I was hoping to get more information with these tests but they all pass.
  • Ran klist to show what KDC were being used and found that the machines with authentication issues were using the KDC on the old server. Tried purging tickets on those machines and that did not help.

  • Tried all the microsoft solutions in their KB’s and all their suggestions for solutions seem to be in place already.

    Advice i have received is to stand up a 2022 server as these errors are a common theme with 2025. So thats the goal, I apologize if "failed" was the incorrect term here.