MS Graph RESTful Queries

1.  Links
1. Graph Explorer
   
2. MS Odata Document
   
3. Oasis Odata v4.0.1 URL Conventions, specifically, pay attention to 
   
1. URL components
   
2. Resource path and how to address entities, properties etc.
   
3. Query Options
   
2. An Odata URL is consist of 3 parts
   
   
   
   
   
   
1. root URL: GET request made to root URL returns service document (that defines all resources available via the service)
2. resource path: Entity or entity sets that are accessible via RESTful API
3. Query option: select, filter, count, skip, order, top etc. See next section 
3. Addressing
1. Getting entity set:    GET serviceRoot/users
2. Getting individual entity by key:    GET serviceRoot/users('john.doe@example.com')
3. Getting entity property    GET serviceRoot/users/displayName
4. Getting entity property raw value:    GET serviceRoot/users/displayName/$value
5. Getting entity set:    GET serviceRoot/users
6. Getting entity set:    GET serviceRoot/users
7. Addressing metadata in powershell: $obj.'@odata.type'
   The key here is that the dot (.) between "odata" and "type" is not denotation of a sub-property, but just a normal text character as part of the property name '@odata.type' (so we quote the whole string)
4. Query options
1. Filter:
1. Filter operators: eq/ne/gt/ge/lt/le/and/or/not/has/in
2. Filter functions: contains/startsWith/endsWith/indexOf/concat/subString
3. Collection functions: hasSubset/hasSubsequence
4. More functions on Oasis URL above
5. Example #1:    GET serviceRoot/users?$filter=upn eq 'johnDoe@example.com'
6. Example #2, filter against complex type. This query finds airports whose address contains "San Francisco", where address is a property of a complex type Location:    GET serviceRoot/Airports?$filter=contains(Location/Address, 'San Francisco')
7. Example #3:    GET serviceRoot/users?$filter=upn in {upn1@x.com,upn2@x.com}'
2. Expand:
1. Navigation properties: any property that can link to another entity. For example, "memberof", "manager" property of a user
2. Example #1:    GET serviceRoot/users?$filter=upn eq 'johnDoe@example.com'$expand=manager
3. Example #2:    $uObj=get-mgUser ... -expandproperty manager; $uObj.manager.additionalProperties.displayName
4. Example #3:    get-mgUser ... -expandproperty "manager(`$select=displayName,jobTitle)"
3. Select:
1. Example #1:    GET serviceRoot/users?$select=*
4. OrderBy:
1. Example #1:    GET serviceRoot/users?$expand=manager($orderby=department)
2. Example #2, order by the count of members:    GET serviceRoot/groups?$orderby=members/$count
5. Top/Skip/Count
6. any/all operator
1. GET serviceRoot/People?$filter=Emails/any(s:endswith(s, 'contoso.com'))
5. Literals
1. null/$it/$root/$this
6. placeholder

Enabling SMS Communication Using Azure Communication Service

Recently adding SMS alerting function to a monitoring program that my son wrote. Below are high level steps for North America developers.

1. Assuming you already have App Service Plan and App Service in Azure
2. Request SMS service
1. Search "Communication Service" -> "create" to create a communication service instance
2. Once created, under "Phone numbers", request a phone number. 
1. Only toll free number can send SMS messages
2. Cost (as of July 2023): $2/month + per message cost (neglectable)
3. You can also request short code ID or aliphatic ID for extra cost
3. Submit request for SMS sending
1. In same page of the communication service instance, under "Regulatory Documents", submit a request. 
2. "opt-in type" refers to how "customers" (as the regulatory is designed around marketing SMS messages) opt-in/opt-out. It could be SMS, web portal, paper form, etc. You have to provide evidence(screenshot) that there is such opt-in option available to customers
3. It could take weeks to get approval
4. Your outbound messages are blocked until your request is approved in Canada. In the States, you can send limited number of messages before approval
4. Sample code to send SMS message

How AD decides Kerberos encryption type per user/computer basis

Supposed that there is no GPO to enforce supported ciphers, on a per principal basis, it is determined as below:

If msDS-SupportedEncryptedTypes is populated, then use values defined in this attribute. It's a 5-bit flag

