ADS Active Directory Service (Farsi User Guide)
Resource: Windows 2000 Server Resource kit Distributed Systems Guide

> ADS > Part 1 > Name Resolution in Active Directory > Finding Information in Active Directory > Resolving Names in Directory Operations

Resolving Names in Directory Operations

When any directory operation is requested by a client, the domain controller that is contacted resolves names by using its "knowledge" of the entire directory to determine whether the domain controller can complete the operation or whether it must refer the client to another server for part or all of the operation.

LDAP finds an object in the directory according to the path that is specified in the distinguished name (also known as the "DN") of the object. Every object is stored in the directory database according to its relative distinguished name (also known as the "RDN") and parent identifier, not according to its distinguished name. A distinguished name is a series of relative distinguished names that lead from the object's relative distinguished name to the relative distinguished name at the top of the distinguished name hierarchy. Therefore, if you know the relative distinguished name of an object, you can always determine the full distinguished name by following the references to the parent objects and ultimately to the root object. For example, the distinguished name of a user object might be cn=UserName,ou=OrganizationalUnit,dc=DomainName,...dc=DomainName, where the series of relative distinguished names denoted by dc=DomainName identifies the DNS domain of the object. This portion of the distinguished name can be matched to the tree of domain names that is formed by certain attribute values that are stored in cn=Partitions,cn=Configuration, dc=ForestRootDomain.

Note

The objects in cn=Partitions,cn=Configuration,dc=ForestRootDomain are cross-reference objects; they contain information that Active Directory can use to construct the directory tree hierarchy.

Because every domain controller has the information about all directory partitions in the forest, splitting a distinguished name into a suffix (which identifies the relative path within the domain) and a prefix (the dc= components that identify the domain itself) is always a local operation. If the local domain controller stores a copy of the domain in question, the domain controller can verify the prefix of the distinguished name and perform the requested operation. If the local domain controller does not store a copy of the domain in question, it returns either a referral to another server or an error message

زمانی که فعالیتی برای دسترسی Client به  Active Directory شروع می شود DC باید متوجه بشود که آیا خود باید جوابگو

باشد تمامی  مراحل را یا قسمتی از مراحل را باید به دیگر DC ها بدهد .اما این عمل چگونه انجام می شود و DC چگونه این مورد را متوجه می شود .

LDAP پیدا می کند هر Object را براساس مسیر یا Path موجود در DN آن Object در ADS Database.

از این طریق و با کمک RDN های موجود در DN سیستم می تواند مقصد و یا در واقع Root Object هر Object را بدست آورد و همچنین Parent های آن.

RDN در درون DN وجود دارد و در واقع DN تشکیل شده از RDN های به هم پیوسته که مسیر را تا ROOT خود نمایان می کند .

از این طریق مشخص می شود که برای دسترسی به هر Object باید Client به کدام DC رجوع کند در واقع LDAP اینگونه متوجه می شود که در کجا بدنبال

موضوع  مورد نظر خود برای Client ها بگردد .

Components of an LDAP Search

در این قسمت تقسیم بندی هایی که در یک DN وجود دارد برای دسترسی به هر Object را مشاهده می کنید .

An LDAP search has the potential to retrieve information about all objects within a specific scope that have certain characteristics — for example, the telephone number of every person in a department.

The following are used to accomplish an LDAP search:

  • A search base (the distinguished name of the search base object) defines the location in the directory from which the LDAP search begins.
  • A search scope defines how deep to search within the search base.
    • Base, or zero level, indicates a search of the base object only.
    • One level indicates a search of objects immediately subordinate to the base object, but does not include the base object itself.
    • Subtree indicates a search of the base object and the entire subtree of which the base object distinguished name is the topmost object.
  • A filter allows certain entries in the subtree and excludes others.
  • A selection indicates what attributes to return from objects that match the filter criteria.
  • Optional controls affect how the search is processed.

Figure 3.1 LDAP Search Base and Search Scope

در Figure 3.1  شما می توانید تقسیم بندی های موجود در میان ساختار درختی Object ها و در واقع  DN را مشاهده می کنید نیازی به توضیح بیشتر ندارد.

Figure 3.2 Base Distinguished Name for an LDAP Search

در شکل Figure 3.2 شما یک مثال نیز مشاهده می کنید از یک DN.

 
Search Filters

برای Search کردن اطلاعات درون ADS می توانید از ADSIEdit استفاده کنید برای مثال شما می خواهید جستجو کنید

تمامی User هایی که دارای فامیلی Smith باشند .

برای این کار شما می توانید از Format زیر در ADSIEdit استفاده کنید برای Search.

Filter

Description

(objectCategory=*)

All objects.

(&(objectClass=user)(!(cn=susan)))

All user objects except "susan".

(cn=sm*)

All objects with a surname that starts with "sm".

(&(objectClass=contact)(|(sn=Smith)(sn=Johnson)))

All contacts with a surname equal to "Smith" or "Johnson".

Table 3.1 Common LDAP Search Filters

The search filters shown in Table 3.1 use one of the following formats:

(<attribute><operator><value>)

– Or –

(<operator>(<filter1>)(<filter2>)...)

Table 3.2 shows some of the most frequently used search filter operators.

Operator

Description

=

Equal to

~=

