LDAP filter and native AD Module cmdlet filter syntax for time based attributes - Active Directory

AD uses 2 types of data to represent time in attributes:

Type 1: stored as long integer, LastLogonTimeStamp, pwdLastSet falls under this category

To use LDAPFilter, convert the value you want to use to long integer.

    $longIntTimeValue=(Get-Date).AddDays(-60).ToFileTimeUtc()

    $ldapfilter="(lastLogonTimeStamp<=$longIntTimeValue)"

    get-aduser -LDAPFilter $ldapfilter

To use native filter:

    $longIntTimeValue=(Get-Date).AddDays(-60).ToFileTimeUtc()

    $filter="(lastLogonTimeStamp -lt $longIntTimeValue)"

    get-aduser -Filter $filter

Type 2: store as LDAP date type. For example, whenCreated/whenChanged. Use below filter to query

    YYYY MM DD HH mm ss.s Z

    Where Z signals end of the value and is mandatory

    example

    (whenCreated>=20221130000000.0Z)

To make a ldap filter in powershell from datetime object

    $dateStr = $date.ToString("yyyyMMddHHmmss") + ".0Z" $ldapFilter = "(whenCreated>=$dateStr)"

get-aduser -LDAPfilter $ldapfilter

To use native AD module filter. Please note that $filter uses single quote

    $date = (get-date).addMonths(-2) $filter = 'whenCreated -lt $date'

get-aduser -filter $filter

Sync custom AD attributes to AAD and other ways to have custom attributes

Custom attributes from on-prem AD (by extend schema) can be sync'ed to AAD:

Azure AD Connect sync: Directory extensions - Microsoft Entra | Microsoft Learn

How to sync Custom Active Directory Attributes to Azure AD? (rebeladmin.com)

Sync'ed attributes can be retrieved thru a pre-built app called "Tenant Schema Extension App"

This is not the same as "external identities | custom attributes", or "B2C | user attributes", but using same mechanism behind the scene.

In fact, using same mechanism, you can just "extend" AAD to have custom attributes without the help of ADC or external ID or B2C. 

Azure AD Graph API Directory Schema Extensions | Microsoft Learn

Please note, it's not a true extension of AAD schema (MS won't allow that), but a clever way of utilizing an app to store such "extended attributes".

This is also different from "custom security attributes". Not sure if "custom security attributes" is using same technique (likely not)

Other reads/Best summary:

Custom security attributes in Azure AD part 1: a trip down memory lane | Blog (michev.info)

See also specific case of syncing on premises AD extend attributes to AAD (extend attributes in this context is any attribute that is not included by default by ADC engine)

Sync additional attributes from on-prem AD to AAD

What's Kerberos Armoring (FAST)

Kerberos Armoring (FAST) described in a sentence:

It provides more secure channel by using TGT session key that the device shares with DC to encrypt/sign subsequent (user) Kerberos pre-auth data 

This also prevents attacker from forcing Kerberos authentication to fall back to NTLM (by preventing attacker from spoofing Kerberos error (because now legit errors are signed with the session key))

FAST is required for Compound Authentication and Dynamic Control Access.

BTW, DCA is a different set of authorization method (claim-based) than traditional DACL. This is possible because AD embeds claims in Kerberos ticket when DCA is enabled. Prior to this, a resource partner can only read SIDs out of Kerberos ticket. Without DCA, if you want to use claims, you have to install ADFS.

Of course, claim support within Kerberos is very basic and limited and mainly for DCA. For any other claim-aware app support, a full ADFS is called for.

Now a proud CISSP!

 Material used:

1. Official study guide (read thru whole book, gave me good idea what are covered by the exam)

2. Official practice exams (use it to find my weak areas)

