Problem: GPOs are not applied

Knowledge Base Community
, , ,
#1

Problem:

Windows Client shows:

C:\Users\Administrator>gpupdate /force
Updating policy…

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
User Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Investigation:

samba-tool gpo list windows
GPOs for user windows
    Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}

Check if the Container is linked and the computer is below this path.

samba-tool gpo listcontainers {31B2F340-016D-11D2-945F-00C04FB984F9}
Container(s) using GPO {31B2F340-016D-11D2-945F-00C04FB984F9}
    DN: DC=schein,DC=me

Check, if the sysvol share can be accessed:
In windows use the explorer \\FQDN\sysvol → FQDn should be replaced with the fqdn of the server. You should the %logonserver% you get from the cmd.

Check dns:
dig ucs-new.schein.me
;; ANSWER SECTION:
ucs-new.schein.me. 900 IN CNAME ucs.schein.me.
ucs.schein.me. 900 IN A 10.200.43.32

dig ucs.schein.me
;; ANSWER SECTION:
ucs.schein.me. 900 IN A 10.200.43.32

This might be a relict from backup2master. But this state could cause trouble:

Logfile anylysis:

[2024/07/23 14:27:13.418601,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: Server not found in database: ldap/ucs.schein.me/schein.me@SCHEIN.ME: no such entry found in hdb
+[2024/07/23 14:27:13.418627,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: heim_audit_vaddreason(): adding reason Service principal unknown
+[2024/07/23 14:27:13.418650,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: Failed building TGS-REP to ipv4:10.0.255.6:63375
+[2024/07/23 14:27:13.418679,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: tgs-req: sending error: -1765328377 to client
+[2024/07/23 14:27:13.418699,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: Making non-FAST KRB-ERROR
+[2024/07/23 14:27:13.418777,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: heim_audit_vaddkv(): kv pair[0] elapsed=0.005813
+[2024/07/23 14:27:13.418801,  3, pid=1732, effective(0, 0), real(0, 0), class=kerberos] ../../source4/auth/kerberos/krb5_init_context.c:90(smb_krb5_debug_wrapper)
+  Kerberos: TGS-REQ ERR_S_PRINCIPAL_UNKNOWN ipv4:10.0.255.6:63375 windows$@SCHEIN.ME ldap/ucs.schein.me/schein.me@SCHEIN.ME elapsed=0.005813 tixaddrs=TYPE_20:48504250343
4304731302d3120202020 reason=Service principal unknown

Solution:

CNAMEs are always tricky using kerberos. In the logfile the old ucs System is still searched. So for kerberos we add a additional spn ro the server account.

samba-tool spn add ldap/ucs.schein.me/schein.me ucs-new$
#2
Mastodon