Approximately equal to

<=

Lexicographically less than or equal to

>=

Lexicographically greater than or equal to

&

AND

|

OR

!

NOT

Table 3.2 Commonly Used LDAP Search Filter Operators

برای استفاده مناسب از ADSIEdit یک نمونه مثال در زیر زده شده دقت کنید .

دراینجا برای نمونه در Active Directory به دنبال User هایی می گردیم که آدرس Email آنها دارای کلمه Test باشد .

برای ایجاد یک Query در ADSIEDIT شما باید بر روی Domain Partition باشید سپس Right-Click کرده و گزینه New Query را انتخاب کنید

تذکر اطلاعات مورد نظر را بر روی Domain Partition می توانید بدست آورید بر روی دو Partition دیگرمعمولا موارد دیگری مورد Search قرار می گیرد .

Example 1 (ADSIEdit -New Query)

در مثال بالا در قسمت New Query در ADSIEdit ما مشخص کردیم تمامی User هایی که در Forest وجود دارند و دارای

Email Address می باشند که در درون آن کلمه TEST قرار دارد را نمایش بدهد .این Search در ADS هایی که دارای User های

زیادی می باشد کمک بزرگی به Admin می کند برای دسترسی به اطلاعات مورد نظر خود .در قسمت اول نام Search خود را مشخص می کنید مثلا Email Search.

Root of Search

در این قسمت شما باید ریز بشوید برای محدوده جستجو البته در اینجا خود Domain در نظر گرفته شده که بهتر می باشد .

همانند شکل Example 2 باید Domain را انتخاب کنید .این قسمت همان DN موجود در Figure 3.1 می باشد .

Example 2 (ADSIEdit - New Query - Root of Query)

Query String (Edit Query...)

در این قسمت شما مشخص می کنید که به دنبال چه مواردی می باشید در مثال بالا تمامی User هایی که EMAIL آنها دارای

کلمه Test باشد را مشخص می کند . همانند شکل Example 3 شما می توانید مواردی را که مشاهده می کنید را جستجو کنید .دقیقا تمامی انواع Object های موجود در ADS.

Example 3 (ADSIEdit - New Query - Edit Query)

Query Scope

دو حالت موجود در Figure 3.1 کاملا مشخص شده .وقتی SubTree انتخاب می شود تمامی زیر مجموعه ها نیز Search می شود .

در شکل Example 4 نتیجه این Query بنام EMAIL Search را مشاهده می کنید .

Example 3 (ADSIEdit  New Query "EMAIL SEARCH" )

در اینجا مشخص شده که دو User بنام های Secureuser3 و Test_ADSI2 وجود دارد در Domain که دارای Email Address می باشند

که در نام آن String مانند TEST وجود دارد .این دو User در Active Directory Users and Computer MMC  نیز وجود دارند

از این گونه Search ها می توان در زمانی که تعداد افراد زیاد می باشد استفاده خوبی کرد برای پیدا کردن اطلاعات مد نظر Admin.

Example 4 (Active Directory Users and Computers MMC )

یک نمونه مثال دیگر در زیر وجود دارد از Query String که تمامی افرادی که در قسمت User Properties در Initials آنها کلمه

 EN و یا en وجود دارد را نمایش می دهد .

Example 5 (ADSIEdit - New Query - Edit Query)

Example 6 (ADSIEdit  New Query "ADSI EDIT TEST 2" )

در اینجا پنج User پیدا شد که دارای Initials = en or EN  می باشند.

For more information about the LDAP search query syntax and operators, see the Microsoft Platform SDK link and the Request for Comments (RFC) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. On the Request for Comments (RFC) site, follow the links to RFC 2254.

 

ObjectCategory vs. ObjectClass in a Search Filter

Because of the existence of the class inheritance hierarchy in the schema, every object in Active Directory is in fact a member of many classes — four or five on the average. For this reason, the objectClass index is prohibitively large (for example, 4n, where n is the number of objects in the system). In addition, objectClass has poor selectivity for many possible class values. For example, a search filter of (objectClass=securityPrincipal) returns every user and group object in the system.

On the other hand, objectCategory usually refers to the most specific class in the object's class hierarchy. Although objectClass can have multiple values, the attribute objectCategory has only one. Every Active Directory object has an objectCategory attribute whose value is a classSchema object.

Every classSchema object has an attribute called defaultObjectCategory, which is the object category of an instance of the class if none is specified by the user. For most classes, the defaultObjectCategory value is the class itself. In the search filter, you can specify objectCategory=X, where X is the ldapDisplayName of a class, and LDAP automatically expands the filter to objectCategory=<defaultObjectCategory of class X>. The objectCategory attribute has a syntax of distinguished name, and LDAP automatically converts the value for objectCategory to the distinguished name format. For example, if you use objectCategory=contact in the filter, the filter changes to objectCategory=cn=person,cn=schema,cn=configuration,dc=<ForestRootDomain> ("person" is the defaultObjectCategory for the class contact).

For more information about class inheritance, see "Active Directory Schema" in this book.

 
 
ADS Active Directory Service (Farsi User Guide)

LastUpdate:2005/07/13

> ADS > Part 1 > Name Resolution in Active Directory > Finding Information in Active Directory > Resolving Names in Directory Operations