Question 1: How/where are the events generated on the Linux Client? I want to know which file(S) generate the security events mentioned above so I can take a closer look and modify if needed.
AD clients do not send any security events explicitly. (Allowing them to generate arbitrary events would be... insecure.) Anything that is logged as an event at a DC is logged by the DC itself and is the result of some other action done by the client to the DC.
For example, the DC will only log event 4768 when it handles an actual Kerberos AS-REQ message (to issue an initial Kerberos ticket); if a client authenticates e.g. using the older Netlogon protocol instead of Kerberos, the DC won't log 4768.
Our issue lies in some of the values (fields) within these events (TargetUserName for example shows hostname instead of username - we need it to show username so our SSO Agent can read the user status).
The user ID logged in that event is not arbitrarily chosen by the client, but is the exact user ID whose credentials were just verified by the DC. So if the user ID is "computer$", that literally means the DC issued a ticket for the machine account "computer$" and not for any person account.
Question 2: Which method does the Linux client tell the KDC (AD) that a domain user logged in/out/is active/changed groups etc?
AD doesn't do central session accounting, so there are no actual "logged in" events being sent – the closest is an "authenticated via Kerberos" or "authenticated via Netlogon protocol" event indicating that credentials were verified, but it doesn't really indicate that a session was set up. Similarly, there are no "is active" or "logged out" events at all, a user is logged in as long as they have a valid Kerberos TGT.
If you're seeing login/logout events from Windows clients, they most likely correspond to a session being created on the DC, not on the client; more specifically I suspect that they correspond to the Windows client connecting to the Sysvol file share hosted on your DC in order to download User GPO files. A Linux client running Winbind won't look at GPO at all; though a client running SSSD might.
There are no "group change" events – the DC informs clients about what groups a user is member of, not the other way around. (Local group membership is not reported to DCs and doesn't influence any security decisions outside of the local machine – when accessing e.g. a file server over SMB, only the DC-provided groups listed in your Kerberos ticket's PAC are used.)
Does it use the keytab (/etc/krb5.keytab) for the host for communication or does it use the user token file generated under /tmp/krb5cc_****_ ?
Both. An AD client uses its machine credentials (krb5.keytab or LSA "machine password") for retrieving user information (such as mapping usernames to UIDs and back) and downloading machine-level Group Policy, while programs invoked by the user will rely on the user's own Kerberos credentials ($KRB5CCNAME or per-user LSA creds) to access file servers, perform web SSO, etc.
One major difference is that in most Linux AD clients, standard communications with the LDAP directory are handled by a single service (SSSD or Winbind) which then always uses machine credentials to retrieve information, e.g. if you run ls -la to list files, their owner UIDs/GIDs are translated by SSSD/Winbind using the machine credentials – whereas in Windows the same communications are done directly by the process that needs the data, e.g. if you're adding a user to file ACLs through the "Security" tab, it is Explorer.exe that performs the actual LDAP search and does so using the user's credentials.
Best Answer
I solved through secpol.msc
I double clicked the subcategories of interest in the right pane (such as Audit Logon, Audit Logoff, Audit Credential Validation) and even though they were already configured to "Success and Failure" I disabled them, clicked Apply, re-enabled them, Apply.
Somehow this unlocked the two machines. I don't know how permanent this fix is it but it did survive a reboot and a gpupdate /force (that returned success).
It should be noted though that there are WSUS and conflicting policies problems in the domain. All computers return error 0x8024002e in their Update Status.