Directory Services in Windows Server "Longhorn"
 

مواردی که در این صفحه شرح داده می شود موارد جدیدی می باشد که در Windows "Longhorn" Server وجود دارد.

در Windows 2003 Server ما Active Directory را داشتیم که در Longhorn نامش Active Directory Domain Service ADDS می باشد .

سرویسهای جدیدی به سرور Longhorn اضافه شده مانند :

  • Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, formerly Active Directory/Application Mode, or ADAM), Active Directory Certificate Services (ADCS), and Active Directory Rights Management Services (ADRMS).

در شکل 1 شما میتوانید ADDS را در Server Manager مشاهده کنید بر روی Longhorn Server.

   Figure 1 : Server Manager

    Figure 1 : Server Manager

Functional Levels

بر روی سرورهای Longhorn یک Functional Level اضافه شده بنام Windows Server Longhorn که چیزی به آن اضافه نشده بلکه نام تغییر کرده

زمانی که این گزینه مورد استفاده قرار بگیرد یعنی اینکه کلیه شبکه دارای سرورهای Windows Longhorn Server می باشند .

زمانی که شما این گزینه را انتخاب کنید برای شبکه و سرورهای خود 2 مورد اضافه می شود به شبکه اول EFS دارای قدرت و امکانات بیشتر می شود

دوم اینکه AES شما دارای 256 Bit کد و یا Encryption می شود برای Authentication Kerberos Protocol بر روی ADDS .و در آخر سرعت کار سرور ها

نیز بهتر می شود .

Read-Only Domain Controller  RODC

مهمترین تغییر در ADDS همین RODC می باشد که در این بخش به آن می پردازیم .از این نوع سرور در جاهایی استفاده می شود که ما از امنیت

سرور مطمئن نیستیم و امکان دسترسی به Server می باشد و امنیت از نظر فیزیکی برای سرور وجود ندارد به همین دلیل از RODC استفاده می شود

که بر روی خود AD Database  را دارد اما اطلاعات Account ها و Password آنها را بر روی خود ندارد تااز Crack شدن آنها خیال Admin راحت باشد .

   Figure 2 : Installing the Read-Only Domain Controller

    Figure 2 : Installing the Read-Only Domain Controller

بجز Account Password کلیه Object های Active Directory بر روی یک RODC وجود دارد و نگهداری می شود فقط بر روی

یک Writeable Domain Controller کلیه اطلاعات از جمله Account Password ذخیره می شود .در زمانی که یک Branch Office بخواهد از طریق

WAN با شبکه اصلی خود ارتباط برقرار کند و Replication Traffic را بر قرار کند بدلیل کم بودن سرعت WAN عبور این ترافیک مشکل ایجاد می کند

و کمبود امنیت Brach Office دلایلی می باشد که از RODC می توان استفاده کرد .عمل Replication از طرف یک RODC رخ نمی دهد بلکه همیشه

یک Writeable DC این اطلاعات را برای RODC ارسال می کند .

بر روی RODC شما نمی توانید Password های Domain را پیدا کنید بجز دو Password که یکی krbtgt Account می باشد که همان PWD مربوط به

Authentication Kerberos می باشد.و دوم Computer Account آن RODC می باشد .

زمانی که یک Client یک Request برای Authentication به یک RODC ارسال می کند RODC آن را دریافت کرده و به یک Writeable DC ازسال می کند

اگر عمل Authentication درست انجام شود Client توسط RODC به شبکه وارد می شود .تدکر PWD بر روی RODC بصورت Cache نیز نگهداری

نمی شوند.مگر اینکه شما مشخص کنید که کدام افراد و Account می توانند بر روی RODC بصورت Cache قرار داشته باشند .

زمانی که اطلاعات یک Account بر روی یک RODC بصورت  Cache وجود داشته در زمان بعدی که User بخواهد Login کند از طریق RODC شناسایی

می شود و دیگر یک Requst برای Writeable DC ارسال نمی شود تا زمانی که اطلاعات آن Account تغییر کند و یا پاک شود از روی RODC.

برای امنیت بیشنر یک RODC بهتر است که فقط Account هایی که لازم می باشد که توسط RODC شناسایی شوند بر روی آن Cache شوند

