Archive for the ‘Schema’ Category

(2015-02-20) Finding Attributes Configured To Be Never Audited

Posted by Jorge on 2015-02-20

When an attribute is defined with the bit 2^8 (=256) in the searchFlags property, the attribute is configured to be never audited. When “Directory Services Access” is enabled AND the correct SACL has been configured on objects for a specific action on the attribute by specific actors, access (read or write) those attributes will be audited by default. When “Directory Services Changes” is enabled AND the correct SACL has been configured on objects for a specific action on the attribute by specific actors, the values (before and after the change) of those attributes will also be audited by default. To disable the behavior of also auditing values for one or more attributes, those attributes can be configured not to be change audited at all. This might be of interest for those attributes that have been configured as confidential and auditing has been enabled on the object.

–

ADFIND

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

OR

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

–

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:=256))" | %{$_.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:=256))"
$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:=256) with (!(searchFlags:1.2.840.113556.1.4.803:=256))

–

More information:

How the Active Directory Schema Works

–

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, Schema, Tooling/Scripting | Leave a Comment »

(2015-02-16) Finding Attributes Marked To Be Copied When Duplicating The Object

Posted by Jorge on 2015-02-16

When an attribute is defined with the bit 2^4 (=16) in the searchFlags property, the attribute is configured to be copied when duplicating the object. When using template objects with generic information that applies to all newly created objects, it can be interesting to configure the new attribute in such a way, so that its attribute value is copied from the reference/template object to the new created object. If this flag is configured, it is the responsibility of the tool used, and NOT the directory service, to honor the setting or not and behave accordingly. Make sure the tools used, interpreter this flag correctly when set.

–

ADFIND

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

OR

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

OR

ADFIND -sc COPY -dn (sorted output: ADFIND -sc COPYL -dn)

–

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:=16))" | %{$_.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:=16))"
$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:=16) with (!(searchFlags:1.2.840.113556.1.4.803:=16))

–

More information:

How the Active Directory Schema Works

–

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

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

–

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:

–

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)

–

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:

–

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)

–

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:

–

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)

–

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:

–

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

(2015-01-25) Finding Attributes Marked To Be Preserved On Deletion Or Recycling

Posted by Jorge on 2015-01-25

When an attribute is defined with the bit 2^3 (=8) in the searchFlags property, the attribute is marked to be preserved when the object is deleted (Recycle Bin is OFF) or when the object is manually or automatically recycled (Recycle Bin is ON). Attributes that are good candidates to be preserved on deletion of the object are for example the password attributes. That helps you to get back up-and-running without setting new passwords and the communication around that when someone makes a mistake and deletes an OU with a large number of user objects. While the Recycle Bin optional feature IS NOT enabled, preserving additional attribute values on the tombstone object (the deleted object) is good if it fits a specific/required purpose. For example, by preserving the data, the impact on the user community is lowered as much as possible. HOWEVER, while the Recycle Bin optional feature IS enabled, all data on an AD object is already preserved by default on a deleted object, whether this flag is enabled or not. Enabling this flag then preserves the data when the deleted object transforms into a recycled object manually or automatically. However recycled objects cannot be undeleted, therefore there is no value in preserving this data on recycled objects. A word of advise: if you have configured additional attributes to be preserved on tombstoned objects, while the Recycle Bin optional feature IS NOT enabled, do not forget to reconfigure those attributes is you are going to enable the Recycle Bin optional feature.

–

ADFIND

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

OR

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

OR

ADFIND -sc TOMBSTONE -dn (sorted output: ADFIND -sc TOMBSTONEL -dn)

–

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:=8))" | %{$_.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:=8))"
$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:=8) with (!(searchFlags:1.2.840.113556.1.4.803:=8))

–

More information:

How the Active Directory Schema Works

–

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

(2015-01-21) Finding Attributes Used In Ambiguous Name Resolution (ANR)

Posted by Jorge on 2015-01-21

When an attribute is defined with the bit 2^2 (=4) in the searchFlags property, the attribute is used in ambiguous name resolution (ANR). Ambiguous Name Resolution (ANR) is an efficient search algorithm in Active Directory that allows you to specify complex filters involving multiple naming-related attributes in a single (filter) clause (e.g. (ANR=jorge)). It can be used to locate objects in Active Directory when you know something about the name of the object, but not necessarily which naming attribute has the information. While ANR is usually used to locate user objects, it can be used to find any class of object in Active Directory. ANR is most used in address book lookups. The list of attributes used in ANR is different per AD version. ANR enabled attributes must be indexed.

–

ADFIND

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

OR

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

OR

ADFIND -sc ANR -dn (sorted output: ADFIND -sc ANRL -dn)

–

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:=4))" | %{$_.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:=4))"
$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:=4) with (!(searchFlags:1.2.840.113556.1.4.803:=4))

–

More information:

–

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

(2015-01-17) Finding Attributes Marked As Non-Replicated

Posted by Jorge on 2015-01-17

When an attribute is defined with the bit 2^0 (=1) in the systemFlags property, the attribute is marked as not replicating between DCs. Constructed attributes are always marked as not replicating as they do not contain any data. Attributes that are kinda DC specific (e.g. lastLogon, logonCount, badPasswordTime, etc.) are also not replicated

–

ADFIND

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

OR

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

OR

ADFIND -sc NOREPL -dn (sorted output: ADFIND -sc NOREPLL -dn)

OR

ADFIND -sc NOREPL+ -dn (sorted output: ADFIND -sc NOREPLL+ -dn) —> for non-replicated attributes that are not links

–

Figure 1: Example Output

–

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(systemFlags: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)(systemFlags: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 (systemFlags:1.2.840.113556.1.4.803:=1) with (!(systemFlags:1.2.840.113556.1.4.803:=1))

–

More information:

How the Active Directory Schema Works

–

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

(2015-01-13) Finding Attributes Marked As System Critical

Posted by Jorge on 2015-01-13

When an attribute is defined with the bit 2^0 (=1) in the schemaFlagsEx property, the attribute is marked as system critical. Any attribute marked as such cannot be made a member of the filtered attribute set (FAS).

–

ADFIND

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

OR

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

OR

ADFIND -sc SYSCRIT -dn (sorted output: ADFIND -sc SYSCRITL -dn)

–

Figure 1: Example Output

–

AD PoSH Module

Get-ADObject -Server R1FSRWDC1.IAMTEC.NET -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(schemaFlagsEx: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)(schemaFlagsEx: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 (schemaFlagsEx:1.2.840.113556.1.4.803:=1) with (!(schemaFlagsEx:1.2.840.113556.1.4.803:=1))

–

More information:

How the Active Directory Schema Works

–

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

« Previous Entries

Jorge's Quest For Knowledge!

All 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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Schema’ Category

(2015-02-20) Finding Attributes Configured To Be Never Audited

(2015-02-16) Finding Attributes Marked To Be Copied When Duplicating The Object

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

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

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

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

(2015-01-25) Finding Attributes Marked To Be Preserved On Deletion Or Recycling

(2015-01-21) Finding Attributes Used In Ambiguous Name Resolution (ANR)

(2015-01-17) Finding Attributes Marked As Non-Replicated

(2015-01-13) Finding Attributes Marked As System Critical

All 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!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Schema’ Category

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: