Kris Lou
2021-Dec-17 19:27 UTC
[Samba] Windows Clients (10-1909 + 2012R2) not purging Machine Account tickets after auto-renew?
Happy Friday -- I recently (last week) pushed my DC's up to 4.14.10, and since then, I've had a handful of machines with broken secure channels to the DC's. Basically, they present as no longer joined to the domain (can't authenticate, no domain-access, etc.), but that doesn't seem to be the case. It seems that this only occurs AFTER the client automatically renewed their machine account password -- so I've got to get this figured out before the next batch hits. smbclient -L <client> -U <user> results in: gse_get_client_auth_token: gss_init_sec_context failed with [ Miscellaneous> failure (see text): Message stream modified](2529638953) > gensec_spnego_client_negTokenTarg_step: SPNEGO(gse_krb5) login failed: > NT_STATUS_LOGON_FAILURE > session setup failed: NT_STATUS_LOGON_FAILUREWindows logs - Security-Kerberos The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server> <client>$. The target name used was <CLIENT>$. This indicates that the > target server failed to decrypt the ticket provided by the client. This can > occur when the target server principal name (SPN) is registered on an > account other than the account the target service is using. Ensure that the > target SPN is only registered on the account used by the server. This error > can also happen if the target service account password is different than > what is configured on the Kerberos Key Distribution Center for that target > service. Ensure that the service on the server and the KDC are both > configured to use the same password. If the server name is not fully > qualified, and the target domain (SAMDOM.TLD) is different from the client > domain (SAMDOM.TLD), check if there are identically named server accounts > in these two domains, or use the fully-qualified name to identify the > server.However, a manual domain-leave/rejoin or "powershell Reset-ComputerMachinePassword" + reboot seems to fix this. So, from above I'm guessing that the machine account tickets are not getting automatically purged or renewed after it refreshes? But manually triggering it seems to work -- after purging the cache with a reboot. Any suggestions regarding this? Thanks. Barebones smb.conf, omitting stuff I have commented out: # Global parameters [global] workgroup = SAMDOM realm = samdom.tld netbios name = <DC> server role = active directory domain controller server services = -dns ntp signd socket directory = /var/lib/samba/ntp_signd ntlm auth = mschapv2-and-ntlmv2-only # Logging log level = 2 log file = /var/log/samba/samba4.log.%m hostname lookups = yes # This needs to be addressed soon ldap server require strong auth = no # Certificates tls keyfile = /var/lib/samba/private/tls/privkey.pem tls certfile = /var/lib/samba/private/tls/fullchain.pem tls cafile = /var/lib/samba/private/tls/chain.pem # Disable Printing load printers = no disable spoolss = yes printing = bsd printcap name = /dev/null # Enable Extended ACL Support map acl inherit = yes store dos attributes = yes # Winbindd parameters template shell = /bin/bash template homedir = /home/%U Kris Lou klou at themusiclink.net
Kris Lou
2022-Jan-10 17:31 UTC
[Samba] Windows Clients (10-1909 + 2012R2) not purging Machine Account tickets after auto-renew?
For sake of closure (I hope, but we'll see in another 2-3 weeks) the (probably) most relevant part of this was that I upgraded the domain functionality level from 2003 to 2008_R2. If accurate, then this link explains most of it: https://docs.microsoft.com/en-us/archive/blogs/askds/it-turns-out-that-weird-things-can-happen-when-you-mix-windows-server-2003-and-windows-server-2012-r2-domain-controllers The Kerberos client depends on a ?salt? from the KDC in order to create the> AES keys on the client side. These AES keys are used to hash the password > that the user enters on the client, and protect it in transit over the wire > so that it can?t be intercepted and decrypted. The ?salt? refers to > information that is fed into the algorithm used to generate the keys, so > that the KDC is able to verify the password hash and issue tickets to the > user. > When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 > DCs are present, there is a mismatch in the encryption types that are > supported on the KDCs and used for salting. Windows Server 2003 DCs do not > support AES and Windows Server 2012 R2 DCs don?t support DES for salting.Substitute 2008_R2 for 2012 R2, and it seems to match up. Hopefully nobody else is still running at domain functionality level 2003 ... Kris Lou klou at themusiclink.net On Fri, Dec 17, 2021 at 11:27 AM Kris Lou <klou at themusiclink.net> wrote:> Happy Friday -- > > I recently (last week) pushed my DC's up to 4.14.10, and since then, I've > had a handful of machines with broken secure channels to the DC's. > Basically, they present as no longer joined to the domain (can't > authenticate, no domain-access, etc.), but that doesn't seem to be the > case. > > It seems that this only occurs AFTER the client automatically renewed > their machine account password -- so I've got to get this figured out > before the next batch hits. > > smbclient -L <client> -U <user> results in: > > gse_get_client_auth_token: gss_init_sec_context failed with [ >> Miscellaneous failure (see text): Message stream modified](2529638953) >> gensec_spnego_client_negTokenTarg_step: SPNEGO(gse_krb5) login failed: >> NT_STATUS_LOGON_FAILURE >> session setup failed: NT_STATUS_LOGON_FAILURE > > > Windows logs - Security-Kerberos > > The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server >> <client>$. The target name used was <CLIENT>$. This indicates that the >> target server failed to decrypt the ticket provided by the client. This can >> occur when the target server principal name (SPN) is registered on an >> account other than the account the target service is using. Ensure that the >> target SPN is only registered on the account used by the server. This error >> can also happen if the target service account password is different than >> what is configured on the Kerberos Key Distribution Center for that target >> service. Ensure that the service on the server and the KDC are both >> configured to use the same password. If the server name is not fully >> qualified, and the target domain (SAMDOM.TLD) is different from the client >> domain (SAMDOM.TLD), check if there are identically named server accounts >> in these two domains, or use the fully-qualified name to identify the >> server. > > > However, a manual domain-leave/rejoin or "powershell > Reset-ComputerMachinePassword" + reboot seems to fix this. > > So, from above I'm guessing that the machine account tickets are not > getting automatically purged or renewed after it refreshes? But manually > triggering it seems to work -- after purging the cache with a reboot. > > Any suggestions regarding this? Thanks. > > Barebones smb.conf, omitting stuff I have commented out: > > # Global parameters > [global] > workgroup = SAMDOM > realm = samdom.tld > netbios name = <DC> > server role = active directory domain controller > server services = -dns > > ntp signd socket directory = /var/lib/samba/ntp_signd > ntlm auth = mschapv2-and-ntlmv2-only > > # Logging > log level = 2 > log file = /var/log/samba/samba4.log.%m > hostname lookups = yes > > # This needs to be addressed soon > ldap server require strong auth = no > > # Certificates > tls keyfile = /var/lib/samba/private/tls/privkey.pem > tls certfile = /var/lib/samba/private/tls/fullchain.pem > tls cafile = /var/lib/samba/private/tls/chain.pem > > # Disable Printing > load printers = no > disable spoolss = yes > printing = bsd > printcap name = /dev/null > > # Enable Extended ACL Support > map acl inherit = yes > store dos attributes = yes > > # Winbindd parameters > template shell = /bin/bash > template homedir = /home/%U > > > > Kris Lou > klou at themusiclink.net >