البته هر چه کمتر بهتر می باشد .در نتیجه لازم نمی باشد که کلیه Account های Domain بر روی یک RODC بصورت Cache وجود داشته باشند.

شما می توانید از Password Replication Policy بر روی RODC استفاده کنید و مشخص کنید که کدام Users , Group ها می توانند بر روی یک

RODC بصورت Cache نگهداری شوند .برای مثال شما می توانید برای امنیت بیشتر اجازه ندهید که PWD مربوط به Administrator ها بر روی سرور

Cache شوند و فقط User های آن سرور  را معرفی کنید .بنابر این مشاهده می کنید که می توان این مورد بسیار مهم را کنترل کرد و اگر خطری

احساس شود از طرف Admin می تواند Cache را Reset کرد .

بر روی شکل 3 می تواند دید که چه Account هایی بر روی سرور RODC بصورت Cache نگهداری می شوند.

   Figure 3 : Cached Account Info

    Figure 3 : Cached Account Info

Administrator Role Separation

بر روی Longhorn سرور می توان برای Administrator ها Rule تعریف کرد که برای مثال کدام User ها می توانند تمامی DC ها را مدیریت کنند

و یا کدام Admin هامی توانند فقط RODC را مدیریت کنند .

User Interface and Tool Improvements

برای مدیریت RODC یک Tab جدید بر روی Property  آنها اضافه شده بنام PRP Password Replication Policy که در شکل 4 مشاهده می کنید.

همانند شکل گروهایی که Deny دارند اطلاعات Account های آنها بر روی RODC در زمان Replication ارسال نمی شود و ذخیره نمی شوند .

   Figure 4 : The Password Replication Policy Tab

    Figure 4 : The Password Replication Policy Tab

اگر بر روی Advanced Button کلیک کنید می توانید لیست افراد و یا Account هایی که بر روی سرور RODC وجود دارد را مشاهده کنید همانند

شکل 5.

   Figure 5 : Advanced Password Replication Policy

    Figure 5 : Advanced Password Replication Policy

بر روی شکل 5 شما می توانید لیست افرادی که توسط RODC عمل Authentication برای آنها انجام شده را مشاهده کنید .

از تغییرات دیگری که بر روی RODC و کلا بر روی Longhorn وجود دارد تغییرات بر روی نصب Active Directory می باشد و نیز استفاده از سوئیچ ADV

بر روی Dcpromo بصورت UI در آمده و کاملتر شده .

در زمان نصب برای ADDS شما می توانید براحتی Browse کنید بر روی Domain های یک Forest بدون اینکه

نیازی به تایپ NetBIOS Name آنها داشته باشید .مورد جدید دیگری که وجود دارد در زمان نصب یک ADDS شما می توانید مواردی همچون DNS و GC و

RODC را در همان اول مشخص کنید.و در آخر اینکه در Unattend Files می توان از Dcpromo استفاده کرد .

 
ADDS Auditing

بر روی Windows Server Longhorn موارد جدیدی بر روی Auditing برای ADDS بوجود آمده که در زیر مشاهده می کنید :

  • Directory Service Access

  • Directory Service Changes

  • Directory Service Replication

  • Detailed Directory Service Replication

Microsoft adds a lot more functionality to auditing for directory services in Windows Server "Longhorn." In Windows Server 2003, you could turn auditing on or off for directory access, but even if you had full success auditing enabled, the audit trail did not include what information had been changed. Now, it can.

In Windows Server "Longhorn," the auditing policy for ADDS has the following four subcategories:

  • Directory Service Access
  • Directory Service Changes
  • Directory Service Replication
  • Detailed Directory Service Replication

For most IT pros, there are two key facts to remember about these changes. First, the Directory Service Access auditing gives essentially the same information as it did under Windows Server 2003, but the Event ID is changed from 566 to 4662. Make note of this change if you use tools to parse the security event log. Second, the new category Directory Services Changes records both the previous value and the current value of the changed attribute.

To implement auditing in ADDS, you use the Global Audit Policy, System Access Control Lists (SACLs), and the ADDS schema. The components work together in order to give you both a flexible and comprehensive auditing framework.

