In Part 3 of the series, the author shifts focus to a seemingly overlooked log field called "SDFlags," which plays a crucial role in understanding LDAP queries related to Active Directory security descriptors. Initially, the author concentrated on LDAP filters and attributes, missing the significance of SDFlags. After noticing it, they discovered that SDFlags only appears when queries request the nTSecurityDescriptor attribute, which outlines permissions on objects within Active Directory. The connection is vital: 100% of queries involving SDFlags also involve nTSecurityDescriptor. The author dives into the technical details, explaining how SDFlags uses bitmask values to determine which components of the security descriptor to retrieve. For instance, a value of 0x5 indicates the query seeks both the Owner and the Discretionary Access Control List (DACL). Understanding this is essential because querying nTSecurityDescriptor without specifying SDFlags can lead to failed queries for non-privileged accounts, as Active Directory won’t return incomplete data. This insight highlights the importance of SDFlags in avoiding permission-related issues during reconnaissance. In a practical lab setting, the author illustrates how querying nTSecurityDescriptor reveals critical permission relationships, which are key for attack path discovery. For example, they note potential risks such as regular user accounts with privileges to modify group memberships or service accounts with extensive rights. This information is particularly relevant for tools like BloodHound, which rely on nTSecurityDescriptor to map out attack paths. Without this data, administrators can miss crucial vulnerabilities within their Active Directory environments. The patterns observed in SharpHound's queries further reinforce the necessity of including nTSecurityDescriptor in security assessments.