• bit 0   DES-CBC-CRC
• bit 1   DES-CBC-MD5
• bit 2   RC4-HMAC
• bit 3   AES128-CTS-HMAC-SHA1-96
• bit 4   AES256-CTS-HMAC-SHA1-96

If msDS-SupportedEncryptedTypes is NOT populated, then AD reads values in userAccoutControl. 

• if 0x200000 is set, DES will be used
• if 0x200000 is not set, default to RC4 for 2008/7 and later

Default behavior:

• Computer account: msDS-SupportedEncryptedTypes set. OS 2008/Win7 and newer: DES is disabled
• User account: msDS-SupportedEncryptedTypes is not set so RC4 is used see here, unless userAccountControl forces DES
• Referral Ticket/Trust object: higher of DES/RC4 that is mutually supported by client and authenticating domain. If both client and trust don't have any custom value set, cipher is RC4.
  
  NOTE/WARNING: If you enabled "AES" support on trust using GUI, only AES will be supported; RC4 will be disabled. If you want to add "AES" on top of RC4, use ksetup to change trust.

PS. Above behavior is always for Service Ticket.

    Since TGT is meant for DCs to read, it always uses what DC supports, and is irrelevant to what is defined on individual accounts.

Sample Script to find risky users

#Bitwise AND: 1.2.840.113556.1.4.803
#Bitwise OR : 1.2.840.113556.1.4.804
# 2097152 is 0x200000, bit mask for userAccountControl DES enforced
# 3 is 0b11, covers the last 2 bits of msDS-SupportedEncryptionTypes, which enables DES

# list users who
    # user object, and
    # enabled, and
        # supportedType set with DES, or
        # supportedTYpe not set but userAccountControl DES set
        
$ldapfilter=@("(&",`
    "(objectclass=user)",`                                                         # user Object
    "(!(userAccountControl:1.2.840.113556.1.4.803:=2))",`                          # enabled
    "(|",` 
        "(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=3)",`              # DES defined in supportedType
        "(&",`                                                                     # or DES not set in supported type but in userAccountControl
            "(!(msDS-SupportedEncryptionTypes=*))",`                                   
            "(userAccountControl:1.2.840.113556.1.4.803:=2097152)",`
        ")",`
     ")",`
")")
$ldapfilter = $ldapfilter -join ""

$u=get-aduser -ldapfilter $ldapfilter -server foo.bar -Properties msDS-SupportedEncryptionTypes,enabled,userAccountControl,UseDESKeyOnly

Decentralized Identity (DID) - Verifiable Credential - Microsoft Verified ID

Traditional IDs are issued/owned by IdPs. From user's perspective, these IDs among different IdPs can be inconsistent, hard to maintain, and there is no guarantee of privacy, control, etc.

Decentralized ID lets a user owns his/her ID. Any other entity can then add claims to DID. For example, an employer can add employment claim to its employees' DIDs. Therefore, traditional IdPs no longer own IDs, they either become irrelevant to a person (if they can't add/verify claims about the said person), or they transform themselves to be claim issuer (if they know something about the holder) /verifiers (in this case, the old IdP is just a consuming party of DID model).  

"Claims" here is called "Verifiable Credentials"(VCs) in DID context. It's verifiable because it's digitally signed. Entities that assign/sign VCs are called Issuer.

DID creation, change, as well as claim history, are stored in a public, decentralized network. It can be tracked and verified without a centralized IdP. Such network is called Trust Systems. Examples include ION (Identity Overley Network) and DID:web. Trust System can be built on top of existing blockchain network such as Bitcoin.

For the model to work, there are implicit trusts listed below:

• Issuer trusts holder
• Verifier trusts issuer
• Holder trusts verifier

Set up a hybrid Azure AD lab

 General steps

1. Set up an on-premise AD with forest name johnfoo.tk
2. get a free domain from freenom (johnfoo.tk)
3. In Freenom, configure to use your own DNS server, pointing to on-prem DC IP
4. set up Azure AD 
5. create an Azure account for AAD Connect, make it Global Admin
6. create an AD service account for AD, give it DC Sync permission (or let AD Connect create for you)
7. Add and verify Custom Domain in AAD. Create the TXT record on your AD DNS. The "@" -named record required by Azure is equivalent of "(same as parent)" record in Windows DNS. Just leave the record name blank when create the TXT record.
8. Install AD Connect, enable
1. PHA (recommended, for auth fault tolerance, or PTA). Of course, use federation is also possible depending on if you are using ADFS right now on prem
2. Enable Seamless SSO (for on prem users SSO into Azure)
3. Be careful what attribute to use for join rule (?). UPN is a good candidate. Unless on prem users are already having email address, using mail for linkage will not work