The Global Audit Policy controls whether or not any auditing is done on ADDS. If auditing is enabled, the Global Policy controls which of the four subcategories of access (listed earlier) are audited. The Global Audit Policy is usually applied in the Default Domain Controllers Group Policy object, so it applies to the entire directory on the domain controller.

Although the Group Policy tools can turn the Global Audit Policy on or off, you must use the Auditpol.exe command-line tool to view or configure the subcategories. They are not exposed in the graphical user interface.

A SACL is a part of an object's security descriptor. By specifying entries in the SACL, you tell the system two things: which actions and which users (or security principals) you care about. In other words, you specify which users attempting to perform which actions should be recorded in the event log. So if you want to record changes to User objects made by Domain Admins but not by the users themselves, you can control this with SACLs. A SACL applies to an object (and can be defined for new objects, and inherited from container objects).

You can also configure the ADDS schema to limit change auditing to particular attributes. Since SACLs are applied to the object by default, access or changes to any attribute are recorded. This could generate a lot of logging activity, and perhaps not all attributes matter to you. So, at the attribute level, you can set a flag to prevent changes to that attribute from being logged.

SearchFlags is an attribute defined in the class that defines attributes, so it's an attribute of an attribute. It is also a bitmask, where each bit of a one-byte value represents a different on/off setting. You might find it easier to get your head around it by thinking of it as a property of an attribute. In Windows Server 2003, seven of these values are used to control various settings, including the indexing and GC replication of the attribute. In Windows Server "Longhorn," the eighth bit (with a value of 128) is used to control whether or not changes are logged. If this bit is set, ADDS will not log change events when modifications are made to that attribute. This applies to all objects that contain the attribute. In Beta 2, you cannot use the graphical user interface to set the eighth bit.

By default, in Windows Server "Longhorn," the Global Audit Policy is turned on and the Directory Service Changes is set to log successful changes.

 
Restartable ADDS

مورد جالب و مهم دیگری که بر روی Longhorn Server بوجود آمده پایداری سرویس ها و از جمله ADDS می باشد .

شما می توانید ADDS را Stop کنید و یا Start کنید که همان ADDS می باشد

زمانی که Service را Stop می کنید سیستم یک Member Server می شود مورد مهم این می باشد که شما این کار را می توانید بدون نیاز به

Reboot کردن سیستم انجام دهید و نیازی به Reset شدن سرور نمی باشد .

  1. ADDS Started  The domain controller is operating normally.

  2. ADDS Stopped  The server has characteristics of both a domain controller in Directory Services Restore Mode and a domain-joined member server.

  3. Directory Services Restore Mode  This mode (or state) is unchanged from Windows Server 2003.

در زمان ADDS Stop فایل NTDS.DIT یا همان AD Database بصورت Offline می باشد .

در این حالت می توان Logon Locally کرد توسط Account های آن سرور اگر از طریق شبکه DC دیگری وجود نداشته باشد .

    Figure 6 : A Domain Controller on Windows Server 'Longhorn' Can Transition between Three States

    Figure 6 : A Domain Controller on Windows Server 'Longhorn' Can Transition between Three States

 

Looking for More?

It is impossible in one short article to explain the depth of the new ADDS features in Windows Server "Longhorn." But as you saw, new Active Directory features will solve a number of problems you previously had to try to work around or simply live with. As the release of the final version of the product draws near and you want to learn more, rest assured that additional documentation will be made available publicly. For now, the best place to look for updates during the beta phase is the Windows Server "Longhorn" Web site.

در زیر مشخصات نویسنده این مقاله را مشاهده می کنید .

Directory Services in Windows Server "Longhorn"

Byron Hynes works in the Windows Server User Assistance group at Microsoft. In the past, he worked as a consultant and trainer, and has a range of experience including running a regional Internet backbone, troubleshooting client-server and Web-enabled applications, and designing databases schemas, network infrastructure, and security models. You can reach him at bhynes@microsoft.com.

 

Last Updated: December 01, 2006

Winteacher.com
Directory Services in Windows Server "Longhorn"

 © 2003-2006 Winteacher.com . All rights reserved