3. CBK reference ( I quickly skimmed thru at very late stage of my study just because I had time, but still helped me to find some knowledge points that I didn't know)

4. CISSP All-in-One Exam Guide (better written, better formatting then official guide)

5. Official Learnzapp app (good to measure my readiness)

6. CISSP mind map series by "Destination Certification" (recommended, very helpful to give you an overall review of each domain, and how different components and concepts fit into bigger picture)

Kerberos Flow Chart / Kerberos sessions keys / AS and TGS

1. Normal Flow
   
   
   
   
   
   
2. Forwarded Delegation
   
   
   
   
   
3. s4u Extension
   
   
   
   
   

A kerberos client is issued 2 type session keys:

1. Session key that is used for communication with TGS

2. Session key that is used for communication with service provider

The process of getting # 1 type session key is called "authentication". It's issued by Authentication Service (AS, for AD, AS resides on same machine as KDC). 

1. Client(machine) sends AS request(contains user ID in cleartext) on behalf of user to AS.
2. AS sends back session key type 1 back to client, encrypted with user's hash). AS also sends back TGT ( same session key plus other info such as session key valid duration) . TGT is not readable to client, it's encrypted with TGS' key (krbtgt hash)
3. Later on, user will use this session key to encrypt messages to TGS
4. AS (AD DC) never stores the session key. It's always the client to keep and present session key to TGS. This is achieved by sending TGT back to TGS (remember in step 2 above, TGT is encrypted with TGS' key so TGS can read the content and get the session key). In other words, session key becomes a timed common knowledge between TGS and client 

The process of getting #2 type session key can be roughly called "authorization" (actual access evaluation happens on resource provider, based on the Service Ticket presented). It's the process to get Service Ticket, which can be later presented to service provider. 

1. client sends a service request, one of the content of this request is its ID/time, encrypted with type #1 session key above. Along side the TGT (again this TGT is not readable to client, but it's readable to TGS/DC) 
2. TGS/DC decrypts TGT to get session key #1 so it can validate client ID /timestamp 
3. If matched, TGS sends back 2 things 
1. type #2 session key, encrypted with type #1 session key so client can read and use type #2 session key for communication with service provider
2. Service Ticket (not readable to client, but only for client to hold it and present to service provider). This is encrypted with service provider's key so only service provider can read it
3. In client's request, it specify a SPN for TGS to locate service provider's key
4. Client presents ST to service provider, along side its own ID, encrypted with type# session key

In short, neither TGS, nor service provide keeps any session keys. It's client's responsibility to obtain (Thru AS and TGS) to get those session keys, and present them to TGS/SP. 

2 TTL related registry on Windows client OS

1. Maximum time a client will cache positive results regardless what TTL a record holds:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\MaxCacheEntryTtlLimit

Note: A record will be cache on client for the period specified in

• record TTL or
• above registry value, whichever is less. 

2. When register its own record, the TTL sent to DNS server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

See Also

• Negative results are cached very differently. Please see Negative cache TTL on Windows-based DNS
• DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record
  

DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record

 
See above, click to see enlarge picture.

This is a screenshot of SOA record.

What the intervals are:

• (Most important one) Minimum default TTL: Default TTL for all records in the zone that don't have their own TTL defined during creation. This parameter is also used as TTL of negative cache
• TTL : TTL for the SOA record itself
• Refresh - This is how often (in seconds) the slave name servers check with the primary name server to see if any changes have been made to the zone
• Retry - This is the time (in seconds) a slave (secondary) DNS server waits before retrying a failed zone transfer
• Expires  - Indicates when the zone data is no longer authoritative - time counted from the point when slave loses contact with master. Applies to Slaves or Secondary servers only. When this expires, slave will no longer respond to queries

Update #1: Regarding negative caching, it is lesser of  Minimum Default TTL, SOA TTL, and 15min (defined in MaxNegativeTTL,  can be viewed with powershell cmdlet get-dnsservercache)

Update #2: One can set different values on SOA TTL and Minimum Default TTL, but Windows will set both to same value, whichever is smaller. Tested on Windows 2016

OS WMI Filter - OS version values

Version attribute	Windows release
NE	Any
95	Windows 95
98	Windows 98
ME	Windows Millennium Edition
NT	Windows NT operating system
2K	Windows 2000 operating system
XP	Windows XP
2K3	Windows Server 2003
2K3R2	Windows Server 2003 R2
VISTA	Windows Vista
Version attribute	Windows release
2K8	Windows Server 2008
WIN7	Windows 7
2K8R2	Windows Server 2008 R2
WIN8	Windows 8
WIN8S	Windows Server 2012
WINBLUE	Windows 8.1
WINBLUESRV	Windows Server 2012 R2
WINTHRESHOLD	Windows 10
WINTHRESHOLDSRV	Windows Server 2016, Windows Server operating system, Windows Server 2019