Tracking AD authentications - what to audit, what to ignore

Audit category "Logon/Logoff" means the actual logon/off activity where a session is established.

Audit category "Account Logon/Logoff" means *authentication*. It's different from "logon/logoff", it's not "logon/logoff" 

There are 2 places in Windows/AD environment where authentication can happen, 

• locally to SAM database (NTLM), or 
• against AD. 

When a principal authenticates against AD, it could be NTLM or Kerberos. 

[update] MS added 2 new features called "Local KDC" and IAkerb respectively. The former feature allows a local auth happens using Kerberos 

 You are going to see a lot of "logon/logoff" events either on member server, or on DC. 

• When it's on member server, it could be local user or AD user established logon session after auth
• When it's on DC - you should see DC same as a resource member server, because logon/logoff events happens when a user accesses it as client. You will see almost all AD users have logon events on DCs with type 3 (remote) because users need to access DC in various ways in domain - e.g., pulling GPO from SYSVOL folder 

For the purpose of tracking user's "logon" activity into AD, you really want to track their "authentication" activity. You should ignore all "logon/logoff" events from DC because this is redundant. For any logon event there must be preceding authentication event. Auth event alone is enough to determine if a user has recent activity against AD. 

This means to check only 4776-NTLM, 4768, Kerberos, see section below 

• logon/off events
• 4624 : logon
  Note: There are tons 4624 for all users on DC (logon type 3, remote) because user need to connect to SYSVOL etc. 
• Related events 
• 4634: log off (e.g. log off session from a remote server) 
• 4647: user initiated logoff (e.g. in interactive console logoff) 
• 4625: failed to logon 
• 4672: special logon (local) 
• 4648: local logon
• AD auth events (a.k.a *Account* Logon/off events) 
• 4776: If reported on DC, tried to validate credentials via NTLM. 
• Fields to extract in Splunk:(when reported on local, SAM) 
• user: user, or Logon_Account 
• domain: dest|dest_nt_host, remove short host name final query: EventCode=4776 | regex user!=".*\$$" | rex field=dest "^.*?\.(?.*)"| strcat domain "\\" user ID 
• 4768 Kerberos TGT validation: 
• Field to extract in Splunk
• user: user | Account_Name | src_user 
•  domain: user_account_domain | dest_nt_domain 
• Related events:
• 4771: Kerberos pre-auth failed 
• 4772: TGT request failed 
• 4769 Kerberos Service Ticket requested (good for knowing what resource an account is accessing) 
• 4770: ST renewed

Make a MIT Kerberos client on Windows

Steps

1. Compose krb5.conf file ( In windows, it's krb5.ini under %programfile%\MIT\Kerberos)
1. concepts here
2. samples here
   
   
   
   
   
   
3. reference here
2. Ktpass command to generate keytab file
1. ktpass /out userName.keytab /mapuser userName@johnfoo.tk /princ http/serviceHostName.johnfoo.com@JOHNFOO.TK /pass <pwd> /crpto all /ptype KRB5_NIT_PRINCIPAL
3. kinit to obtain ticket
1. kinit -k -t userName.keytab http/serviceHostName.johnfoo.tk@JOHNFOO.TK
4. klist to verify that ticket was issued successfully
   
   
   
   
   

Demo-parallel-foreach

 This requires PowerShell v7

$sub=New-Object System.Collections.ArrayList

$destSubs = [System.Collections.ArrayList]::Synchronized($sub)

$allsubs=@(1,2,3,4,5)

$externalVariable=3

$AllSubs | Sort-Object -Property Name | ForEach-Object -Parallel {

    # Any external variable reference needs to be localized using "using"

    $localVariable = $using:externalVariable

    ($_ -lt $localVariable)

    # Obtain reference to the bag with `using` modifier

    $localCostsVariable = $using:destsubs

    # Add to bag

    $localCostsVariable.Add($_)

}

$destSubs

write-host ""

$sub

# NOTE: many AD object properties won't be visible inside of a parallel script block.

# Need to trigger PS AD adapter driver to populate the result set first

# https://stackoverflow.com/questions/75851412/powershell-foreach-object-parallel-not-all-properties-of-piped-in-object-are-a

#

$users = get-aduser -filter $filter -properties samAccountName,lastLogonTimestamp

#$users=$users|select *    # uncomment this line in order to make below work

$users|foreach -parallel {
   [do something with $_.samAccountName]   # --> this works fine. samAccountName can be read properly
   [do something with $_.lastLogonTimestamp]    # --> this doesn't work. lastLogonTimestamp is always NULL regardless if it is actually populated

}