Can't join active directory after updating to windows server 2025

changed the description

I can reproduce this issue and also confirmed with Microsoft AD team (of which I used to belong). Two significant changes in WS2025 that might be in play here:

RC4 Kerberos is disabled from use in a new domain
Computers can no longer join domain with a password of the computer name.

It seems like "message stream modified" might the same as "KRB_AP_ERR_MODIFIED", which suggests the RC4 issue.

This same version of adcli/sssd/realmd works fine on my ubuntu 24 machine when joining Windows Server 2022 domain DC's and Windows Server 2019 domain DC's, the only difference in my tests is WS2025 DCs.

Hi @Yaya48,

referring to @nedpyle's comment, is RC4 still enabled for Kerberos on Ubuntu? Can you run adcli as

KRB5_TRACE=/dev/stdout /usr/sbin/adcli join --verbose --domain XXX.lan --domain-realm XXX.LAN --domain-controller 192.168.5.6 --login-type user --login-user XXX

and send the (sanitizted) output?

I'll try to setup WS2025 to reproduce the issue.

bye, Sumit

Hi, i'm doing those test on a debian 12 ( stable ) machine

https://pastebin.com/raw/fsAqSPpt here's the log of adcli running

Judging by the trace, it fails within a password change, e.g. in Kerberos code:


[2498] 1733796479.200476: Creating authenticator for admin@DOMAIN.LAN -> kadmin/changepw@DOMAIN.LAN, seqnum 0, subkey aes256-cts/47BF, session key aes256-cts/F928
[2498] 1733796479.200478: Resolving hostname 192.168.5.6
[2498] 1733796479.200479: Initiating TCP connection to stream 192.168.5.6:464
[2498] 1733796479.200480: Sending TCP request to stream 192.168.5.6:464
[2498] 1733796479.200481: Received answer (95 bytes) from stream 192.168.5.6:464
[2498] 1733796479.200482: Terminating TCP connection to stream 192.168.5.6:464
 ! Couldn't set password for computer account: DEBIAN$: Message stream modified
adcli: joining domain DOMAIN.lan failed: Couldn't set password for computer account: DEBIAN$: Message stream modified

Can you collect a tcpdump of this communication? I wonder if we get something new in response and MIT Kerberos processing of the change password response is tripped up.

Hi,got you the dump adcli.pcap

Thanks. So packet 78 is a response from AD DC providing us with a TGS-REP with a ticket to kadmin/changepw, as requested. Looks like something within the packet is breaking logic in MIT Kerberos. In order to decrypt the packet's content, we need a keytab of the key for admin_temp user. I can generate one based on a password you used, so if this was a throw-away account, you might want to share it with me.

Otherwise, you can generate it yourself and provide a keytab:

$ ktutil
ktutil: addent -password -p admin_temp@23RDB.LAN -k 2 -e aes256-sha1 -s 23RDB.LANadmin_temp
Password for admin_temp@23RDB.LAN:
ktutil:  l -k -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2                     admin_temp@23RDB.LAN (aes256-cts-hmac-sha1-96)  (0x36c7ad7bf609a70d7e09a5118742a4401e40c1b7a2ef8ff5b2e866ddb9f2bc3c)
ktutil: wkt admin_temp.keytab
ktutil: quit

Since I don't know a password, I used 'Secret123' above for example, so the key value is wrong for decryption purposes but just demonstrates how you create a keytab.

Hi,

can you add the corresponding adcli debug output as well. I'm asking because the debug logs you have snet show that adcli is already talking with the kadm/kpasswd port 464 while this is not covered in the network trace.

bye, Sumit

Hi,

here is a capture I got during testing: join.cap

To me it looks like AD is returning an error in packet 106. I used 'Secret123' as password here.

bye, Sumit

From RFC 3244:

   The server will respond with a KRB-PRIV message unless it cannot
   decode the client AP-REQ or KRB-PRIV message, in which case it will
   respond with a KRB-ERROR message.  NOTE: Unlike change password
   version 1, the KRB-ERROR message will be sent back without any
   encapsulation.
...
   The user-data component of the KRB-PRIV message, or e-data component
   of the KRB-ERROR message, consists of the following data.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          result code          |        result string          /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   result code (16 bits) (result codes 0-4 are from the original change
   password protocol):

      The result code must have one of the following values
      (big-endian integer):

      KRB5_KPASSWD_SUCCESS             0 request succeeds (This value
                                         is not allowed in a KRB-ERROR
                                         message)

We get edata equal to 0x0000 in the packet 106, so it is actually saying KRB5_KPASSWD_SUCCESS which is not allowed in the KRB-ERROR message.

Hi,

I wondered about this as well since it looks like there is no real error described in the reply.

I try to set a user password with adcli passwd-user which is using the same libkrb5 call krb5_set_password_using_ccache() as adcli join. I got the same Message stream modified error but the password was actually changed. So I assume that the operation really was successful.

Now the questions is, can this be fixed in AD (@nedpyle do you know where we can ask) or do we have to talk the MIT Kerberos upstream to make an exception for this no-error error message?

bye, Sumit

I have submitted a request to Microsoft's Dochelp team to clarify the behaviour (or a change in specification). You can follow the discussion at https://lists.samba.org/archive/cifs-protocol/2024-December/004390.html

I have received a confirmation from Steve Syfuhs that it is indeed a regression in Windows Server 2025:

https://hachyderm.io/@SteveSyfuhs/113652185587416636

yeah it's a bug on our end. Spec is right. We're fixing the bug. Our crypto agility overhaul to include sha256/384 introduced it. Amazingly we even have a test for this exact thing...that mocked out the relevant response check. Oops.

Greetings, has there been any update on this situation within the last 3 weeks?

I'm getting the exact same issue on RL9.5...

It is a bug in Microsoft implementation of Kerberos in Windows Server 2025. They are working on the fix but we have no details on the current state.

January CU patch did not solve the issue. We use the workaround (adcli command): --ldap-passwd --use-ldaps in order to domain join new machines, or trust-dropped machines. We also set machine password rotation to 120d via sssd.conf, hopefully a CU fix will be released.

Note: realm command does not wrap --ldap-passwd --use-ldaps adcli options

I get "unknown option" for --ldap-passwd when I use in my realm join. I'm currently running the latest versions of everything in Alma 9.5. Could you tell me if my syntax is incorrect somewhere?

# realm join --ldap-passwd --use-ldaps --user=userguy domain.local --verbose

realm: Unknown option --ldap-passwd Please check https://red.ht/support_rhel_ad to get help for common issues.

Thanks!

I encountered this issue as well. The realm command essentially wraps around adcli or Samba tools, but it doesn't expose the LDAP-related password set. You can join the domain using adcli (which will only provide you with a krb5 keytab), and then modify sssd.conf (along with other files like nsswitch.conf and pam.d).

I'll give that a go. Thank you for replying!

The earliest a patch would come for this would be the February CU, and March is more likely tbh.

Can't join active directory after updating to windows server 2025

Designs

Child items ...

Activity

Admin message

Admin message

Can't join active directory after updating to windows server 2025

Activity