Manually join Windows clients into Azure AD

1. Enable join/register option for regular users: AAD|Devices|Device Settings|Users may join devices to Azure AD
2. On Win client, Accounts, connect to work, then select "join this device to Azure AD", follow on screen instructions 
3. use "AzureAD\azureUPN" to log into the newly joined machine (e.g. AzureAD\jlan@johnfoo.tk)

Manually register Windows clients into Azure AD

1. Same steps as above, but in step 2, do not select "join this device to AZure AD", instead, just click on "next" button 

Create a B2C Tenant

1. Run "az provider register --namespace Microsoft.AzureActiveDirectory"
2. Follow on screen instruction

Grant Admin access to an Azure-joined machine

1. Tenant wide permission
1. Azure AD has a "Device administrators" role that is used for this purpose
2. Go to Devices | Device Settings | Manage Addtional local administrators on all Azure AD Joined devices | +assignment
2. Individual machine
1. Locally on the machine, using Account Settings to elivate a user
2. "net localgroup administrators /add "Contoso\username" for adding on-prem user
3. "net localgroup administrators /add "AzureAD\UserUpn" for adding Azure user
4. use MDM solution

Enabled Hybrid AD join

1. Run ADC, select Configure | additional tasks | Configure device options
2. Follow on screen instruction

Create a split-DNS for AD forest with same AD-domain name and DNS-domain name

 This is useful for a lab environment where you have an AD forest uses same domain name AD-wise and DNS-wise

• Set up
• domain name: foo.bar
• internal subnet: 192.168.0.0/24
• Commands
• Add-DnsServerClientSubnet -Name "loopback" -IPv4Subnet 127.0.0.0/24
  Note: don't forget to add loopback as internal subnet 
• Add-DnsServerClientSubnet -Name "internal" -IPv4Subnet 192.168.0.0/24
• Add-DnsServerZoneScope -ZoneName "foo.bar" -Name "internet"
• Add-DnsServerResourceRecord -ZoneName "foo.bar" -A -Name "@" -IPv4Address "yourPublicIP" -ZoneScope "internet"
• Repeat above to add other A records that needs a public internet presence
• Add-DnsServerResourceRecord -ZoneName "johnfoo.tk" -name "@" -NameServer "yourPublicIP" -NS -ZoneScope "internet" (Optional, your DNS provider already knows how to find your name server)
• Add-DnsServerQueryResolutionPolicy -Name "NonInternalPolicy" -Action ALLOW -ClientSubnet "ne,Internal,loopback" -ZoneScope "Internet,1" -ZoneName "foo.bar"
• Add-DnsServerResourceRecord -ZoneName "johnbook.ga" -name "@" -TXT -DescriptiveText "MS=ms35639551" -ZoneScope "internet" 

What is DNS DNAME record and how it works

 

Setting up ADC using gMSA - and ADC concepts in general

Connector concepts

1. for an ADC service, on one side, it's on-prem AD, on the other, it's AAD. 
2. ADC is therefore divided with 3 components: connector space to AD, metaverse, and connector space to AAD
   
   
   
   
   
   
   
   
   
3. With these 3 components in mind, there are below operations can be performed
1. Take connectors for AD for example, import from AD (to pick up new changes in AD), this picks up AD object and create a corresponding staging object in Connector Space
2. or to export to AD (for writeback), this exports staging object to AD
3. Synchronization: meaning create metaverse objects from staging objects, then create staging objects on the connector space other side of flow
4. Same operations are applicable on AAD connectors in same way
4. Seamless SSO VS. AADj-join SSO. 
1. Seamless SSO: 
1. For AD users on on-prem device to access cloud resource
2. Leverage a computer object in on-prem AD to represent Azure AD. When a Windows AD user access cloud access, in the background the user is redirected to access the computer object first and get a kerberos ticket, which can be sent to, and decrypted by AAD.
2. Azure-joined SSO (aka Azure Kerberos)
1. For AAD-join device to access on-prem resources
2. Same concept of having a computer object in on-prem AD representing Azure.
3. Azure uses the computer object to acquire partial Kerberos TGT for user. User then use it to acquire full TGT from AD

Steps

1. Create a security group for hosts that will be running ADC service, place all host as member "ADCHosts"
2. Create the gMSA account
1. Import-module ActiveDirectory
2. Add-KdsRootKey -EffectiveImmediately
3. New-ADServiceAccount -Name ADCsvc -Description "gMSA for Azure AD Connect installation" –DNSHostName ADCsvc.johnfoo.tk -principalsAllowedToRetrieveManagedPassword ADChosts
   
   Note: param DNSHostName doesn't really do anything here other than used for populating gMSA's DNSHostName attribute.
3. On ADC server, install gMSA account
   
1. Install-ADServiceAccount -Identity ADCsvc$
   Note: 
1. don't forget the $ sign at the end, remember this is really a computer account
2. If you get access denied error, reboot ADC host for membership change in step 1 to take effect
4. Run ADC Installer
1. custom installation
2. use existing service account
3. specify "johnfoo\adcsvc$" fun ADC service itself
4. specify a "Global Administrator" for AAD
5. specify an existing account or let ADC installer creates a new account for on-prem AD. This account needs DC Sync (replication) permission. 
   Note: the account created by installed is called "MSOL_*" under "users" container. To get the exact name, check ACL entries on top of domain that has DC Sync permission
5. If you use ADC to sync extension attributes (e.g. employeeType), there should be an app in AAD called "Tenant Schema Extension App" , this is where you can find App ID so you can retrieve extension attributes (for example, create a dynamic group based on an extension attribute)

How to initiate a manual sync (see figure above)

1. open "Synchronization Service"
2. On "Operations" tab, right click a connector that is for AD, run, import, or
   On "Connectors" tab, right click a connector for AD, run, import
3. then Run -> sync on both sides
4. Finally export on AAD connector

How to change existing sync rules

1. use Synchronization Rules Editor
2. A rule defines scoping/filter/join rules/transforming rule
3. Understand rule types for different phase of operations: provision/join/
4. Example: if you want to change "sync criteria" (a.k.a "how to uniquely identify users cross forest", which is not possible to be changed using ADC configure GUI once initially set up), this can be done by editing rule for AD inbound rule for user, interOrgPerson, AccountEnable etc., page "join rule" 
5. special notes for "join rules", while there can be multiple sync rules for a connector source, there can be ONLY one sync rule that defines join rules. Such sync rule will have "join" at end of the sync rule name. So for example above, you only need to find and make changes in "inbound from AD * join" rules
6. see here
   

Notes:

1. If install ADC on a member server, Virtual Service Account is recommended
2. Duplicate attribute resiliency Instead of failing to provision objects with duplicate UPNs / proxyAddresses, the duplicated attribute is “quarantined” and a temporary value is assigned.
3. UserPrincipalName soft match When this feature is enabled, soft-match is enabled for UPN in addition to the primary SMTP address, which is always enabled
4. What should be used as sourceAnchor: 
1. ObjectID if single forest; 
2. still ObjectID even in multi-forest scenario, or use something won't change even when moving user between forests. 
3. EmployeeID would be one if uniqueness can be guaranteed
4. For where you don't have a proper attribute to use, Microsoft provides ms-DS-ConsistencyGuid
5. Predecessor: DirSync -> Azure AD Sync
   Sibling: Azure AD Cloud Sync

How to sync extension attribute from on-prem AD to AAD - and how to use it

