Search This Blog

Nov 26, 2018

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

Aug 23, 2018

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.)
-           

Tags: ,

Jul 5, 2018

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

Tags: , ,
Subscribe to: Posts (Atom)