Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Indexing’ Category

(2015-02-10) Finding Attributes With A Subtree Index

Posted by Jorge on 2015-02-10


When an attribute is defined with the bit 2^6 (=64) in the searchFlags property, the attribute is configured to have a subtree index. This index allows Virtual List View (VLV) operations to be more efficient when using a specific attribute as the sort key. In a (very) large DS it also prevents the VLV query to terminate with the "Critical Extension Unavailable" error as a subtree index prevents the use of the special internal table called TEMP. The size of this table can vary, but by default the maximum number of entries is configured to be 10000 (the MaxTempTableSize setting of the Default Query Policy). VLV is a GUI technique that can be used when, ordered lists containing a large number of entries, need to be displayed. When the LDAP protocol is extended to use VLV (request: 2.16.840.1.113730.3.4.9; response: 2.16.840.1.113730.3.4.10), a window that contains a small number of visible list entries is drawn. The visible portion of the list can be relocated to different points in the list by means of scrolling, slider bars, and cursor keys as well as PAGE UP/DOWN keys. The user experience is that the full list can be browsed at will, even though it might contain millions of entries. In fact, the complete list contents are never required at any one time. Rather than retrieve the complete list from wherever it is stored (typically, from disk or a remote server), the server retrieves only the information that is required to display the part of the list that is currently in view on the client. This improves both the response from the server and the speed at which results are listed at the client.

ADFIND

ADFIND -h R1FSRWDC1.IAMTEC.NET -schema -f "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=64))" -dn

OR

ADFIND -h R1FSRWDC1.IAMTEC.NET -bit -schema -f "(&(objectClass=attributeSchema)(searchFlags:AND:=64))" -dn

OR

ADFIND -sc SINDEXED -dn (sorted output: ADFIND -sc SINDEXEDL -dn)

image

Figure 1: Example Output

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=64))" | %{$_.DistinguishedName}

ADSI Through PoSH

$targetDC = "R1FSRWDC1.IAMTEC.NET"
$rootDSE = [ADSI]"LDAP://$targetDC/RootDSE"
$schemaNamingContext = $rootDSE.schemaNamingContext
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.SearchRoot = "LDAP://$targetDC/$schemaNamingContext"
$search.filter = "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=64))"
$search.FindAll() | %{$_.Properties.distinguishedname}

PS: replace the FQDN of the DC with your info

PS: the opposite of this query can be found by replacing (searchFlags:1.2.840.113556.1.4.803:=64) with (!(searchFlags:1.2.840.113556.1.4.803:=64))

More information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), AD Queries, Indexing, Schema, Tooling/Scripting | Leave a Comment »

(2015-02-06) Finding Attributes With A Tuple Index

Posted by Jorge on 2015-02-06


When an attribute is defined with the bit 2^5 (=32) in the searchFlags property, the attribute is configured to have a tuple index. A regular index, assuming the attribute syntax also supports it, also is optimized to support queries using trailing wildcards (e.g. ‘name=jorge*’). To be able to support medial queries, where wildcards in queries are anywhere but at the end of the string (e.g. ‘name=*pinto’ or ‘name=jorge*pinto’), a tuple index should be enabled for the attribute(s) if (an) application(s) is/are having bad/poor medial query performance. An important thing to be aware of is that tuple indexes will increase the AD database (NTDS.DIT) more than regular indexes. In addition, the performance impact of new attribute insertion depends on the number of attributes being inserted at once. The more attributes being inserted, the higher the impact.

ADFIND

ADFIND -h R1FSRWDC1.IAMTEC.NET -schema -f "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=32))" -dn

OR

ADFIND -h R1FSRWDC1.IAMTEC.NET -bit -schema -f "(&(objectClass=attributeSchema)(searchFlags:AND:=32))" -dn

OR

ADFIND -sc TUPLE -dn (sorted output: ADFIND -sc TUPLEL -dn)

image

Figure 1: Example Output

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=32))" | %{$_.DistinguishedName}

ADSI Through PoSH

$targetDC = "R1FSRWDC1.IAMTEC.NET"
$rootDSE = [ADSI]"LDAP://$targetDC/RootDSE"
$schemaNamingContext = $rootDSE.schemaNamingContext
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.SearchRoot = "LDAP://$targetDC/$schemaNamingContext"
$search.filter = "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=32))"
$search.FindAll() | %{$_.Properties.distinguishedname}

PS: replace the FQDN of the DC with your info

PS: the opposite of this query can be found by replacing (searchFlags:1.2.840.113556.1.4.803:=32) with (!(searchFlags:1.2.840.113556.1.4.803:=32))

More information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), AD Queries, Indexing, Schema, Tooling/Scripting | Leave a Comment »