ADC syncs a default set of attributes from AD to AAD out of box. To sync extension attributes (the term 'extension attributes' here doesn't refer to "extensionattribute1-15", but rather any attribute that is not included by default by ADC for sync with Azure):

1. Open ADC | Configuration | Customize Sync Options
2. In "optional features", check "Directory extension attribute sync"
3. In attribute select page, check and select what you want to include to be sync'ed

Within Azure AD portal, how to retrieve extension attribute

1. There should be a new app called "Tenant Schema Extension App" , this is where you can find App ID so you can retrieve extension attributes
2. E.g. Creating a dynamic group based on extension attribute
1. when create group rule, select "Get custom extension properties" option
2. In new window, paste in the App ID you copied from step 1, then click on refresh button
3. back to attribute dropdown list, at buttom the new attribute should be available for you to chose. The attribute name is in format similar to "extension_appID_GUID_onPremAttName"

See Also: general concept of extend attribute in AAD

Azure - Places to enable MFA - and special notes about Authentication App as a factor

There are multiple places where you can mandate MFA. Below are the list and the advantages/disadvantages of each place.

• Conditional Access Policy
  
  This method focuses on "access control". It forces MFA based on certain conditions when user is accessing resources. Naturally, this is fit for when you want to have higher level of assurance when certain resources are accessed
  
  
• Identity Protection\MFA registration policy
  
  This place is to force users to register MFA rather than define when to use
  
  
• Sign-in risk policy
  
  Force user to use MFA base on risk detected. What considered as "risky" is determiend by MS algorithm that is not disclosed. Factors include unusual logon behavior, unusual location etc.
  
  
• Security Default
  
  This is a heavy hand approach. "Security Default" enforces a bunch of best practices tenant-wide along with MFA requirement.

Places you define what factors you can offer to users for registration, and how each factor should behave

• Legacy
• AAD | Security | Multifactor authentication | additional cloud-based MFA settings
• AAD | Password Reset | SSPR Policy (if used, only for SSPR)
• New
• AAD | Security | Authentication policies (how each factor should behave )

Besides the above 4 approaches to require MFA, it can also be registered on per-user basis in AAD portal. To improve Authenticator registration rate among users, you can create a registration campaign under "Security | Authentication methods | Registration campaign"

Special notes about registering Authenticator App as a factor:

When doing a per-user registration, other form of factors (SMS, voice call) can be assigned to users in AAD portal, but Authenticator App can only be registered by user himself in "my account" portal

How "Authentication Context" Works in Azure

 First of all, let's just say "Authentication Context" has little to do with authentication, not sure why MS picked such a misleading name. It's really a labeling system to give content owner more control over what should be protected, and how.

1. Create the context
   It's a label can be defined in AAD | security - in here, everything is just a text tag. It has no meaning now until after you use it in a Conditional Access Policy
2. Link the "auth context" created in step 1 to a "sensitivity label"
   "auth context" created above will be shown as an option for you to choose from in your Sensitivity Label'| site setting | "Define external sharing and device access settings" page, there is an option called "Use Azure AD Conditional Access to protect labeled SharePoint sites", under which you will see the label you created in step #1
3. Link the context to an access policy
   Create a conditional access policy targeting this label (traditionally you can only target applications, user actions, but now you can target a tag/label)
4. How everything works together
   For documents with the abovementioned sensitivity label, its access settings -> context name -> access policy in scope for the context
5. This way, the level of protection is not limited to be defined only by Azure admin, but by content owner as well.
   In other words, Azure AD admin defines a protection option, content owners decide if they want to use that option themselves (by enabling the label) (compare to the old way where Azure admin push down a policy for all things in scope)

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

Deletion Protection And Mysterious Access Denied

Issue:

-         Setup

1.     A group called “delComputerGrp”

2.     A member of delGroup called “delComputerUsr”

3.     OU named “testOU”

4.     delComputerGrp is granted below permission on “testOU” OU

§  Permission: “delete computer objects”

§  Apply to “all descendent objects”

-         Expected behavior

1.     Member of delComputerGrp can delete computer accounts under testOU

2.     This was working

-         Actual behavior

1.     Access Denied

Troubleshooting:

-         Check effective permission on OU level for delComputerGrp, it has the “delete computer objects” permission (expected)

-         Check effective permission on OU level for delComputerUsr, it doesn’t have “delete computer objects” permission (unexpected)
Note: This may be a bug on how Windows calculates effective permission. Although this is puzzling, but it turned out not related what we were going to discover later

-         Found that on testOU, it has “delete all child objects/Deny” ACE. No one has added this entry. This is shown as “DELETE CHILD” in dsacls output

-          In the meantime, the flag “accidental deletion protection” flag is not enabled on testOU

-          When enable “accidental deletion” on OU, here is what happen:On OU protected:

Fig. 2

So even with the protection turned on,  “delete child” is not set to deny. Something else set the “delete child/Deny” entry

Unexpected discovery:

-          By a little bit of googling and testing, I found that when one enables “accidental deletion protection” on an object, AD does not just add the deny permission on target object, it also adds a deny entry on parent container! In summary, when you check the protection box, it does:

1.       On target object (whether it be a leaf object or a container)

§  “Delete/deny” on the object itself

§  “Delete subtree/Deny” on the object itself

2.       On the parent container

§  “Delete all child objects”

-         
Fig 3

-          Back to the problem of deleting computer objects in test OU, it seems that someone has enabled deletion protection a computer (or computers) within testOU. AD then added “delete all child objects” on testOU. This deny ACE on parent container (testOU) effectively cancelled out the “delete compute objects/allow” permission. So even though the intention is to protect only one computer, but it makes delComputerGrp unable to delete other sibling computers.

Why AD needs to set deny permission on parent container to protect a child object?

-         It turns out that there are 2 type of ACE entries that give us ability to delete an object

1.     Delete permission on the target itself

2.     Delete Child from parent

-         As long as one has “delete” OR “delete child” (on parent), he/she can  remove the target object

-         The keyword of above statement is “OR”: Even with “delete” is denied on target, “delete child” from parent still gives one ability to delete the object. In order to truly protect an object, AD has to go one level up and deny the “delete child” permission. It’s a design flaw if you ask me, because it now causes problem that is described at the beginning of this article

Solution

-         Option #1: Remove the “delete child/deny” ACE from parent container (testOU)

1.     This gives the ability to remove computer objects back to delComputerGrp

2.     Computer(s) that need protection still get certain degree of protection (compare to when the flag is not enabled). Just that the protection is not complete - member of delComputerGrp are still able to remove via “delete computer objects/allow” entry (subset of “delete child”)

3.     But the biggest drawback is the “delete child/deny” entry is going to come back whenever anyone turns on the protection on any object in this container

-         Option #2: Instead of give “delete computer objects/allow” permission on (testOU) to delComputerGrp, give it “delete”(all descendent objects)

1.     This gives delComputerGrp more permissions than it should have, it can now remove not only computers, but all other object types - not a least privilege approach

2.     “Delete child” is not going to cancel out delComputerGrp’s ability to remove computer objects now. Because, remember, the condition to delete an object is “delete” OR “delete child”.

Ref.:

http://www.active-directory-security.com/2017/08/how-to-correctly-audit-who-can-delete-an-organizational-unit-in-active-directory.html (Defences, n.d.)

-           

Negative cache TTL on Windows-based DNS

Think about this scenario:

- client uses Windows DNS for name resolution
- client has a record on an external DNS server, let's say a.external.com
- Windows DNS forwards queries of *.external.com to its respective authoritative DNS
- a.external.com has a TTL of 1 min
- a.external.com is removed then re-created with a new IP in 2 min time range (this is common for a cluster or load balancer setup)
- After the record is re-created, client pings it right away and expect to see new IP returned
- Actual result is "host name not found in DNS"

This is because how Windows DNS handles negative cache. Within that 2 min outage window, if anyone queried the name, Windows DNS gets a negative result from upstream (external) DNS. This negative result is cached ( naturally called negative caching), with a TTL as described below:

• Windows client resolver has a universal negative cache time (default 5 min) that can be changed in registry
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \DNSCache\Parameters\NegativeCacheTime
• Windows DNS server sets the TTL of negative result cache from SOA of hosting zone (update: lesser of TTL for SOA record itself, or the zone Minimum Default TTL). In this particular case, TTL from external.com zone SOA. However when SOA TTL is too short (<1min) or too long (>15min), Windows will cap TTL to be 1min and 15 min respectively(Coming from MaxNegativeTTL, can be viewed by powershell cmdlet get-dnsservercache).

See my other 2 posts on TTL/negative cache

(positive) TTL client side registries
DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record

More read:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959309(v=technet.10)
https://social.technet.microsoft.com/wiki/contents/articles/26864.windows-server-dns-service-negative-caching.aspx
https://social.technet.microsoft.com/Forums/windowsserver/en-US/e5feb606-9eba-46aa-ac57-08a98f812071/negative-dns-caching?forum=winserveripamdhcpdns
Windows 2000 behavior about capping: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959309(v=technet.10)?redirectedfrom=MSDN
Cannot find official article about new versions, but I assume globally it's regulated by MaxNegativeTTL