(2015-02-02) Finding Attributes With A Container Index

Posted by Jorge on 2015-02-02


When an attribute is defined with the bit 2^1 (=2) in the searchFlags property, the attribute is configured to have a containerized index. This index indexes the value of the attribute relative to the name of the container or OU. Since the index is container-based, its size will be smaller and probably faster when performing one level queries. A one level query is a query against objects in a single container/OU.

ADFIND

ADFIND -h R1FSRWDC1.IAMTEC.NET -schema -f "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=2))" -dn

OR

ADFIND -h R1FSRWDC1.IAMTEC.NET -bit -schema -f "(&(objectClass=attributeSchema)(searchFlags:AND:=2))" -dn

OR

ADFIND -sc CINDEXED -dn (sorted output: ADFIND -sc CINDEXEDL -dn)

image

Figure 1: Example Output

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=2))" | %{$_.DistinguishedName}

ADSI Through PoSH

$targetDC = "R1FSRWDC1.IAMTEC.NET"
$rootDSE = [ADSI]"LDAP://$targetDC/RootDSE"
$schemaNamingContext = $rootDSE.schemaNamingContext
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.SearchRoot = "LDAP://$targetDC/$schemaNamingContext"
$search.filter = "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=2))"
$search.FindAll() | %{$_.Properties.distinguishedname}

PS: replace the FQDN of the DC with your info

PS: the opposite of this query can be found by replacing (searchFlags:1.2.840.113556.1.4.803:=2) with (!(searchFlags:1.2.840.113556.1.4.803:=2))

More information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), AD Queries, Indexing, Schema, Tooling/Scripting | Leave a Comment »

(2015-01-29) Finding Attributes With A Regular Index

Posted by Jorge on 2015-01-29


When an attribute is defined with the bit 2^0 (=1) in the searchFlags property, the attribute is configured to have a regular index. When applications are querying AD on a regular basis, or very frequently, using the same attributes over and over again, attribute(s) used can be, or better yet should be, indexed to improve query performance. The values of an indexed attribute are placed in a special table in a sorted order, so that a query using the attribute is completed much faster by just looking at a subset of all the data in the DS.

Important points to be aware of about indexes:

  • Indexing attributes increases the AD database (NTDS.DIT), therefore it costs disk space;
  • Indexes are built locally by every DC and are not replicated;
  • Configuring an attribute for indexing impacts DC performance immediately because of the index is built right away, unless deferred indexing (W2K12 DCs and higher) has been configured. With deferred indexing configured, the indexing operation only starts after the DCs reboots (probably restarting the service is enough) or the operational attribute updateSchemaNow is triggered. Deferred indexing is configured by enabling the 18th bit on the forest-wide attribute dsHeuristics.
  • The speed at which an index is created is dependent on how much data must be indexed and also the hardware on which the DC is running;
  • Queries that contain bitwise operations on an indexed attribute (e.g. systemFlags, userAccountControl) negates the usefulness of the index. A bitwise operation cannot be directly looked up in the index table, and the entire set of values in the index will have to be enumerated and tested;
  • Queries that contain a NOT of an indexed attribute negates the use of the index for that portion of the query. It requires the enumeration of all objects in the search scope to determine which objects do not have the attribute or which objects have permissions applied that deny the trustee/actor to view the attribute value;
  • Linked attributes are implicitly indexed, therefore no need to explicitly index;
  • Indexes can be built and will work correctly for attributes with multiple values or non-unique values.

ADFIND

ADFIND -h R1FSRWDC1.IAMTEC.NET -schema -f "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=1))" -dn

OR

ADFIND -h R1FSRWDC1.IAMTEC.NET -bit -schema -f "(&(objectClass=attributeSchema)(searchFlags:AND:=1))" -dn

OR

ADFIND -sc INDEXED -dn (sorted output: ADFIND -sc INDEXEDL -dn)

image

Figure 1: Example Output

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=1))" | %{$_.DistinguishedName}

ADSI Through PoSH

$targetDC = "R1FSRWDC1.IAMTEC.NET"
$rootDSE = [ADSI]"LDAP://$targetDC/RootDSE"
$schemaNamingContext = $rootDSE.schemaNamingContext
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.SearchRoot = "LDAP://$targetDC/$schemaNamingContext"
$search.filter = "(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=1))"
$search.FindAll() | %{$_.Properties.distinguishedname}

PS: replace the FQDN of the DC with your info

PS: the opposite of this query can be found by replacing (searchFlags:1.2.840.113556.1.4.803:=1) with (!(searchFlags:1.2.840.113556.1.4.803:=1))

More information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), AD Queries, Indexing, Schema, Tooling/Scripting | Leave a Comment »

 
%d bloggers like this: