Иерархическая структура доменов системы windows server носящая общее имя называется

1. ^ ^{a b} «Directory System Agent». MSDN Library. Microsoft. Retrieved 23 April 2014.
2. ^ ^{a b} Solomon, David A.; Russinovich, Mark (2005). «Chapter 13». Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (4th ed.). Redmond, Washington: Microsoft Press. p. 840. ISBN 0-7356-1917-4.
3. ^ ^{a b c} Hynes, Byron (November 2006). «The Future of Windows: Directory Services in Windows Server «Longhorn»«. TechNet Magazine. Microsoft. Archived from the original on 30 April 2020. Retrieved 30 April 2020.
4. ^ «Active Directory on a Windows Server 2003 Network». Active Directory Collection. Microsoft. 13 March 2003. Archived from the original on 30 April 2020. Retrieved 25 December 2010.
5. ^ Rackspace Support (27 April 2016). «Install Active Directory Domain Services on Windows Server 2008 R2 Enterprise 64-bit». Rackspace. Rackspace US, Inc. Archived from the original on 30 April 2020. Retrieved 22 September 2016.
6. ^ «Microsoft Kerberos — Win32 apps». docs.microsoft.com.
7. ^ «Domain Name System (DNS)». docs.microsoft.com.
8. ^ King, Robert (2003). Mastering Active directory for Windows server 2003 (3rd ed.). Alameda, Calif.: Sybex. p. 159. ISBN 9780782152012. OCLC 62876800.
9. ^ Howes, T.; Smith, M. (August 1995). «The LDAP Application Program Interface». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
10. ^ Howard, L. (March 1998). «An Approach for Using LDAP as a Network Information Service». Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
11. ^ Zeilenga, K. (February 2001). «LDAP Password Modify Extended Operation». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
12. ^ Zeilenga, K.; Choi, J.H. (June 2006). «The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
13. ^ Daniel Petri (8 January 2009). «Active Directory Client (dsclient) for Win98/NT».
14. ^ «Dsclient.exe connects Windows 9x/NT PCs to Active Directory». 5 June 2003.
15. ^ ^{a b} Thomas, Guy (29 November 2000). «Windows Server 2008 — New Features». ComputerPerformance.co.uk. Computer Performance Ltd. Archived from the original on 2 September 2019. Retrieved 30 April 2020.
16. ^ «What’s New in Active Directory in Windows Server». Windows Server 2012 R2 and Windows Server 2012 Tech Center. Microsoft.
17. ^ «Compare Active Directory-based services in Azure». docs.microsoft.com.
18. ^ «AD LDS». Microsoft. Retrieved 28 April 2009.
19. ^ «AD LDS versus AD DS». Microsoft. Retrieved 25 February 2013.
20. ^ Zacker, Craig (2003). «11: Creating and Managing Digital Certificates». In Harding, Kathy; Jean, Trenary; Linda, Zacker (eds.). Planning and Maintaining a Microsoft Windows server 2003 Network Infrastructure. Redmond, WA: Microsoft Press. pp. 11–16. ISBN 0-7356-1893-3.
21. ^ «Active Directory Certificate Services Overview». Microsoft TechNet. Microsoft. Retrieved 24 November 2015.
22. ^ «Overview of authentication in Power Apps portals». Microsoft Docs. Microsoft. Retrieved 30 January 2022.
23. ^ «How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates». TechNet. Microsoft. Retrieved 30 January 2022.
24. ^ «Step 1: Preinstallation Tasks». TechNet. Microsoft. Retrieved 21 October 2021.
25. ^ «Test Lab Guide: Deploying an AD RMS Cluster». Microsoft Docs. Microsoft. Retrieved 30 January 2022.
26. ^ Windows Server 2003: Active Directory Infrastructure. Microsoft Press. 2003. pp. 1–8–1–9.
27. ^ «Organizational Units». Distributed Systems Resource Kit (TechNet). Microsoft. 2011. An organizational unit in Active Directory is analogous to a directory in the file system
28. ^ «sAMAccountName is always unique in a Windows domain… or is it?». Joeware. 4 January 2012. Retrieved 18 September 2013. examples of how multiple AD objects can be created with the same sAMAccountName
29. ^ Microsoft Server 2008 Reference, discussing shadow groups used for fine-grained password policies: https://technet.microsoft.com/en-us/library/cc770394%28WS.10%29.aspx
30. ^ «Specifying Security and Administrative Boundaries». Microsoft Corporation. 23 January 2005. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
31. ^ Andreas Luther. «Active Directory Replication Traffic». Microsoft Corporation. Retrieved 26 May 2010. The Active Directory is made up of one or more naming contexts or partitions.
32. ^
    «Sites overview». Microsoft Corporation. 21 January 2005. A site is a set of well-connected subnets.
33. ^ «Planning for domain controllers and member servers». Microsoft Corporation. 21 January 2005. […] member servers, […] belong to a domain but do not contain a copy of the Active Directory data.
34. ^ «What Is the Global Catalog?». Microsoft Corporation. 10 December 2009. […] a domain controller can locate only the objects in its domain. […] The global catalog provides the ability to locate objects from any domain […]
35. ^ «Global Catalog». Microsoft Corporation.
36. ^ «Attributes Included in the Global Catalog». Microsoft Corporation. 26 August 2010. The isMemberOfPartialAttributeSet attribute of an attributeSchema object is set to TRUE if the attribute is replicated to the global catalog. […] When deciding whether or not to place an attribute in the global catalog remember that you are trading increased replication and increased disk storage on global catalog servers for, potentially, faster query performance.
37. ^ «Directory data store». Microsoft Corporation. 21 January 2005. Active Directory uses four distinct directory partition types to store […] data. Directory partitions contain domain, configuration, schema, and application data.
38. ^ «What Is the Active Directory Replication Model?». Microsoft Corporation. 28 March 2003. Domain controllers request (pull) changes rather than send (push) changes that might not be needed.
39. ^ «What Is Active Directory Replication Topology?». Microsoft Corporation. 28 March 2003. SMTP can be used to transport nondomain replication […]
40. ^ «Active Directory Backup and Restore». TechNet. Microsoft. Retrieved 5 February 2014.
41. ^ «AD DS: All domains should have at least two functioning domain controllers for redundancy». TechNet. Microsoft. Retrieved 5 February 2014.
42. ^ Posey, Brien (23 August 2010). «10 tips for effective Active Directory design». TechRepublic. CBS Interactive. Retrieved 5 February 2014. Whenever possible, your domain controllers should run on dedicated servers (physical or virtual).
43. ^ «You may encounter problems when installing SQL Server on a domain controller (Revision 3.0)». Support. Microsoft. 7 January 2013. Retrieved 5 February 2014.
44. ^ Degremont, Michel (30 June 2011). «Can I install SQL Server on a domain controller?». Microsoft SQL Server blog. Retrieved 5 February 2014. For security and performance reasons, we recommend that you do not install a standalone SQL Server on a domain controller.
45. ^ «Installing Exchange on a domain controller is not recommended». TechNet. Microsoft. 22 March 2013. Retrieved 5 February 2014.
46. ^ «Security Considerations for a SQL Server Installation». TechNet. Microsoft. Retrieved 5 February 2014. After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.
47. ^ «Exchange Server Analyzer». TechNet. Microsoft. Retrieved 5 February 2014. Running SQL Server on the same computer as a production Exchange mailbox server is not recommended.
48. ^ «Running Domain Controllers in Hyper-V». TechNet. Microsoft. Planning to Virtualize Domain Controllers. Retrieved 5 February 2014. You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment.frank
49. ^ ^{a b} efleis (8 June 2006). «Large AD database? Probably not this large». Blogs.technet.com. Archived from the original on 17 August 2009. Retrieved 20 November 2011.
50. ^ Berkouwer, Sander. «Active Directory basics». Veeam Software.
51. ^
    Active Directory Service Interfaces, Microsoft
52. ^ «Domain and Forest Trusts Technical Reference». Microsoft Corporation. 28 March 2003. Trusts enable […] authentication and […] sharing resources across domains or forests
53. ^ «Domain and Forest Trusts Work». Microsoft Corporation. 11 December 2012. Retrieved 29 January 2013. Defines several kinds of trusts. (automatic, shortcut, forest, realm, external)
54. ^ «Privileged Access Management for Active Directory Domain Services». docs.microsoft.com.
55. ^ «TechNet Wiki». social.technet.microsoft.com.
56. ^ ^{a b} Edge, Charles S., Jr; Smith, Zack; Hunter, Beau (2009). «Chapter 3: Active Directory». Enterprise Mac Administrator’s Guide. New York City: Apress. ISBN 978-1-4302-2443-3.
57. ^ «Samba 4.0.0 Available for Download». SambaPeople. SAMBA Project. Archived from the original on 15 November 2010. Retrieved 9 August 2016.
58. ^ «The great DRS success!». SambaPeople. SAMBA Project. 5 October 2009. Archived from the original on 13 October 2009. Retrieved 2 November 2009.
59. ^ «RFC 2307bis». Archived from the original on 27 September 2011. Retrieved 20 November 2011.
60. ^ «Active Directory Administration with Windows PowerShell». Microsoft. Retrieved 7 June 2011.
61. ^ «Using Scripts to Search Active Directory». Microsoft. Retrieved 22 May 2012.
62. ^ «ITAdminTools Perl Scripts Repository». ITAdminTools.com. Retrieved 22 May 2012.
63. ^ «Win32::OLE». Perl Open-Source Community. Retrieved 22 May 2012.
64. ^ «Introducing AWS Directory Service for Microsoft Active Directory (Standard Edition)». Amazon Web Services. 24 October 2017.

1. ^ ^{a b} «Directory System Agent». MSDN Library. Microsoft. Retrieved 23 April 2014.
2. ^ ^{a b} Solomon, David A.; Russinovich, Mark (2005). «Chapter 13». Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000 (4th ed.). Redmond, Washington: Microsoft Press. p. 840. ISBN 0-7356-1917-4.
3. ^ ^{a b c} Hynes, Byron (November 2006). «The Future of Windows: Directory Services in Windows Server «Longhorn»«. TechNet Magazine. Microsoft. Archived from the original on 30 April 2020. Retrieved 30 April 2020.
4. ^ «Active Directory on a Windows Server 2003 Network». Active Directory Collection. Microsoft. 13 March 2003. Archived from the original on 30 April 2020. Retrieved 25 December 2010.
5. ^ Rackspace Support (27 April 2016). «Install Active Directory Domain Services on Windows Server 2008 R2 Enterprise 64-bit». Rackspace. Rackspace US, Inc. Archived from the original on 30 April 2020. Retrieved 22 September 2016.
6. ^ «Microsoft Kerberos — Win32 apps». docs.microsoft.com.
7. ^ «Domain Name System (DNS)». docs.microsoft.com.
8. ^ King, Robert (2003). Mastering Active directory for Windows server 2003 (3rd ed.). Alameda, Calif.: Sybex. p. 159. ISBN 9780782152012. OCLC 62876800.
9. ^ Howes, T.; Smith, M. (August 1995). «The LDAP Application Program Interface». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
10. ^ Howard, L. (March 1998). «An Approach for Using LDAP as a Network Information Service». Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
11. ^ Zeilenga, K. (February 2001). «LDAP Password Modify Extended Operation». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
12. ^ Zeilenga, K.; Choi, J.H. (June 2006). «The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation». The Internet Engineering Task Force (IETF). Archived from the original on 30 April 2020. Retrieved 26 November 2013.
13. ^ Daniel Petri (8 January 2009). «Active Directory Client (dsclient) for Win98/NT».
14. ^ «Dsclient.exe connects Windows 9x/NT PCs to Active Directory». 5 June 2003.
15. ^ ^{a b} Thomas, Guy (29 November 2000). «Windows Server 2008 — New Features». ComputerPerformance.co.uk. Computer Performance Ltd. Archived from the original on 2 September 2019. Retrieved 30 April 2020.
16. ^ «What’s New in Active Directory in Windows Server». Windows Server 2012 R2 and Windows Server 2012 Tech Center. Microsoft.
17. ^ «Compare Active Directory-based services in Azure». docs.microsoft.com.
18. ^ «AD LDS». Microsoft. Retrieved 28 April 2009.
19. ^ «AD LDS versus AD DS». Microsoft. Retrieved 25 February 2013.
20. ^ Zacker, Craig (2003). «11: Creating and Managing Digital Certificates». In Harding, Kathy; Jean, Trenary; Linda, Zacker (eds.). Planning and Maintaining a Microsoft Windows server 2003 Network Infrastructure. Redmond, WA: Microsoft Press. pp. 11–16. ISBN 0-7356-1893-3.
21. ^ «Active Directory Certificate Services Overview». Microsoft TechNet. Microsoft. Retrieved 24 November 2015.
22. ^ «Overview of authentication in Power Apps portals». Microsoft Docs. Microsoft. Retrieved 30 January 2022.
23. ^ «How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates». TechNet. Microsoft. Retrieved 30 January 2022.
24. ^ «Step 1: Preinstallation Tasks». TechNet. Microsoft. Retrieved 21 October 2021.
25. ^ «Test Lab Guide: Deploying an AD RMS Cluster». Microsoft Docs. Microsoft. Retrieved 30 January 2022.
26. ^ Windows Server 2003: Active Directory Infrastructure. Microsoft Press. 2003. pp. 1–8–1–9.
27. ^ «Organizational Units». Distributed Systems Resource Kit (TechNet). Microsoft. 2011. An organizational unit in Active Directory is analogous to a directory in the file system
28. ^ «sAMAccountName is always unique in a Windows domain… or is it?». Joeware. 4 January 2012. Retrieved 18 September 2013. examples of how multiple AD objects can be created with the same sAMAccountName
29. ^ Microsoft Server 2008 Reference, discussing shadow groups used for fine-grained password policies: https://technet.microsoft.com/en-us/library/cc770394%28WS.10%29.aspx
30. ^ «Specifying Security and Administrative Boundaries». Microsoft Corporation. 23 January 2005. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
31. ^ Andreas Luther. «Active Directory Replication Traffic». Microsoft Corporation. Retrieved 26 May 2010. The Active Directory is made up of one or more naming contexts or partitions.
32. ^
    «Sites overview». Microsoft Corporation. 21 January 2005. A site is a set of well-connected subnets.
33. ^ «Planning for domain controllers and member servers». Microsoft Corporation. 21 January 2005. […] member servers, […] belong to a domain but do not contain a copy of the Active Directory data.
34. ^ «What Is the Global Catalog?». Microsoft Corporation. 10 December 2009. […] a domain controller can locate only the objects in its domain. […] The global catalog provides the ability to locate objects from any domain […]
35. ^ «Global Catalog». Microsoft Corporation.
36. ^ «Attributes Included in the Global Catalog». Microsoft Corporation. 26 August 2010. The isMemberOfPartialAttributeSet attribute of an attributeSchema object is set to TRUE if the attribute is replicated to the global catalog. […] When deciding whether or not to place an attribute in the global catalog remember that you are trading increased replication and increased disk storage on global catalog servers for, potentially, faster query performance.
37. ^ «Directory data store». Microsoft Corporation. 21 January 2005. Active Directory uses four distinct directory partition types to store […] data. Directory partitions contain domain, configuration, schema, and application data.
38. ^ «What Is the Active Directory Replication Model?». Microsoft Corporation. 28 March 2003. Domain controllers request (pull) changes rather than send (push) changes that might not be needed.
39. ^ «What Is Active Directory Replication Topology?». Microsoft Corporation. 28 March 2003. SMTP can be used to transport nondomain replication […]
40. ^ «Active Directory Backup and Restore». TechNet. Microsoft. Retrieved 5 February 2014.
41. ^ «AD DS: All domains should have at least two functioning domain controllers for redundancy». TechNet. Microsoft. Retrieved 5 February 2014.
42. ^ Posey, Brien (23 August 2010). «10 tips for effective Active Directory design». TechRepublic. CBS Interactive. Retrieved 5 February 2014. Whenever possible, your domain controllers should run on dedicated servers (physical or virtual).
43. ^ «You may encounter problems when installing SQL Server on a domain controller (Revision 3.0)». Support. Microsoft. 7 January 2013. Retrieved 5 February 2014.
44. ^ Degremont, Michel (30 June 2011). «Can I install SQL Server on a domain controller?». Microsoft SQL Server blog. Retrieved 5 February 2014. For security and performance reasons, we recommend that you do not install a standalone SQL Server on a domain controller.
45. ^ «Installing Exchange on a domain controller is not recommended». TechNet. Microsoft. 22 March 2013. Retrieved 5 February 2014.
46. ^ «Security Considerations for a SQL Server Installation». TechNet. Microsoft. Retrieved 5 February 2014. After SQL Server is installed on a computer, you cannot change the computer from a domain controller to a domain member. You must uninstall SQL Server before you change the host computer to a domain member.
47. ^ «Exchange Server Analyzer». TechNet. Microsoft. Retrieved 5 February 2014. Running SQL Server on the same computer as a production Exchange mailbox server is not recommended.
48. ^ «Running Domain Controllers in Hyper-V». TechNet. Microsoft. Planning to Virtualize Domain Controllers. Retrieved 5 February 2014. You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment.frank
49. ^ ^{a b} efleis (8 June 2006). «Large AD database? Probably not this large». Blogs.technet.com. Archived from the original on 17 August 2009. Retrieved 20 November 2011.
50. ^ Berkouwer, Sander. «Active Directory basics». Veeam Software.
51. ^
    Active Directory Service Interfaces, Microsoft
52. ^ «Domain and Forest Trusts Technical Reference». Microsoft Corporation. 28 March 2003. Trusts enable […] authentication and […] sharing resources across domains or forests
53. ^ «Domain and Forest Trusts Work». Microsoft Corporation. 11 December 2012. Retrieved 29 January 2013. Defines several kinds of trusts. (automatic, shortcut, forest, realm, external)
54. ^ «Privileged Access Management for Active Directory Domain Services». docs.microsoft.com.
55. ^ «TechNet Wiki». social.technet.microsoft.com.
56. ^ ^{a b} Edge, Charles S., Jr; Smith, Zack; Hunter, Beau (2009). «Chapter 3: Active Directory». Enterprise Mac Administrator’s Guide. New York City: Apress. ISBN 978-1-4302-2443-3.
57. ^ «Samba 4.0.0 Available for Download». SambaPeople. SAMBA Project. Archived from the original on 15 November 2010. Retrieved 9 August 2016.
58. ^ «The great DRS success!». SambaPeople. SAMBA Project. 5 October 2009. Archived from the original on 13 October 2009. Retrieved 2 November 2009.
59. ^ «RFC 2307bis». Archived from the original on 27 September 2011. Retrieved 20 November 2011.
60. ^ «Active Directory Administration with Windows PowerShell». Microsoft. Retrieved 7 June 2011.
61. ^ «Using Scripts to Search Active Directory». Microsoft. Retrieved 22 May 2012.
62. ^ «ITAdminTools Perl Scripts Repository». ITAdminTools.com. Retrieved 22 May 2012.
63. ^ «Win32::OLE». Perl Open-Source Community. Retrieved 22 May 2012.
64. ^ «Introducing AWS Directory Service for Microsoft Active Directory (Standard Edition)». Amazon Web Services. 24 October 2017.

Содержание

1. Иерархическая структура доменов системы windows server носящая общее имя называется
2. Иллюстрированный самоучитель по Microsoft Windows 2003
3. Иерархия доменов
4. Учебное пособие Издательство Тюменского государственного университета 2009
5. Ключи к тестам для самоконтроля.
6. Вопросы для подготовки к зачету
7. ГЛОССАРИЙ

Содержание

Что такое Active Directory?

Каталог (directory) — на самом деле простой способ упорядочения чего угодно. Каталоги прочно вошли в нашу жизнь. Вы пользуетесь каталогом, отыскивая номер в телефонной книге. То же самое вы делаете, когда организуете файлы и папки на жестком диске своего компьютера.

Потребность в службах каталогов

Традиционный способ обращения с колоссальным объемом информации о сетевых ресурсах — хранение ее в отдельных каталогах, которые обычно управляются приложением или компонентом операционной системы, использующим эту информацию.

Active Directory — не первая служба каталогов. В современных сетях используется несколько служб каталогов и стандартов. Вот лишь некоторые из них:

• Х.500 и Directory Access Protocol (DAP). X.500 — спецификация Internet Standards Organization (ISO), определяющая, как должны быть структурированы глобальные каталоги. Х.500 также описывает применение DAP для обеспечения взаимодействия между клиентами и серверами каталогов;

• Lightweight Directory Access Protocol (LDAP). LDAP была разработана в ответ на критические замечания по DAP, которая оказалась слишком сложной для примене-ния в большинстве случаев. LDAP быстро стала стандартным протоколом каталогов в Интернете.

• Novell Directory Services (NDS). Служба каталогов для сетей Novell NetWare, совместимая со стандартом Х.500.

• Active Directory. Составная часть сетей под управлением Windows Server 2000 или Windows Server 2003. Соответствует стандарту LDAP.

• Централизация

• Масштабируемость

• Стандартизация

• Расширяемость

• Разделение физической памяти

• Безопасность

В сложной сети служба каталогов должна обеспечивать эффективный способ управления, поиска и доступа ко всем ресурсам в этой сети, например к компьютерам, принтерам, общим папкам и т. д. Хорошая реализация службы каталогов дает следующие основные преимущества:

Централизация. Смысл централизации — уменьшение количества каталогов в сети. Включение информации обо всех сетевых ресурсах в централизованный каталог создает единственную точку управления, что упрощает администрирование ресурсов и позволяет эффективнее делегировать административные задачи. Кроме того, в сети появляется единая точка входа для пользователей (или их компьютеров/приложений), когда возникает необходимость в поиске ресурсов.

Масштабируемость. Служба каталогов должна допускать рост сети, не создавая при этом слишком больших издержек. То есть она должна поддерживать какой-либо способ разбиения базы данных каталога на разделы, чтобы не утратить контроль над базой данных из-за ее чрезмерного разрастания и при этом сохранить преимущества централизации.

Стандартизация. Служба каталогов должна предоставлять доступ к своей информации по открытым стандартам. Это гарантирует, что другие приложения смогут использовать ресурсы в Active Directory (и публиковать их в ней), а не поддерживать собственные каталоги.

Расширяемость. Служба каталогов должна тем или иным способом позволять администраторам и приложениям расширять в соответствии с потребностями организации набор информации, хранимой в каталоге.

Разделение физической сети. Благодаря службе каталогов топология физической сети должна быть прозрачной пользователям и администраторам. Ресурсы можно находить (и обращаться к ним), не зная, как и где они подключены к сети.

Безопасность. Служба каталогов была бы крайне полезной злоумышленнику, так как она хранит подробную информацию о данной организации. Поэтому служба каталогов должна поддерживать защищенные средства хранения, управления, выборки и публикации информации о сетевых ресурсах.

AD отделяет логическую структуру иерархии доменов Windows 2003 от физической структуры сети.

Логические компоненты AD

• Объекты: ресурсы хранятся в виде объектов.

  • Классы объектов

  • Схема Active Directory

• Домены: базовая организационная структура.

• Деревья: несколько доменов объединяются в иерархическую структуру.

• Леса: группа из нескольких деревьев домена.

• Организационные единицы: позволяют делить домен на зоны и делегировать на них права.

Логическая структура Active Directory не базируется на физическом местонахождении серверов или сетевых соединениях в пределах домена. Это позволяет структурировать домены, отталкиваясь не от требований физической сети, а от административных и организационных требований.

Объекты

Ресурсы хранятся в Active Directory как объекты.

Объекты хранятся в Active Directory в виде иерархической структуры контейнеров и подконтейнеров, упрощающей поиск, доступ и управление, она во многом похожа на файловую систему Windows с файлами в папками.

Классы объектов. Объект на самом деле представляет собой просто набор атрибутов. Например, объект пользователя (user object) состоит из таких атрибутов, как имя, пароль, телефонный номер, сведения о членстве в группах и т. д. Атрибуты, образующие объект, определяются классом объекта.

Active Directory Schema. Классы и атрибуты, определяемые ими, собирательно называются Active Directory Schema — в терминологии баз данных схема (schema) — это структура таблиц и полей, а также их взаимосвязи. Active Directory Schema можно считать набором данных (классов объектов), определяющим то, как организована и хранится реальная информация (атрибуты объекта) в каталоге.

Домены

Базовая организационная структура в сетевой модели Windows Server 2003 — домен. Домен представляет административную единицу (administrative boundary). Компьютеры, пользователи и другие объекты внутри домена делят общую базу данных защиты (security database).

Домены позволяют администраторам разделять сеть на зоны безопасности (security boundaries). Кроме того, администраторы из разных доменов могут устанавливать свои модели защиты; таким образом, модель защиты одного домена может быть изолирована от моделей защиты других доменов. Домены в основном предназначены для логического деления сети в соответствии с внутренней структурой организации.

Домен Windows Server 2003 также представляет пространство имен, которое соответствует системе именования, давно привычной большинству администраторов сетей: DNS, применяемой в Интернете.

Деревья

Несколько доменов организуется в иерархическую структуру, называемую деревом (tree). На самом деле, даже если в организации лишь один домен, у вас все равно имеется дерево. Первый домен, созданный в дереве, является корневым. Следующий домен считается дочерним по отношению к корневому.

Леса

Лес — это группа из одного или более деревьев доменов, которые не образуют непрерывного пространства имен, но могут совместно использовать общую схему и глобальный каталог. В сети всегда есть минимум один лес, и он создается, когда в сети устанавливается первый компьютер с поддержкой Active Directory (контроллер домена). Первый домен в лесу, называемый корневым доменом леса (forest root domain), играет особую роль, так как на нем хранится схема и он управляет именованием доменов для целого леса. Его нельзя удалить из леса, не удалив сам лес. Кроме того, в иерархии доменов леса нельзя создать домен, который находился бы над корневым.

Организационные единицы

Организационные единицы (organizational units, OU) позволяют разделять домен на зоны административного управления, т. е. создавать единицы административного управления внутри домена. В основном это дает возможность делегировать административные задачи в домене. До появления Active Directory домен был наименьшим контейнером, которому вы могли бы назначить административные разрешения.

Специальный механизм доверительных отношений позволяет объектам в одном домене обращаться к ресурсам в другом домене.

Windows Server 2003 поддерживает шесть типов доверительных отношений:

• Доверие к родительскому и дочернему доменам

• Доверие к корневому домену дерева

• Доверие к внешнему домену

• Доверие к сокращению

• Доверие к сфере

• Доверие к лесу

Поскольку домены разграничивают зоны безопасности, специальный механизм, назы-ваемый доверительными отношениями (trust relationships), позволяет объектам в одном домене [доверяемом (trusted domain)] обращаться к ресурсам в другом [доверяющем (trusting domain)].

Доверие к родительскому и дочернему доменам, а также к корневому домену дерева

Active Directory автоматически выстраивает транзитивные двусторонние доверительные отношения между родительскими и дочерними доменами в дереве доменов. При создании дочернего домена доверительные отношения автоматически формируются между дочерним доменом и его родителем. Эти отношения двусторонние. Доверие также является транзитивным, т. е. контроллеры доверяемого домена пересылают запросы на аутентификацию контроллерам доверяющих доменов.

Двусторонние транзитивные доверительные отношения автоматически создаются и между корневыми доменами деревьев в одном лесу. Это резко упрощает управление доменами по сравнению с тем, что было в версиях Windows, предшествовавших Windows 2000. Вам больше не нужно конфигурировать отдельные односторонние доверительные отношения между доменами.

Внешнее доверие

Внешнее доверие используется, когда нужно создать доверительные отношения между доменом Windows Server 2003 и доменом Windows NT 4.0. Поскольку ограниченные домены (down-level domains) (домены, не поддерживающие Active Directory) не могут участвовать в двусторонних транзитивных доверительных отношениях, следует использовать внешнее доверие. Внешнее доверие является односторонним.

Доверие к сокращению

Доверие к сокращению — это способ создания прямых доверительных отношений между двумя доменами, которые уже могут быть связаны цепочкой транзитивных доверий, но которым нужно оперативнее реагировать на запросы друг от друга.

Доверие к сфере

Доверие к сфере — новшество Windows Server 2003 — служит для подключения домена Windows Server 2003 к сфере Kerberos, которая не поддерживает Windows и использует протокол защиты Kerberos V5. Доверие к сфере может транзитивным или нетранзитивным, одно- или двусторонним.

Доверие к лесу

Доверие к лесу — тоже новшество Windows Server 2003 — упрощает управление несколькими лесами и обеспечивает более эффективное защищенное взаимодействие между ними. Этот тип доверия позволяет обращаться к ресурсам в другом лесу по той же идентификации пользователя (user identification, ID), что и в его собственном лесу.

Разбиение базы данных AD на разделы

Active Directory — набор всех объектов в лесу. По мере роста леса растет и каталог. Одна из проблем, которые пришлось решать при разработке каталога, — как сделать так, чтобы база данных каталога могла увеличиваться по мере расширения организации без ограничений по производительности сервера или по местонахождению в сети. Выход был найден: каталог разделяется на распределенные разделы.

Поскольку домены — основные строительные блоки сети, имеет смысл разделять каталог по границам доменов. Каждый домен содержит раздел каталога, который хранит информацию об объектах в этом домене. Разделы из всех доменов леса образуют полный каталог Active Directory.

Важное преимущество разбиения каталога на разделы по доменам заключается в том, что в лес можно добавлять новые домены, не создавая лишней нагрузки на существующие домены. При добавлении нового домена создается новый раздел, и контроллеры нового домена берут на себя большую часть работы, связанной с управлением этим разделом.

Физическая структура сети с Active Directory довольно проста по сравнению с ее логической структурой. Физическими компонентами являются контроллеры доменов и сайты.

Контроллер домена — это сервер под управлением Windows Server 2003, на котором установлена и работает служба Active Directory. В домене можно создать любое число контроллеров. На каждом контроллере домена хранится полная копия раздела каталога данного домена. Контроллеры домена локально разрешают запросы на информацию об объектах в своем домене и пересылают в другие домены запросы на информацию, отсутствующую в данном домене. Контроллеры домена также отслеживают изменения в информации каталога и отвечают за репликацию этих изменений на другие контроллеры.

Контроллер домена хранит полную копию раздела каталога для своего домена, это означает, что контроллеры следуют модели репликации с несколькими хозяевами (multimaster model). To есть каждый контроллер просто хранит мастер-копию раздела, и с его помощью можно модифицировать эту информацию.

Однако есть роли, которые могут быть присвоены контроллерам домена и при которых выбранный контроллер становится единственным, кому дозволено выполнять упомянутую выше задачу. К таковым относятся роли хозяина операций (operations master roles).

Роли, действующие в границах леса.

Существует две роли хозяина операций, которые могут быть назначены единственному контроллеру домена в лесу:

• Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов определяющих объекты, которые находятся в Active Directory. Если схему нужно обновлять или изменять, наличие Schema Master обязательно;

• Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Domain Naming Master запрашивается при добавлении к лесу новых доменов. Если Domain Naming Master недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру.

Общедоменные роли.

Существует три роли хозяина операций, которые могут быть назначены одному из контроллеров в каждом домене:

• Хозяин RID [Relative Identifier (RID) Master]. Отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект и указывают, где он был создан;

• Эмулятор основного контроллера домена [Primary Domain Controller (PDC) Emulator]. Отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows 2000, Windows Server 2003 или Windows XP и на которых не установлен клиент службы каталогов. Одна из основных задач эмулятора PDC — регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит обращение, если аутентификация клиента оказалась неудачной. Это дает возможность эмулятору PDC проверять недавно измененные пароли для устаревших клиентов в домене, прежде чем отклонять запрос на вход.

• Хозяин инфраструктуры (Infrastructure Master). Регистрирует изменения, вносимые в контролируемые объекты в домене. Обо всех изменениях сначала сообщается Infrastructure Master, и лишь потом они реплицируются на другие контроллеры домена. Infrastructure Master обрабатывает информацию о группах и членстве в них для всех объектов в домене. Еще одна задача Infrastructure Master— передавать информацию об изменениях, внесенных в объекты, в другие домены.

Сервер глобального каталога. Одна из функций сервера, которую можно назначить контроллеру домена. Серверы глобального каталога выполняют две важные функции. Они дают возможность пользователям входить в сеть и находить объекты в любой части леса. Глобальный каталог содержит подмножество информации из каждого доменного раздела и реплицируется между серверами глобального каталога в домене. Когда пользователь пытается войти в сеть или обратиться к какому-то сетевому ресурсу из любой точки леса, соответствующий запрос разрешается с участием глобального каталога. Другая функция глобального каталога, полезная независимо от того, сколько доменов в вашей сети, — участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, его имя сначала сверяется с содержимым глобального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных от того, где хранится нужная пользовательская учетная запись.

Сайт

Сайт Windows Server 2003 — это группа контроллеров доменов, которые находятся в единой или нескольких IP-подсетях и связаны скоростными и надежными сетевыми соединениями. Сайты в основном используются для управления трафиком репликации. Контроллеры доменов внутри сайта могут свободно реплицировать изменения в базу данных Active Directory всякий раз, когда происходят такие изменения. Однако контроллеры доменов з разных сайтах сжимают трафик репликации и передают его по определенному расписанию, чтобы уменьшить сетевой трафик.

Сайты не являются частью пространства имён Active Directory- Когда пользователь просматривает логическое пространство имен, компьютеры и пользователи группируются в домены и OU без ссылок на сайты. Сайты содержат объекты только двух типов. Первые — это контроллеры доменов в границах сайта, а вторые — связи сайта (site links), сконфигурированные для соединения данного сайта с остальными.

Связи сайта. Внутри сайта репликация осуществляется автоматически. Для репликации между сайтами вы должны установить связь между ними. Связь состоит из двух частей: физического соединения между сайтами (обычно WAN-канала) и объекта связи сайта (site link object). Этот объект создается в Active Directory и определяет протокол передачи трафика репликации [Internet Protocol (IP) или Simple Mail Transfer Protocol -SMTP)]. Объект связи сайта также инициирует выполнение запланированной репликации.

Все объекты и атрибуты нужно реплицировать на все контроллеры в домене, чтобы у каждого контроллера была актуальная мастер-копия раздела каталога для данного домена. А это огромный объем передаваемых данных, отслеживать которые весьма трудно.

В Windows Server 2003 применяется модель репликации с несколькими хозяевами (multi-master replication model), в которой все реплики (точные копии) базы данных Active Directory считаются равными хозяевами (equal masters). Вы можете вносить изменения в эту БД на любом контроллере домена, и изменения будут реплицированы на другие контроллеры доменов. Контроллеры доменов в рамках одного сайта выполняют репликацию на основе уведомлений. Когда на одном из контроллеров домена вносятся изменения, он уведомляется своих партнеров по репликации (прочие контроллеры доменов в пределах сайта); затем партнеры запрашивают изменения, и происходит репликация.

Пока вы не сконфигурируете свои сайты в Active Directory, все контроллеры доменов автоматически включаются в один сайт по умолчанию с именем «Default-First-Site-Name», который создается при создании первого домена.

Если вам нужно контролировать трафик репликации по более медленным WAN-каналам, создайте дополнительные сайты.

Сначала рассмотрим репликацию внутри одного сайта:

Внутрисайтовая репликация (intrasite replication). Трафик репликации передается в несжатом виде. В этом случае предполагается, что все контроллеры домена внутри сайта связаны широкополосными соединениями. Более того, репликация происходит по механизму уведомления об изменениях. То есть, если изменения вносятся в домене, они быстро реплицируются на другие контроллеры домена.

Межсайтовая репликация (intersite replication). Все данные передаются в сжатом виде. Здесь учитывается вероятность того, что трафик будет передаваться по более медленным WAN-линиями связи, но нагрузка на серверы возрастает из-за необходимости компрессии/декомпрессии данных. Вы можете использовать не только сжатие, но и планировать репликацию на те периоды времени, которые наиболее оптимальны для вашей организации.

Межсайтовая репликация

Active Directory и DNS тесно интегрируются и даже используют общее пространство имен. А значит, важно, чтобы вы понимали, как устроена каждая из этих систем и как они работают совместно.

DNS — это служба локатора (locator service), используемая Active Directory (и многими другими компонентами Windows). Active Directory делает свои службы доступными в сети, публикуя их в DNS. Когда устанавливается контроллер домена (или к нему добавляются службы), он использует динамические обновления для регистрации своих служб в DNS как записей SRV. После этого клиенты могут находить службы через простые DNS-запросы. По умолчанию служба Microsoft DNS работает на каждом контроллере домена под управлением Windows Server 2003.

Пространство имен DNS в сети отражает пространство имен Active Directory. DNS разделяется на домены. Каждый домен отвечает за записи, хранящиеся в этом домене, и за сопоставление хост-имен и служб с IP-адресами в своих границах. Пространство имен DNS также разделяется на зоны — неразрывные части пространства имен, за управление которыми отвечают определенные серверы. Зона охватывает минимум один домен и может включать другие домены.

• Определение географической модели организации

  • Локальная модель

  • Региональная модель

  • Национальная модель

  • Международная модель

  • Филиалы

  • Дочерние компании

• Создание карты территориального размещения организации

• Сбор сведений о информационных потоках в организации

• Анализ текущей модели администрирования

• Анализ топологии существующей сети

Первый шаг в проектировании структуры AD — определение лесов и доменов.

• Применение одного домена

  • Упрощение управления пользователями и группами

  • Нет необходимости планировать доверительные отношения

  • Для делегирования прав применяются OU

• Применение нескольких доменов

  • Возможность реализации разных политик безопасности

  • Децентрализованное управление

  • Оптимизация трафика

  • Разные пространства имен

  • Необходимо сохранить существующую архитектуру доменов Windows NT

  • Размещение хозяина схемы в отдельный домен

Применение одного домена

Простейшая модель Active Directory — единственный домен. Подавляющее большинство сетей во всем мире позволяет использовать единственный домен, поэтому такая модель, хотя и может показаться не столь гибкой, как другие, обычно заслуживает самого тщательного рассмотрения. В сущности, при планировании структуры Active Directory полезно всегда исходить из предположения, что будет использоваться один домен, и пытаться остаться в рамках этой модели.

В модели с единственным доменом все объекты находятся в одной зоне безопасности, поэтому не приходится заниматься планированием доверительных отношений с другими доменами или реализовать кросс-доменные аутентификацию и разрешения. Кроме того, при использовании одного домена ИТ-отделу гораздо проще обеспечить централизованное управление сетью.

Модель с единственным доменом упрощает управление пользователями и группами, а также реализацию групповых политик. По сути, становится легче выполнять почти все операции по управлению сетью, а значит, требуется меньше усилий на планирование, администрирование и устранение неполадок, что в итоге приведет к сокращению общих затрат.

Домены Active Directory масштабируемы в гораздо большей мере, чем домены Windows NT. Поэтому исчезает существенное препятствие, не позволявшее применять однодоменные сети на основе Windows NT, в которых диспетчер учетных записей безопасности (Security Accounts Manager, SAM) поддерживал только до 40 000 объектов в домене. В отличие от Windows NT в домен Active Directory может входить более миллиона объектов.

• В каждом домене требуется хотя бы один контроллер

• Групповая политика и управление доступом действует на уровне домена

• При создании дочернего домена, между родительским и дочерним доменами автоматически устанавливаются двусторонние транзитивные доверительные отношения, для доменов расположенных далеко друг от друга это не так.

• Административные права, действующие между доменами, выдаются только для Администраторов предприятия

• Необходимо создавать доверяемые каналы

Хотя однодоменная модель дает существенное преимущество — простоту, иногда приходится использовать несколько доменов. Старайтесь планировать домены так, чтобы все они входили в одно дерево доменов. Так как все домены в одном дереве делят одно пространство имен, административные издержки будут значительно ниже, чем при использовании нескольких деревьев. При создании нескольких доменов определять их границы лучше в соответствии с теми разграничениями внутри компании, вероятность изменения которых меньше всего. Например, создание доменов по территориальному принципу, как правило, надежнее, чем создание доменов в соответствии с иерархией подразделений компании, поскольку изменение организационной структуры более вероятно, чем изменение территориальной.

Дерево доменов — это иерархическая структура доменов, использующих единое пространство имен. Первый создаваемый домен становиться корневым, а любой другой дочерним.

Два дерева, представляющие собой два пространства имен

Недостатки:

• Разное пространство имен, поддержка больше DNS-имен

• Проблемы связанные с применением нескольких доменов

• Возможности LDAP клиентов

Дерево доменов — это иерархическая структура доменов, использующих единое пространство имен. Первый домен дерева, который вы создаете, становится корневым для данного дерева, а любой домен, добавляемый в дерево, — дочерним для этого корневого домена. Одна веская причина, по которой может понадобиться несколько деревьев доменов, — поддержка в лесу нескольких пространств имен DNS. Тогда применение нескольких деревьев — это еще и отличный способ объединить отдельные леса, чтобы использовать общие схему и глобальный каталог, в то же время поддерживая разные пространства имен.

Недостатки такого варианта:

• Поскольку у каждого дерева должно быть отдельное пространство имен DNS, ИТ-отделу придется поддерживать больше DNS-имен, чем в случае однодоменной модели.

• Чем больше деревьев, тем больше доменов, поскольку каждое дерево должно содержать минимум один домен. Следовательно, возникнут все проблемы, связанные с применением нескольких доменов.

• Возможно, что LDAP-клиенты (Lightweight Directory Access Protocol), разработанные не Microsoft, не смогут выполнять поиск по глобальному каталогу и вместо этого им придется вести LDAP-поиск по каждому дереву отдельно. В результате увеличится время отклика для таких клиентов.

С учетом этих недостатков имеет смысл подумать об альтернативном решении: объединить пространства имен и использовать одно дерево с разными доменами вместо нескольких деревьев.

Отдельные пространства имен, в одном дереве

Лес — это группа из одного или нескольких деревьев доменов, которые не образуют единое пространство имен, но используют общие схему, конфигурацию каталогов, глобальный каталог и автоматически устанавливают двусторонние транзитивные доверительные отношения между доменами. В сети всегда есть минимум один лес, создаваемый, когда в сети устанавливается первый контроллер домена. Первый домен становится корневым доменом леса.

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен новый тип доверия, введенный в Windows Server 2003, — доверие к лесу (forest trust), применяемое при управлении отношениями между двумя лесами.

Доверие к лесу не является транзитивным на уровне лесов. Другими словами, если первый лес доверяет второму, а второй —третьему, это еще не означает, что первый автоматически доверяет третьему. Также учтите, что для использования доверия к лесу нужно, чтобы оба леса находились на функциональном уровне Windows 2003, т. е. чтобы все контроллеры доменов в обоих лесах работали под управлением Windows Server 2003.

В общем и целом, следует по возможности избегать использования нескольких лесов. Однако есть несколько случаев, в которых может потребоваться реализация нескольких лесов. К этим случаям относятся следующие:

• Объединение двух существующих организаций. Независимо от того, слияние это или поглощение, вы можете столкнуться с тем, что у вас появятся два полностью раздельных леса, которые нужно связать друг с другом для совместного использования ресурсов. Эта связь может быть временной, если в дальнейшем один лес планируется сделать частью другого, или постоянной, если обе компании должны остаться относительно автономными.

• Создание автономного подразделения. Поскольку леса являются крайними зонами безопасности, отдельный лес можно использовать для того, чтобы создать сеть, в которой администрирование в значительной мере независимо от основного леса. В таком случае ИТ-персонал отдельного леса может поддерживать и изменять схему, не оказывая влияния на другие леса.

• Создание изолированного подразделения. Изолированный лес отличается от автономного в первую очередь уровнем полномочий по управлению, доступных администраторам вне леса. В изолированном лесу гарантируется, что администратор вне леса не сможет повлиять на управление им.

Прежде чем приступить к планированию структуры нескольких лесов, вы должны принять к сведению, что большая часть функциональности, доступной в пределах одного леса, недоступна между лесами. Кроме того, поддержка нескольких лесов требует значительно больше усилий в администрировании, чем поддержка одного леса.

Архитектура с несколькими лесами имеет следующие недостатки.

• При поиске ресурсов от пользователей требуется более высокий уровень подготовки. С точки зрения пользователя, поиск ресурсов в рамках одного леса сравнительно прост благодаря единому глобальному каталогу. При наличии нескольких лесов существует несколько глобальных каталогов, и пользователям приходится указывать, в каком лесу вести поиск ресурсов.

• Сотрудникам, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (user principal name, UPN) по умолчанию. От таких сотрудников требуется более высокий уровень подготовки.

• Часто для наблюдения за отдельными лесами и управления ими нужен дополнительный ИТ-персонал, а значит, расходуются средства на подготовку большего штата ИТ-сотрудников и на оплату их труда.

• Администраторам приходится хранить несколько схем.

• Для каждого леса используются отдельные контейнеры конфигурации. Изменения в топологии необходимо реплицировать в другие леса.

• Любую репликацию информации между лесами приходится настраивать вручную. Администраторы должны конфигурировать разрешение DNS-имен между лесами, чтобы обеспечить функционирование контроллеров доменов и поддержку поиска ресурсов.

• Администраторам приходится настраивать списки управления доступом (ACL) к ресурсам, чтобы соответствующие группы из разных лесов могли обращаться к этим ресурсам, а также создавать новые группы, чтобы можно было использовать роли одних лесов в других лесах.

Чтобы найти сетевой ресурс, необходимо знать имя объекта или его одно из его свойств. Active Directory поддерживает несколько типов имен:

• Относительные составные имена

• Составные имена

• Основные имена пользователей

• Канонические имена

Решив, какую структуру доменов и лесов нужно создать, переключите свое внимание на именование элементов, входящих в эту структуру.

LDAP — стандартный протокол, используемый клиентами для поиска информации в каталоге. Служба каталогов, поддерживающая LDAP (например Active Directory), индексирует все атрибуты всех объектов, хранящихся в каталоге, и публикует их. Клиенты, поддерживающие LDAP, могут выполнять всевозможные запросы к серверу.

Каждый объект в Active Directory является экземпляром класса, определенного в схеме Active Directory. У каждого класса имеются атрибуты, обеспечивающие уникальную идентификацию каждого объекта каталога. Чтобы это реализовать, в Active Directory действует соглашение об именовании, позволяющее логически упорядочить хранение объектов и предоставить клиентам стандартизированные методы доступа к объектам. И пользователи, и приложения должны соблюдать соглашение об именовании, используемое каталогом. Чтобы найти сетевой ресурс, вы должны знать его имя или одно из его свойств. Active Directory поддерживает несколько типов имен, поэтому при работе с Active Directory можно использовать разные форматы имен.

Относительное составное имя (RDN) объекта уникально идентифицирует объект, но только в его родительском контейнере. Таким образом, оно уникально идентифицирует объект относительно других объектов в том же самом контейнере. Например, здесь:

CN=wjglenn,CN=Users,OC=kd,DC=ru относительным составным именем объекта является CN=wjglenn. RDN родительской организационной единицы (OU) — Users. У большинства объектов RDN — то же, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации, указываемой при создании объекта, и не допускает, чтобы в одном и том же родительском контейнере существовали два объекта с одинаковыми RDN.

В нотации относительных составных имен применяются специальные обозначения, называемые тэгами LDAP-атрибутов и идентифицирующие каждую часть имени. Существует три тэга атрибутов:

• DC — тэг Domain Component, который идентифицирует часть DNS-имени домена вроде СОМ или ORG.

• OU — тэг Organizational Unit, который идентифицирует организационную единицу, являющуюся контейнером.

• CN — тэг Common Name, который идентифицирует простое имя, присвоенное объекту Active Directory.

У каждого объекта в каталоге имеется составное имя (DN), которое уникально на глобальном уровне и идентифицирует не только сам объект, но и место, занимаемое объектом в общей иерархии объектов. DN можно рассматривать как относительное DN объекта, объединенное с относительными DN всех родительских контейнеров, образующих путь к объекту.

Вот типичный пример составного имени: CN=wjglenn,CN=Users,DC=kd,DC=ru

Это DN означает, что объект пользователя wjglenn содержится в контейнере Users, в свою очередь содержащемся в домене kd.ru. Если объект wjglenn переместят в другой контейнер, его DN изменится и будет отражать новое местоположение в иерархии. DN гарантированно уникальны в лесу — по аналогии с тем, как полное доменное имя (fully qualified domain name, FQDN) уникально идентифицирует местонахождение объекта в иерархии DNS. Существование двух объектов с одинаковыми DN невозможно.

Каноническое имя объекта используется во многом также, как и составное. Просто у него другой синтаксис. Составному имени, приведенному в предыдущем разделе, соответствовало бы следующее каноническое имя: kd.ru/Users/wjglenn

Как видите, в синтаксисе составных и канонических имен два основных отличия. Первое — каноническое имя формируется от корня к объекту, а второе — в каноническом имени не используются тэги LDAP-атрибутов (например CN и DC).

При выработке стратегии именования две роли хозяев операций представляют интерес:

• Хозяин именования доменов

  • Один домен в каждом лесу, обрабатывает добавление и удаление доменов и генерирует уникальный идентификатор защиты (SID)

• Хозяин RID

  • Генерирует последовательности для каждого из контроллеров домена. Действует в пределах домена. Генерирует для каждого контроллера домена пул по 500 RID.

Active Directory используется модель репликации с несколькими хозяевами, при которой на каждом контроллере домена хранится своя копия раздела Active Directory; контроллеры домена являются равноправными хозяевами. Можно внести изменения в объекты, хранящиеся на любом контроллере домена, и эти изменения реплицируются на другие контроллеры.

Модель с несколькими хозяевами хорошо подходит для большинства операций, но не для всех. Некоторые операции должны выполняться только одним контроллером в каждом домене или даже в каждом лесу. Чтобы выполнять эти специальные операции, определенные контроллеры доменов назначаются хозяевами операций.

Однако при выработке стратегии именования представляют интерес две роли хозяев операций: именования доменов (domain naming master) и RID (relative ID master). Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Следует учитывать требования и DNS и AD

• Поддерживается иерархия, длина имени до 64 символов

• Подключение к внешним сетям

Совместимость с NetBios-именами

• Плоская модель, длина имени не более 16 символов

Существует возможность назначать разные NetBios и DNS имена, но такой подход не допустим.

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS. Клиенты используют DNS для разрешения IP-адресов серверов, на которых выполняются важные сетевые сервисы Active Directory. Следовательно, Active Directory и DNS неразрывно связаны.

В DNS имена образуют иерархию и формируются путем «движения» от родительских доменов к дочерним. Так, у домена kd.ru может быть дочерний домен sales.kd.com, у того в свою очередь — дочерний домен europe.sales.kd.ru. Имя каждого домена соответствует пути, идентифицирующему домен в иерархии DNS, т. е. пути к корневому домену (корневой домен обозначается точкой).

Active Directory следует соглашению об именовании, принятому в DNS. Когда вы создаете первый домен Active Directory, он становится корневым для леса и первого дерева доменов в этом лесу. С этого корневого домена начинается пространство имен. Каждый добавляемый домен получает имя от родительского домена и иерархии, в которую входит родительский домен.

Все имена доменов Active Directory идентифицируются по DNS, но можно использовать и NetBIOS-имена (Network Basic Input/Output System) — унаследованную систему именования, которая применялась в старых версиях Windows и по-прежнему поддерживается в Windows Server 2003. Windows автоматически генерирует NetBIOS-имена для каждой службы, выполняемой на компьютере, добавляя к имени компьютера дополнительный символ. Доменам также присваиваются NetBIOS-имена.

Допускается изменение доменных имен после развертывания, но это может оказаться затруднительным. Лучше с самого начала выбрать правильные имена. Выбирая доменные имена, соблюдайте следующие правила:

Используйте только символы, разрешенные стандартами Интернета: а—z, 0—9 и дефис (-). Хотя реализация DNS в Windows Server 2003 поддерживает и другие символы, применение стандартных символов гарантирует возможность взаимодействия с другими реализациями DNS.

Используйте короткие доменные имена, которые легко идентифицировать и которые соответствуют соглашению об именовании в NetBIOS.

В качестве основы имени корневого домена берите только зарегистрированные доменные имена. Даже если вы не используете в качестве имени корня леса зарегистрированное DNS-имя, это поможет избежать путаницы. Например, у компании может быть зарегистрирован домен kd.ru. Если вы не используете kd.ru в качестве имени корневого домена вашего леса, все равно формируйте имя, производное от kd.ru (скажем, sales.kd.ru).

Не используйте дважды одно и то же доменное имя. Иное возможно только в сетях, которые не взаимодействуют между собой (например, вы можете создать домен microsoft.com в частной сети, не подключенной к Интернету), но это плохой подход. Когда-нибудь он обязательно приведет к путанице.

Для большей безопасности создайте отдельные внутреннее и внешнее пространства имен, чтобы предотвратить несанкционированный доступ к закрытым ресурсам. И создавайте внутреннее имя на основе внешнего (например kd.ru и local.kd.ru).

Объекты участников системы безопасности — это объекты AD, которым назначены идентификаторы защиты и которые указываются при входе в сеть (учетные записи пользователей, компьютеров и групп)

При добавлении учетной записи администратор задает:

• Имя используемое для входа в сеть

• Имя домена, содержащего учетную запись

• Прочие атрибуты (имя, фамилия, телефон..)

Имена могут содержать любые символы Unicode, за исключением следующих: #, +, «, , <, >

Объекты участников системы безопасности (security principal objects) — это объекты Active Directory, которым назначены идентификаторы защиты и которые указываются при входе в сеть и предоставлении доступа к ресурсам домена. Администратор должен давать объектам участников системы безопасности (учетным записям пользователей, компьютеров и групп) имена, уникальные в рамках домена. Следовательно, вы должны выработать стратегию именования, которая позволит это делать.

Добавляя в каталог учетную запись нового пользователя, администратор должен задать следующую информацию:

• имя, которое пользователь должен указывать при входе в сеть;

• имя домена, содержащего учетную запись пользователя;

• прочие атрибуты, такие как имя, фамилия, номер телефона и т. д.

В идеале следует создать стратегию именования, определяющую единообразный подход к формированию имен.

• Длина имен учетных записей пользователей не более 20 символов

• Имена учетных записей компьютеров не более 15 символов

• Длина имен учетных записей групп не более 63 символов

• Нельзя использовать только точки, пробелы и знак @

Имена участников системы безопасности не могут состоять только из точек, пробелов и знаков @. Любые точки или пробелы в начале имени пользователя отбрасываются.

Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.kd.ru и sales.kd.ru. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.

Для этого требуется определить, сколько доменов нужно и как организовать эти домены — в одно дерево доменов или в лес. По завершении этого этапа проектирования наступает время переключить внимание на планирование структуры административной защиты каждого домена. По собранной вами информации о компании и ИТ-персонале вы должны определить, как лучше всего делегировать административные полномочия в доменах.

Первый этап проектирования административной структуры защиты — планирование использования организационных единиц (OU) в каждом домене. Следующий этап проектирования этой структуры — выработка стратегии управления учетными записями пользователей, компьютеров и групп. Затем вы должны разработать эффективную реализацию групповой политики.

OU служит контейнером, в который можно поместить ресурсы и учетные записи домена. Затем можно назначить OU административные разрешения и позволить содержащимся в нем объектам наследовать эти разрешения. OU могут содержать любые объекты следующих типов: пользователи; компьютеры; группы; принтеры; приложения; политики безопасности; общие папки; другие OU.

Не следует создавать структуру OU исключительно ради того, чтобы иметь какую-то структуру, — OU используются в определенных целях. К этим целям относятся: делегирование административного управления объектами; ограничение видимости объектов; управление применением групповой политики.

• Делегирование прав администрирования — Существует чтобы облегчить жизнь администраторам

• Ограничение видимости объектов

• Управление применением групповой политикой

Есть две основные архитектуры OU, применяемые для делегирования административных полномочий: на основе объектов и на основе задач. Эти две архитектуры рассматриваются в следующих разделах.

Архитектура основанная на объектах

В структуре OU, основанной на объектах, делегирование полномочий выполняется в зависимости от типа объектов, которые хранятся в OU. Вы можете выбрать структуру OU, в которой объекты группируются по принадлежности к одному из следующих типов: пользователям; компьютерам; сайтам; доменам; OU.

Чтобы делегировать полномочия по администрированию объектов, входящих в OU, определенному пользователю или группе, придерживайтесь следующей схемы. Поместите пользователя или группу, которой требуются административные права, в группу безопасности. Поместите в OU набор объектов, которыми нужно управлять. Делегируйте административные задачи для этой OU группе безопасности, в которую вы добавляли пользователя или группу на этапе 1.

Служба каталогов Active Directory позволяет весьма точно управлять делегированием административных полномочий. Например, можно предоставить одной группе полный доступ ко всем объектам OU, второй — права на создание, удаление и изменение объектов OU определенного типа, а третьей — право управлять определенным атрибутом объектов конкретного типа (скажем, возможностью сбрасывать срок действия паролей учетных записей пользователей). Кроме того, можно сделать эти разрешения наследуемыми, чтобы они применялись не только к данному OU, но и ко всем создаваемым OU более низкого уровня. Такое тонкое управление обеспечивает огромную гибкость.

Если вы выберете структуру OU на основе объектов, то сможете поместить все объекты некоего типа в один контейнер, а затем назначить довольно сложный набор административных разрешений для этих OU, определяющих, что вправе делать каждый администратор. Далее можно создать OU более низкого уровня, управляющие применением групповой политики или решением какие-либо других задач, причем эти OU унаследуют ту же структуру разрешений.

Верхний уровень структуры OU

Правильно разработанная структура OU позволяет администраторам эффективно делегировать полномочия. Следует уделять особое внимание верхнему уровню структуры OU, который всегда должен отражать относительно неизменную часть структуры предприятия, чтобы его не приходилось изменять в случае реорганизации. Так, следующие типы структуры верхнего уровня основаны на постоянных характеристиках предприятия, изменение которых маловероятно.

Физические участки. В филиалах, физически расположенных в разных местах (особенно, когда компания действует на обширной территории, например в нескольких странах), часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к администрированию. Создание отдельного OU верхнего уровня для каждого филиала — один из вариантов архитектуры, основанной на задачах; в зависимости от местонахождения определяются разные административные задачи.

Типы административных задач. Структура верхнего уровня, основанная на административных задачах, относительно постоянна. Какие бы реорганизации не происходили в компании, основные типы административных задач вряд ли сильно изменятся.

Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

При планировании структуры OU верхнего уровня для среды с несколькими доменами, есть смысл подумать о создании структуры верхнего уровня, которая будет одной и той же для каждого домена сети. В этом случае особенно эффективна архитектура, основанная на объектах или на задачах (об этих архитектурах рассказывается далее). Создание структуры OU, одинаковой для различных доменов, позволяет реализовать единый подход к администрированию и поддержке сети.

OU нижних уровней (создаваемые в OU верхнего уровня) должны использоваться для более тонкого управления административными полномочиями или в других целях, например для применения групповой политики. Запомните: по умолчанию OU нижних уровней наследуют разрешения от родительских OU. При планировании архитектуры вы должны определить и то, когда наследуются разрешения и когда они не наследуются.

При проектировании OU нижних уровней легко переусердствовать. Помните: ваша основная задача — получить структуру, максимально облегчающую администрирова-ние учетных записей и ресурсов. Поэтому ваша архитектура должна быть как можно проще. Если вы создадите слишком глубоко вложенную структуру OU, то не только будете иметь дело с более запутанной структурой, но и можете столкнуться со снижением производительности. Групповая политика может применяться к OU на разных уровнях — на уровне домена, сайта и каждого из родительских OU. Чем больше политик нужно применить, тем больше время ответа и тем ниже производительность.

Применение OU для ограничения видимости объектов

В некоторых организациях определенные объекты должны быть скрыты от определенных администраторов или пользователей. Даже если вы запретите изменение атрибутов объекта, пользователи, имеющие доступ к контейнеру с таким объектом, все равно смогут видеть, существует ли этот объект. Однако вы можете скрыть объекты, поместив их в OU и ограничив круг пользователей, которые имеют разрешение Список содержимого (List Contents) для этой OU. Тогда объекты, помещенные в контейнер, будут невидимы пользователям, не имеющим этого разрешения.

Применение OU для управления групповой политикой

Групповая политика позволяет применять одни и те же параметры конфигурации сразу к нескольким объектам. С ее помощью можно определять параметры пользователей (например ограничения, налагаемые на пароли) или компьютеров. При использовании групповой политики вы создаете объект групповой политики (Group Policy Object, GPO) — объект, содержащий параметры конфигурации, которые вам нужно применить. Создав GPO, вы связываете его с доменом, сайтом или OU.

Проектируя структуру OU, управляющую применением групповой политики, старайтесь соблюдать следующие принципы.

Планируйте структуру OU так, чтобы использовать как можно меньше GPO. Чем больше GPO связано с каким-либо объектом, тем больше времени потребуется пользователям, чтобы войти в сеть.

Создавайте OU верхнего уровня, основанные на объектах или задачах, а затем создавайте OU более низких уровней, управляющие групповой политикой.

Создавайте дополнительные OU, чтобы обойтись без фильтрации для изъятия группы пользователей из OU, связанной с GPO.

При установке Active Directory создается несколько контейнеров и OU, используемых по умолчанию.

Контейнер Домен (Domain). Корневой контейнер в иерархии Active Directory. Административные разрешения, применяемые к этому контейнеру, могут влиять на дочерние контейнеры и объекты всего домена. Не делегируйте полномочия на управление этим контейнером — им должны управлять администраторы служб.

Контейнер Встроенный (Built-in). Содержит учетные записи администраторов служб, используемые по умолчанию.

Контейнер Пользователи (Users). Применяемое по умолчанию хранилище учетных записей новых пользователей и групп, создаваемых в домене. Также не следует изменять разрешения на доступ к этому контейнеру, действующие по умолчанию. Если требуется делегировать управление определенными пользователями, создайте новые OU и перенесите в них объекты пользователей. Кроме того, с контейнером Пользователи (Users) нельзя связать GPO. Чтобы применить групповую политику к пользователям, вы также должны создать OU и перенести в них пользователей.

Контейнер Компьютеры (Computers). Применяемое по умолчанию хранилище новых учетных записей компьютеров, создаваемых в домене. Как и в случае контейнера Пользователи (Users), чтобы назначить разрешения или GPO компьютерам, следует создать OU.

OU Контроллеры домена (Domain Controllers). Здесь по умолчанию хранятся учетные записи компьютеров — контроллеров домена. К этому OU по умолчанию применяется ряд политик. Чтобы обеспечить единообразие применения этих политик ко всем контроллерам домена, рекомендуется не переносить объекты-компьютеры, являющиеся контроллерами домена, из этого OU. По умолчанию этим OU управляют администраторы служб. Не делегируйте управление этим OU пользователям, которые не являются администраторами служб.

Существует пять базовых моделей структуры OU:

• На основе местоположения

• На основе структуры организации

• На основе функций

• Смешанная — сначала по местоположению, затем по структуре организации

• Смешанная — сначала по структуре, затем по местоположению

Каждый OU по умолчанию наследует разрешения, заданные для родительского OU. Ана-логично объекты, содержащиеся в OU, наследуют разрешения, заданные для этого OU (и для каждого из его родителей). Наследование — эффективный способ предоставить или делегировать разрешения на доступ к объектам. Преимущество наследования в том, что администратор может управлять разрешениями на доступ ко всем объектам в OU, задавая разрешения для самого OU, а не конфигурируя все дочерние объекты по отдельности.

Бывают ситуации, где наследование препятствует решению нужных задач. Вам может потребоваться, чтобы некоторые разрешения на доступ к объекту переопределяли разрешения, наследуемые объектом от родителей. В таком случае заблокируйте наследование разрешений, применяемых к родительской OU, чтобы они не распространялись на дочернюю OU.

Модель по месту положения

Преимущества:

• OU Устойчивы к изменениям

• Для центрального 1Т-отдела легко реализовать общедоменные политики

• Легко определять положение ресурсов

• Легко создавать новые OU при расширении компании

Недостатки:

• Предполагает наличие в каждом филиале администратора

• Архитектура не соответствует бизнес-структуре или административной структуре

В модели OU на основе местонахождения административные полномочия распределены между несколькими филиалами, расположенными в разных местах. Эта модель полезна, когда у каждого филиала свои требования к администрированию, отличные от требований других филиалов.

Назначение объектов групповой политики сайтам (обычно выполняемое по территориальному признаку) обеспечивает во многом такие же преимущества, что и модель OU на основе местонахождения, но лишено ее недостатков.

Модель на основе структуры организации

Преимущества:

• Обеспечивает определенный уровень автономии для каждого отдела

• Поддерживает слияния и расширения

• Удобна администраторам

Недостатки:

• Уязвима при реорганизации, т.к. может потребоваться изменение верхнего уровня структуры ОU

В модели OU на основе структуры организации административные полномочия распределены между отделами или подразделениями, в каждом из которых имеется собственный администратор. Эта модель полезна, когда у компании есть четкая структура отделов.

Модель на основе функций

Преимущества:

• Устойчивость при реорганизациях

Недостаток:

• Создание дополнительных OU для делегирования административного управления пользователями, компьютерами, принтерами.

В модели OU на основе функций административный персонал децентрализован и использует модель управления, основанную на бизнес-функциях, существующих в организации. Это идеальный выбор для малых компаний, в которых ряд бизнес-функций выполняется несколькими отделами одновременно.

Смешанная модель — по положению

Преимущества:

• Поддерживает рост числа подразделений

• Позволяет создавать зоны безопасности

Недостатки:

• При реорганизации административного персонала, необходимо пересмотреть структуру

• Необходимо взаимодействие между администраторами, работающими в разных отделах одного филиала

В этой модели сначала создаются OU верхнего уровня, представляющие географические участки, на которых находятся филиалы компании, а потом — OU более низкого уровня, представляющие структуру организации.

Смешанная модель — по структуре

Преимущества:

• Надежная защита на уровне отделов и подразделений

• И в тоже время возможность делегировать административные полномочия в зависимости от местоположения

Недостатки:

• Уязвимость при реорганизациях

В этой модели сначала создаются OU верхнего уровня, представляющие организационную структуру компании, а потом — OU более низкого уровня, представляющие территориальные участки.

Типы учетных записей

Учетная запись в Active Directory — это список атрибутов, определяющих участника системы безопасности (security principal), например пользователя или группу пользователей. В Active Directory можно создать пять типов учетных записей, перечисленных ниже.

Компьютер. Всякий раз, когда в домен добавляется компьютер под управлением Microsoft Windows NT, Windows 2000, Windows XP или Windows Server 2003, для него создается учетная запись компьютера. Учетные записи компьютеров служат для аутентификации компьютеров, которые обращаются к сети и ресурсам домена.

Пользователь. Учетная запись пользователя — это набор атрибутов для пользователя. Объект-пользователь хранится в Active Directory и позволяет пользователю входить в сеть. Пользователь должен указать удостоверения (имя и пароль) только один раз, затем ему предоставляются соответствующие разрешения на доступ к сетевым ресурсам.

Группа. Это набор пользователей, компьютеров или других групп, для которого можно задать разрешения. Задавая разрешения группам и добавляя члены в эти группы, можно сэкономить время, поскольку не приходится назначать разрешения каждому отдельно взятому члену группы.

InetOrgPerson. Учетная запись InetOrgPerson работает во многом аналогично учетной записи пользователя за исключением того, что учетные записи InetOrgPerson совместимы с другими службами каталогов, основанными на LDAP (Lightweight Directory Access Protocol). Это обеспечивает совместимость между Active Directory и другими системами.

Контакт. Объект, который хранится в Active Directory, но для которого не задаются разрешения. То есть контакт нельзя использовать для входа в сеть или доступа к ресурсам. Часто контакты связывают с пользователями, работающими вне сети, которым отправляет сообщения почтовая система.

Учетные записи компьютеров позволяют применять к компьютерам, входящим в домен, во многом такие же средства защиты, как и для пользователей. Эти учетные записи дают возможность выполнять аутентификацию компьютеров — членов домена прозрачным для пользователей образом, добавлять серверы приложений как рядовые серверы (member servers) в доверяемые домены и запрашивать аутентификацию пользователей или служб, которые обращаются к этим серверам ресурсов.

Так как разрешается помещать учетные записи компьютеров в OU и назначать им групповую политику, вы можете управлять тем, как выполняется аутентификация и обеспечивается защита компьютеров различных типов. Например, для компьютеров, установленных в общедоступном информационном киоске, действуют другие требова-ния безопасности, чем для рабочих станций, установленных в управляемой среде с ограниченным доступом.

Всякий раз, когда в домен добавляется новый компьютер, создается новая учетная запись компьютера. Таким образом, еще одна составляющая стратегии управления учетными записями — определение пользователей, которые вправе добавлять компьютеры в домен, создавая их учетные записи.

Кроме того, необходимо продумать соглашение об именовании компьютеров. Хорошее соглашение должно позволять без труда идентифицировать компьютер по владельцу, местонахождению, типу или любой комбинации этих данных.

Учетные записи пользователей позволяют идентифицировать пользователей, входящих в сеть, задавать, к каким ресурсам они вправе обращаться, и указывать всевозможную информацию о пользователях. Администраторы — тоже пользователи, но с более широкими правами доступа к ресурсам, связанным с управлением сетью. Группы служат для того, чтобы формировать наборы пользователей, для которых нужно задать одни и те же требования к безопасности или права доступа.

Учетные записи пользователей предоставляют пользователям возможность входить в домен или на локальный компьютер и обращаться к ресурсам. Объекты учетных записей пользователей содержат информацию о пользователях и связывают с ними определенные привилегии или ограничения. Каждый объект Active Directory связан со списком управления доступом (Access Control List, ACL), который представляет собой список разрешений на доступ к объекту, заданных для пользователей и групп.

В Windows Server 2003 существует два основных типа учетных записей пользователей.

Локальные учетные записи пользователей. Создаются в базе данных защиты локального компьютера и управляют доступом к ресурсам этого компьютера. Локальные учетные записи пользователей предназначены для управления доступом к изолированным компьютерам или к компьютерам, входящим в рабочую группу. Когда вы только что установили операционную систему на сервер, используются локальные учетные записи, управление которыми осуществляется через консоль Управление компьютером (Computer Management) в узле Локальные пользователи и группы (Local Users and Groups). Если вы сделаете сервер контроллером домена, инструмент Управление компьютером запретит доступ к этому узлу, и вместо него будет использоваться инструмент Active Directory — пользователи и компьютеры (Active Directory Users and Computers) (учетные записи пользователей на контроллерах домена хранятся в Active Directory).

Доменные учетные записи пользователей. Создаются в Active Directory и дают возможность пользователям входить в домен и обращаться к любым ресурсам сети. Вы можете создать доменную учетную запись пользователя с помощью Active Directory — пользователи и компьютеры (Active Directory Users and Computers). Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.

Встроенные учетные записи пользователей.

Windows автоматически создает несколько учетных записей пользователей, называемых встроенными. И на локальных компьютерах, и в доменах создается две ключевых учетных записи: Администратор (Administrator) и Гость (Guest).

Учетная запись Администратор обладает наибольшими возможностями, поскольку она автоматически включается в группу Администраторы (Administrators). Члены этой группы имеют высший уровень прав по управлению компьютером, им предоставляются почти все пользовательские права. Учетная запись Администратор уровня домена дает максимум возможностей по управлению доменом в целом; по умолчанию она включается в группу Администраторы домена (Domain Admins) [а администратор корневого домена леса, кроме того, входит в группы Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins)]. Учетную запись Администратор нельзя удалить, но ее можно переименовать (и это следует сделать для большей безопасности). Также следует задать для этой учетной записи непустой пароль и не передавать его другим пользователям.

Учетная запись Гость (Guest) — еще одна базовая встроенная учетная запись пользователя. Она предназначена для того, чтобы администратор мог задать единый набор разрешений для любых пользователей, которые иногда входят в сеть, но не имеют обычной учетной записи. Учетная запись Гость позволяет это сделать, так как автоматически включается в локальную группу Гости (Guests). В среде, где есть домен, эта учетная запись также включается в группу Гости домена (Domain Guests). По умолчанию учетная запись Гость отключена. И действительно, ее следует использовать только в сетях, не требующих особой защиты. Эту учетную запись нельзя удалить, но можно отключить и/или переименовать.

• Каждый пользователь должен иметь уникальное имя (логин) в домене

• Длина имени не должна превышать 20 символов (из-за совместимости с предыдущими версиями Windows)

• Имена не чувствительны к регистру букв

• Имена не должны содержать символов: «/[]:; = , + *?< >

• Должна поддерживаться гибкая система именования

• Учитывайте совместимость именования для других приложений (например для электронной почты)

Тщательное планирование схемы именовании учетных записей пользователей позволяет стандартизировать идентификацию пользователей домена. Единое соглашение также облегчает распознавание и запоминание имен пользователей.

Есть несколько правил, которые нужно соблюдать при планировании стратегии именования пользователей.

Существует много разных соглашений, применимых при создании имен, и у каждого администратора или проектировщика сети есть свои предпочтения. Однако хорошее соглашение об именовании должно быть таким, чтобы имена для входа легко запоминались и чтобы можно было различать сотрудников с похожими именами.

• Политика сохранения последних паролей (рекомендуемое значение: 24)

• Политика смены пароля (рекомендуемое значение: 42)

• Смена пароля не чаще чем 1 раз сутки

• Длина пароля на должна быть короче 7 символов

• Используйте сложную схему пароля (строчные, прописные буквы, цифры и другие символы)

Пароли — один из наиболее важных аспектов сетевой безопасности, поэтому политику определения паролей пользователей необходимо тщательно продумать. В Windows Server 2003 по умолчанию действуют более строгие ограничения на пароли, чем в предыдущих версиях. Например, в Windows Server 2003 имеется новое средство, проверяющее сложность пароля учетной записи Администратор (Administrator). Если пароль пустой или недостаточно сложный, Windows предупреждает, что использовать нестойкий пароль опасно. Оставив пароль пустым, вы не сможете обращаться к учетной записи через сеть.

Надежная политика управления паролями гарантирует, что пользователи в полной мере соблюдают принципы задания паролей, установленные компанией. При планировании политики управления паролями следует соблюдать ряд правил.

• Политика блокировки учетных записей (рекомендуемое значение для пользователя 5 попыток)

• Ограничение времени, в которое разрешен вход

• Политика истечения сроков билетов (tickets) (значение по умолчанию 10 часов)

• Не используйте административные учетные записи для обычной работы

• Переименуйте или отключите встроенные учетные записи

Контроллеры домена должны проверять идентификацию пользователя или компьютера прежде чем предоставить доступ к системным и сетевым ресурсам. Такая проверка называется аутентификацией и выполняется всякий раз при входе в сеть.

Типы групп

Группы безопасности

• Используются для объединения в одну административную единицу

• Используются ОС

Группы распространения

• Используются приложениями (не ОС) для задач не связанных с защитой

Области действия групп

Глобальные группы

• Содержат учетные записи пользователей и компьютеров только того домена в котором создана эта группа

• Можно назначать разрешения или добавлять в локальные группы любого домена в данном лесу

Локальные группы домена

• Существуют на контроллерах домена и используются для управления доступом к ресурсам локального домена

• Могут включать пользователей и глобальные группы в пределах леса

Универсальные группы

• Используются для назначение разрешений доступа к ресурсам нескольких доменов

• Существуют вне границ доменов

• Могут включать пользователей, глобальные группы и другие универсальные группы в пределах леса

Группы упрощают предоставление разрешений пользователям. Группы могут быть локальными или доменными. Группы упрощают предоставление разрешений пользователям. Например, назначить разрешения группе и добавить пользователей в эту группу гораздо проще, чем по отдельности назначать разрешения многочисленным пользователям и управлять этими разрешениями. Когда пользователи входят в группу, для изменения того или иного разрешения всех этих пользователей достаточно одной операции.

Как и в случае учетных записей пользователей, группы бывают локальные и уровня домена. Локальные группы хранятся в базе данных защиты локального компьютера и предназначены для управления доступом к ресурсам этого компьютера. Группы уровня домена хранятся в Active Directory и позволяют помещать в них пользователей и управлять доступом к ресурсам домена и его контроллеров.

• Способ упорядочить пользователей

• Глубина вложений должна быть минимальной (желательно 1 уровень вложенности)

• Требования при именовании такие схожи с требованиями для пользователей, но длина до 64 символов

Active Directory позволяет вкладывать группы (т. е. помещать одни группы в другие). Вложение групп — эффективный способ упорядочения пользователей. При вложении групп стремитесь к тому, чтобы уровень вложения был минимальным. В сущности, лучше ограничиться одним уровнем вложения. Чем глубже вложение, тем сложнее поддерживать структуру разрешений.

• Избегайте выдачи разрешений учетным записям

• Создавайте локальные группы домена

• Для упорядочивания пользователей используйте глобальные группы

• Помещайте глобальные группы в локальные группы домена

• Не включайте пользователей в универсальные группы

Итак, вы ознакомились с доступными типами и областями действия групп и планированием учетных записей пользователей. Теперь пора посмотреть, какое место занимают пользователи и группы в стратегии управления учетными записями.

Групповая политика — набор параметров конфигурации пользователей и компьютеров. Называется объектом групповой политики (GPO)

Существует два типа параметров групповой политики:

• Конфигурация компьютера

  • Используется для задания групповых политик, применяемых к определенным компьютерам

• Конфигурация пользователя

  • Используется для задания групповых политик, применяемых к определенным к определенным пользователям

Не зависимо от типа есть три категории:

• Параметры программ

• Параметры Windows

• Административные шаблоны

Групповая политика — мощное и эффективное средство, позволяющее задать параметры сразу для нескольких пользователей и компьютеров. Кроме того, групповая политика применяется для распространения и обновления ПО в организации.

Групповая политика — набор параметров конфигурации пользователей и компьютеров, который можно связать с компьютерами, сайтами, доменами и OU в Active Directory. Такой набор параметров групповой политики называется объектом групповой политики (Group Policy Object, GPO).

Любой компьютер под управлением Windows 2000, Windows ХР или Windows Server 2003 (независимо от того, входит он в Active Directory или нет) содержит один локальный GPO, в котором заданы политики, применяемые к этому компьютеру. Если компьютер входит в Active Directory, к нему можно применить несколько дополнительных GPO, не являющихся локальными.

Существует два основных типа параметров групповой политики.

Параметры применяемые для установки ПО на клиентских ПК (поддерживаются ОС Windows 2000 и более новые)

Используются два компонента:

• Служба установки Windows

  • Установка и обновление ПО в соответствии с инструкциями в установочных пакетах

• Установочные пакеты Windows

  • Исполняемые файлы сценариев со всеми инструкциями (msi)

Узел Параметры программ (Software Settings) содержит параметры, которые можно использовать для развертывания ПО на клиентских компьютерах, к которым применяется групповая политика. Для этого клиентские компьютеры должны работать под управлением Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, Windows XP 64-Bit Edition или Windows Server 2003 и быть членами домена. Вы можете задать, для каких пользователей или на какие компьютеры будет установлено ПО, при необходимости указать обновления и даже удалить ПО. Для поддержки этой функции нужны два взаимодействующих компонента.

Служба установки Windows (Windows Installer service) — служба, которая развертывает и обновляет ПО в соответствии с инструкциями в установочных пакетах Windows (Windows Installer packages)

Установочные пакеты Windows (Windows Installer Packages) — исполняемые файлы сценариев со всеми инструкциями, нужными Windows Installer для установки, обновления или восстановления ПО. Файлы Windows Installer Package имеют расширение msi.

Служба Windows Installer отслеживает состояние устанавливаемого приложения. Эта информация может использоваться для переустановки приложения, восстановления отсутствующих или поврежденных файлов и удаления больше не нужного приложения.

Существует два способа развертывания ПО с помощью групповой политики: публикация (publishing) и назначение (assigning). Когда приложение назначается пользователю, создается ярлык, доступный пользователю и показываемый в меню Пуск (Start) или на рабочем столе этого пользователя. Это называется предложением (advertising) приложения пользователю. Когда пользователь щелкает ярлык (или открывает файл, связанный с программой), запускается программа установки. Когда приложение назначается компьютеру, приложение устанавливается при первом запуске компьютера после назначения.

Если вы публикуете приложение, оно становится доступным пользователям, которые могут установить его, когда пожелают. Приложения можно публиковать только для пользователей — сделать это для компьютера нельзя. Приложение становится доступным в апплете Установка и удаление программ (Add/Remove Programs) панели управления (Control Panel) и устанавливается по запросу пользователя, если тот откроет файл, связанный с программой.

Категория Параметры Windows (Windows Settings) предназначена для изменения ряда параметров конфигурации, связанных со средой Windows.

Сценарии (Scripts). При настройке конфигурации компьютера можно задать сценарии, которые выполняются при его включении или выключении. При настройке конфигурации для пользователя можно задать сценарии, выполняемые при входе или выходе пользователя. Сценарии можно писать на любое языке сценариев с поддержкой ActiveX, в том числе на VBScript, JScript, Perl, языке командных файлов MS-DOS и др.

Параметры безопасности (Security Settings). Это параметры безопасности, задаваемые для компьютеров и пользователей.

Настройка Internet Explorer (Internet Explorer Maintenance). Этот узел доступен только для пользователей. Он служит для управления работой Internet Explorer на клиентских компьютерах.

Службы удаленной установки (Remote Installation Services, RIS). RIS позволяет автоматически выполнять удаленную установку операционной системы на новые клиентские компьютеры. Эти параметры тоже доступны только для конфигураций пользователей. Они управляют удаленной установкой операционных систем.

Перенаправление папок (Folder Redirection). И эти параметры доступны только для конфигураций пользователей. Они позволяют переопределить специальные папки Windows [такие как Мои документы (My Documents), Главное меню (Start Menu) и Application Data], изменив их местонахождение по умолчанию на сетевой каталог. Благодаря этому можно централизованно управлять папками пользователей.

Административные шаблоны

Категория Административные шаблоны (Administrative Templates), доступная для конфигураций компьютеров и пользователей, содержит все параметры групповой политики, хранящиеся в реестре.

Поскольку GPO, применяемые к пользователю или компьютеру, могут поступать из нескольких источников, нужен способ определения того, как эти GPO сочетаются друг с другом. GPO обрабатываются в следующем порядке.

Локальный GPO — обрабатывается локальный GPO компьютера и применяются все параметры защиты, заданные в этом GPO.

GPO сайта — обрабатываются GPO, связанные с сайтом, к которому относится компьютер. Параметры, заданные на этом уровне, переопределяют любые параметры, заданные на предыдущем уровне, с которыми они конфликтуют. Если с сайтом связано несколько GPO, администратор сайта может задать, в каком порядке обрабатываются эти GPO.

GPO домена — обрабатываются GPO, связанные с доменом, к которому относится компьютер, и применяются содержащиеся в них параметры. Параметры, заданные на уровне домена, переопределяют параметры, примененные на локальном уровне или на уровне сайта, с которыми они конфликтуют. Если с доменом связано несколько GPO, администратор, как и в предыдущем случае, может задать порядок их обработки.

GPO OU — обрабатываются GPO, связанные с любыми OU, содержащими пользователя или компьютер. Параметры, заданные на уровне OU, переопределяют параметры, примененные на локальном уровне или уровне домена/сайта, с которыми они конфликтуют. Один и тот же объект может входить в несколько OU. В этом случае сначала обрабатываются GPO, связанные с OU, находящимся на самом высоком уровне иерархии Active Directory, затем — с OU, находящимся на следующем уровне и т.д. Если с одной OU связано несколько GPO, администратор, как и в предыдущих случаях, может задать порядок их обработки.

• Дочерние контейнеры наследуют групповую политику от родительских контейнеров

• Есть возможность переопределить унаследованные параметры

• В GPO можно задавать активность/неактивность и не определенность параметров

• Не противоречивые политики верхнего и нижнего уровней комбинируются, а для несовместимых значений используются значения родительских контейнеров

• Дополнительные механизмы наследования:

  • Не перекрывать

  • Блокировать наследование политик

• Если необходимо не применять политику к пользователю или группе, можно запретить чтение или применение этой политики для данного пользователя или группы

По умолчанию дочерние контейнеры наследуют групповую политику от родительских контейнеров. Однако можно переопределить унаследованные параметры, задав для дочернего объекта другие значения параметров. Кроме того, в GPO можно задать, что тот или иной параметр активен, неактивен или не определен. Параметры, которые не определены для родительского контейнера, вообще не наследуются дочерними контейнерами, а параметры, которые активны или неактивны, наследуются.

Если GPO определены и для родителя, и для потомка и если заданные в них параметры совместимы, эти параметры комбинируются. Например, если в родительской OU задана определенная длина пароля, а в дочерней OU — некая политика блокировки учетных записей, будут использоваться оба этих параметра. Если параметры несовместимы, то по умолчанию с дочерним контейнером связывается значение параметра, переопределяющее значение параметра, который связан с родительским контейнером.

Совет: На вкладке Общие (General) окна свойств GPO можно отключить неиспользуемые параметры конфигурации компьютера или пользователя, содержащиеся в GPO. В большинстве политик задействована лишь часть доступных параметров. Если неиспользуемые параметры включены, они все равно обрабатываются, что приводит к лишнему расходу системных ресурсов. Отключив неиспользуемые параметры, вы снизите нагрузку на клиентские компьютеры, обрабатывающие политику.

Конечно, описанное выше наследование применяется только по умолчанию. Имеется еще два механизма, применяемых при управлении наследованием групповых политик.

Не перекрывать (No Override). Когда вы связываете GPO с контейнером, можно выбрать Не перекрывать, чтобы параметры, заданные в этом GPO, не переопределялись параметрами в GPO, связанных с дочерними контейнерами. Это гарантирует, что для дочерних контейнеров будет применяться заданная вами политика.

Блокировать наследование политики (Block Policy Inheritance). При выборе этого параметра контейнер не наследует параметры GPO, заданные для родительского контейнера. Однако, если для родительского контейнера указан параметр Не перекрывать, дочерний контейнер не может заблокировать наследование от своего родителя.

При реализации групповой политики сначала создают GPO, затем связывают их с сайтами, доменами и OU. Может потребоваться применение некоторых GPO на уровне доменов или сайтов, но в большинстве случаев следует применять GPO на уровне OU.

Связывание GPO с доменом

GPO, связанный с доменом, применяется ко всем пользователям и компьютерам домена. Поскольку это мощная политика, следует свести к минимуму количество GPO этого уровня. Типичное применение GPO уровня домена — реализация корпоративных стандартов. Например, в компании может действовать стандартное требование, состоящее в том, что ко всем компьютерам и пользователям должна применяться одна и та же политика управления паролями и аутентификацией. В этом случае применение GPO уровня домена было бы отличным решением.

Связывание GPO с сайтом

GPO связывают с сайтами очень редко, поскольку гораздо эффективнее связывать GPO с OU, структура которых основана на территориальном делении. Но при определенных обстоятельствах связывание GPO с сайтом — приемлемое решение. Если параметры должны быть общими для всех компьютеров, физически находящихся в определенном месте, и для этого места создан сайт, есть смысл связать GPO с сайтом. Например, для компьютеров, расположенных в некоем филиале, нужно задать определенную сетевую конфигурацию с поддержкой подключения к Интернету. В этом случае идеально подходит GPO, связанный с сайтом.

Связывание GPO с OU

В большинстве случаев лучше связывать GPO с хорошо продуманной структурой OU, чем с сайтами или доменами. OU обеспечивают наибольшую гибкость, поскольку позволяют спроектировать структуру, хотя бы отчасти упрощающую применение групповой политики. Кроме того, OU гибче в администрировании. Вы можете без проблем перемещать пользователей и компьютеры между OU, изменять структуру OU и даже переименовывать сами OU.

Для принятия параметров групповой политики клиентские компьютеры должны быть членами Active Directory. Основные операционные системы обладают следующими возможностями по поддержке групповой политики.

Windows 95/98/Ме не поддерживают групповую политику.

Windows NT 4.0 и более ранних версий не поддерживает групповую политику.

Windows 2000 Professional и Server поддерживают многие параметры групповой политики, доступные в Windows Server 2003, но не все. Неподдерживаемые параметры игнорируются.

Windows XP Professional, Windows XP 64-bit Edition и Windows Server 2003 полностью поддерживают групповую политику.

Планирование сайтов

Сайт — это группа контроллеров домена, существующих в одной или нескольких IP-подсетях, связанных быстрым и надежным сетевым соединением. Поскольку сайты основаны на IP-подсетях, они обычно соответствуют топологии сети, а значит, соответствуют и географической структуре компании. Сайты соединяются с другими сайтами WAN-каналами.

Сайты Active Directory позволяют отделить логическую организацию структуры каталогов (структуры лесов, доменов и OU) от физической структуры сети. Сайты представляют физическую структуру сети на основе Active Directory. Поскольку сайты не зависят от структуры доменов, в один домен может входить несколько сайтов или, наоборот, один сайт может содержать несколько доменов.

Сайты не входят в пространство имен Active Directory- Пользователь, просматривающий логическое пространство имен, видит компьютеры и пользователей, сгруппированных в домены и OU, но сайты при этом не показываются. Однако имена сайтов используются в записях DNS (Domain Name System), поэтому у сайтов должны быть допустимые DNS-имена.

Если вы не конфигурируете в Active Directory собственные сайты, все контроллеры доменов автоматически входят в один сайт по умолчанию с именем Default-First-Site-Name, который создается при создании первого домена.

Сайты содержат объекты только двух типов: контролеры доменов, входящие в сайт, и связи сайтов (site links), настраиваемые для соединения с другими сайтами.

В целом, сайты служат для управления трафиком по WAN-каналам. А конкретнее, сайты используются для управления: трафиком входа на рабочие станции; трафиком репликации; распределенной файловой системой (Distributed File System, DPS); службой репликации файлов (File Replication Service, FRS).

Для разработки топологии сайта необходима

• Информация о физической структуре сети:

• Информация о логической архитектуре AD

Основные принципы:

• Создается для LAN или группы LAN

• Создается для каждого территориального участка с контроллером домена

• Создавайте сайт для участков с сервером, на котором выполняется приложение, работающее с данными о сайтах

Для разработки топологии сайта необходима

• Информация о физической структуре сети:

  • Территориальное местоположение филиалов

  • Структура и скорость LAN филиалов

  • Сведения о TCP/IP-подсетях филиалов

  • Скорость и стоимость WAN-соединений

• Информация о логической архитектуре AD:

  • План лесов

  • План доменов

  • План административной иерархии

Ответственный за топологию сайтов

При планировании сайта следует подумать и о том, кто будет управлять структурой сайта после его развертывания. Ответственным за топологию сайтов назначают администратора (или администраторов). Он должен по мере роста и изменения физической сети вносить необходимые изменения в структуру сайтов. Ответственный за топологию сайтов выполняет следующие обязанности:

• Изменяет топологию сайтов в соответствии с изменениями в физической топологии сети.

• Отслеживает сведения о подсетях в сети: IP-адреса, маски подсетей и местонахождения подсетей.

• Наблюдает за сетевыми соединениями и задает цены связей между сайтами.

После того как вы определили структуру сайтов сети, наступает следующий этап планирования сайтов — определение количества и размещения контроллеров доменов в этих сайтах.

Как определить, нужен ли контроллер домена для данного участка

Первый этап планирования контроллеров доменов в сети — определить, где должны находиться контроллеры. Часто администраторы используют слишком мало контроллеров домена, предполагая, что чем меньше контроллеров у домена, тем проще им управлять. Но бывает, что контроллеров домена, наоборот, слишком много, поскольку администраторы полагают, будто в каждом из участков сети должен быть минимум один контроллер домена. Предположения, выдвигаемые в обоих случаях, вполне могут оказаться правильными, но это не всегда так.

Чтобы определить, нужно ли создать контроллер домена для данного сайта, руководствуйтесь следующими принципами.

Если сайт охватывает много пользователей, помещение контроллера домена в сайт обеспечивает, что при аутентификации пользователей, входящих в сеть, не генерируется сетевой трафик, который нужно передавать на удаленный контроллер домена по WAN-каналу.

Если пользователям нужна возможность входить в домен, даже когда WAN-канал не работает, следует установить контроллер домена в локальном сайте. Если WAN-канал недоступен и нет локальных контроллеров домена, способных обработать запросы на вход в систему, пользователи регистрируются с кэшированными удостоверениями и не могут обращаться к ресурсам других компьютеров.

Если на серверах сайта выполняются приложения, работающие с сайтами, и нужно обеспечить доступ пользователей домена к этим приложениям, установите в этом сайте контроллер домена. Тогда серверы, на которых выполняются такие приложения, смогут выполнять аутентификацию пользователей, обращаясь к локальному контроллеру домена, и не будут генерировать трафик аутентификации, передаваемый по WAN-каналу.

Если сайт является узловым (hub site), т. е. связывает друг с другом остальные сайты меньшего размера, и если у этих сайтов меньшего размера нет своих контроллеров доменов, имеет смысл поместить контроллер домена в узловой сайт, чтобы уменьшить время отклика при входе.

Когда вы добавляете контроллер домена по любой из вышеперечисленных причин, нужно учитывать следующие моменты.

Контроллерами доменов нужно управлять. Устанавливайте контроллеры только там, где есть администраторы, достаточно квалифицированные для того, чтобы управлять контроллерами домена. Если таких администраторов нет, вы должны обеспечить сотрудникам ИТ-отдела уровень доступа, позволяющий удаленно управлять контроллером домена.

Контроллеры домена должны быть защищены. Устанавливайте контроллеры домена только в тех сайтах, в которых можно гарантировать физическую безопасность контроллера.

Как определить количество необходимых контроллеров доменов

Следующий этап — определить, сколько контроллеров доменов требуется на сайте для обслуживания каждого из его доменов.

Количество пользователей домена, входящих на сайт, — основной фактор, влияющий на число контроллеров, необходимых данному домену. Чтобы определить, сколько контроллеров требуется каждому из доменов сайта, руководствуйтесь следующими правилами.

Если данный домен сайта охватывает менее 1000 пользователей, в нем достаточно установить всего один контроллер.

Если данный домен сайта охватывает от 1000 до 10 000 пользователей, в нем требуется установить не менее двух контроллеров.

Для каждых дополнительных 5000 пользователей следует добавлять по одному контроллеру. Например, если на сайт входят 20 000 пользователей домена, в этом домене следует установить четыре контроллера.

Как разместить контроллеры корневого домена леса

Первый домен, создаваемый в новом лесу, называется корневым доменом леса и занимает особое место среди доменов леса. Корневой домен леса закладывает основу структуры леса и пространства имен. Кроме того, данные о группах Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins) уровня леса так-же хранятся в корневом домене леса.

Доверительные отношения между доменами являются транзитивными, и вся аутентификация между разными доменами леса выполняется или через корневой домен леса (т. е. контроллер корневого домена леса), или через специально сконфигурированное доверие к сокращению (shortcut trusts) между региональными доменами. Если один сайт содержит несколько доменов, но корневой домен леса находится в другом сайте, можно определить доверие к сокращению или добавить контроллер корневого домена леса в локальный сайт. Это позволит аутентифицировать пользователей между доменами локального сайта, даже если WAN-канал неработоспособен.

Существуют задачи, которые в отличие от модели репликации с несколькими хозяевами решаются только определенными контроллерами домена. Эти контроллеры выполняют так называемые роли хозяев операций. Хозяева операций (operations masters) — контроллеры домена, которым назначены определенные роли, связанные с обслуживанием домена или леса, и они всегда выполняют функции, специфичные для домена или леса, — никакой другой компьютер не вправе брать на себя эти функции. Такие функции разделены на категории для лучшей управляемости.

В Windows Server 2003 две роли хозяев операций уровня леса.

• Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов, определяющих объекты, которые находятся в Active Directory- Если схему нужно обновлять или изменять, — как, например, в случае установки приложения, которое должно модифицировать классы или атрибуты схемы, — то делать это следует на хозяине схемы [т. е. должен быть доступен контроллер домена (DC), имеющий роль хозяина схемы] одному из членов группы Администраторы схемы (Schema Admins). Если DC, являющийся хозяином схемы, недоступен, а вы должны внести изменения в схему, можно передать эту роль другому DC.

• Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Хозяин именования доменов запрашивается при добавлении к лесу новых доменов. Если хозяин именования доменов недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру. Здесь есть одна тонкость, о которой важно помнить в среде с несколькими доменами: хозяин именования доменов должен быть еще и сервером глобального каталога. Дело вот в чем. Чтобы проверить, является ли уникальным домен, создаваемый в лесу, хозяин именования доменов запрашивает глобальный каталог. Эти две роли автоматически назначаются первому контроллеру домена в лесу. В однодоменной среде (или в лесу с нескольким доменами, в котором все контролле-ры корневого домена леса хранят глобальный каталог) вы должны оставить обе роли хозяев операций уровня леса первому контроллеру, созданному в корневом домене леса.

В лесу с несколькими доменами, в котором глобальный каталог хранится не на всех контроллерах, передайте обе роли хозяев операций уровня леса контроллеру корневого домена леса, не являющемуся сервером глобального каталога.

Роли хозяев операций уровня домена

В Windows Server 2003 три роли хозяев операций уровня домена.

• Эмулятор основного контроллера домена [Primary Domain Controller (PDC) Emulator] отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows Server 2003. Одна из основных задач эмулятора PDC — регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит обращение, если аутентификация клиента оказалась неудачной.

• Хозяин RID [Relative Identifier (RID) Master] отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) — уникальный идентификатор каждого объекта в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект в домене и указывают, где он был создан.

• Хозяин инфраструктуры [Infrastructure Master] регистрирует изменения, вносимые в контролируемые объекты в домене. Обо всех изменениях сначала сообщается хозяину инфраструктуры, и лишь потом они реплицируются на другие контроллеры домена. Хозяин инфраструктуры обрабатывает информацию о группах и членстве в них для всех объектов в домене. Еще одна задача хозяина инфраструктуры — передавать информацию об изменениях, внесенных в объекты, в другие домены. Не назначайте роль хозяина инфраструктуры контроллеру домена, содержащему глобальный каталог, если только этот каталог не хранится на всех контроллерах домена. Это объясняется тем, что хозяин инфраструктуры не будет нормально работать, если он содержит ссылки на объекты, не входящие в домен. Если хозяин инфраструктуры является еще и сервером глобального каталога, то глобальный каталог будет содержать объекты, которые не хранятся на хозяине инфраструктуры, что опять же помешает его работе.

Сервер глобального каталога — это контроллер домена, поддерживающий подмножество атрибутов объектов Active Directory, к которым чаще всего обращаются пользователи или клиентские компьютеры, например регистрационное имя пользователя. Серверы глобального каталога выполняют две важные функции. Они дают возможность пользователям входить в сеть и находить объекты в любой части леса, не обращаясь к конкретным контроллерам доменов, на которых хранятся эти объекты. Active Directory состоит из трех разделов.

Раздел схемы. Хранит определения всех объектов, которые можно создать в лесу, а также их атрибутов. В лесу существует только один раздел схемы. Его копия реплицируется на все контроллеры доменов, входящие в лес.

Раздел конфигурации. Определяет структура доменов, сайтов и объектов-серверов Active Directory. В лесу существует только один раздел конфигурации. Его копия реплицируется на все контроллеры доменов, входящие в лес.

Раздел домена. Служит для идентификации и определения объектов, специфичных для домена. В каждом домене существует свой раздел домена, копия которого реплицируется на все контроллеры этого домена.

Другая функция глобального каталога, полезная независимо от того, сколько доме-нов в вашей сети, — участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, указывая имя участника системы безопасности (user principal name, UPN) вида user@domain.com, оно сначала сверяется с содержимым глобального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных от того, где хранится нужная пользовательская учетная запись. Кроме того, это позволяет входить в сеть, когда контроллер домена недоступен, например из-за того, что не работает WAN-канал.

Под пропускной способностью контроллера домена имеется в виду число пользовате-лей сайта, которое может поддерживать этот контроллер. Администраторы должны понимать требования, предъявляемые к каждому контроллеру домена, и подбирать аппаратное обеспечение в соответствии с этими требованиями, чтобы в дальнейшем не было трудноразрешимых проблем, связанных с тем, что контроллеры доменов не отвечают на запросы пользователей, поскольку не справляются с нагрузкой.

Основной фактор, влияющий на требования к пропускной способности, — количество пользователей домена, которые должны проходить аутентификацию. После того как вы оценили требования к оборудованию с учетом количества пользователей, следует уточнить эти требования — принять во внимание дополнительные роли и службы, которые будут работать на этом контроллере домена.

Определение требований к процессорам

Количество процессоров, необходимых контроллеру домена, в основном зависит от того, сколько пользователей будут входить в домен. Чтобы по числу пользователей, входящих в домен, определить, какие процессоры использовать, руководствуйтесь следующими правилами.

Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше.

Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше.

Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше.

Определение требований к дисковому пространству

Как и требования к процессорам, требования к дисковому пространству в первую очередь зависят от числа пользователей в домене. Чтобы определить требования к дисковому пространству, руководствуйтесь следующими правилами.

На диске, содержащем БД Active Directory (NTDS.dit), для хранения данных о каждой 1000 пользователей необходимо выделить минимум 400 Мб. Сюда входит и пространство, занимаемое разделом DNS.

На диске, содержащем файлы журналов транзакций Active Directory, должно быть минимум 500 Мб свободного места.

На диске, содержащем общие папки SYSVOL, должно быть минимум 500 Мб.

На диске, на который устанавливается ОС Windows Server 2003, должно быть примерно 2 Гб свободного дискового пространства.

Определив минимальный объем дискового пространства, необходимый контроллерам доменов, вы должны выделить дополнительное дисковое пространство на тех контроллерах домена, на которых будет храниться глобальный каталог. Если в лесу только один домен, назначение контроллеру домена роли сервера глобального каталога не приведет к увеличению размера БД. Однако, если в лесу более одного домена, для каждого дополнительного домена размер глобального каталога увеличивается приблизительно на 50% от размера базы данных этого домена.

Определение требований к памяти

И вновь основным фактором, влияющим на требования к объему памяти контроллера домена, является количество пользователей. Чтобы определить требования к памяти контроллера домена, руководствуйтесь следующими правилами.

Если пользователей меньше 500, контроллеру домена требуется 512 Мб памяти.

Если количество пользователей находится в пределах от 500 до 1000, контроллеру домена требуется 1 Гб памяти.

Если пользователей больше 1000, контроллеру домена требуется 2 Гб памяти.

Репликация Active Directory — жизненно важная операция, которую необходимо тщательно планировать. Правильно спланированная репликация ускоряет ответ каталога, уменьшает сетевой трафик по WAN-каналам и сокращает административные издержки.

Процесс репликации

Как вы уже знаете, в Windows Server 2003 используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory. Когда вы создаете, удаляете или переносите объект либо изменяете его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Внутрисайтовая и межсайтовая репликация

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по-разному.

При внутрисайтовой репликации трафик репликации передается в несжатом формате. Это объясняется тем, что контроллеры домена, принадлежащие одному сайту, как предполагается, связаны каналами с высокой пропускной способностью. Помимо того, что данные не сжимаются, используется механизм репликации, основанный на уведомлении об изменениях. Значит, если в данные домена вносятся изменения, эти изменения быстро реплицируются на все контроллеры домена.

При межсайтовой репликации все данные передаются в сжатом виде. Это отражает тот факт, что трафик, вероятно, передается по более медленным WAN-каналам (в сравнении с соединениями локальной сети, используемыми при внутрисайтовой репликации). Однако при этом увеличивается нагрузка на серверы, поскольку, помимо прочих операций по обработке, им приходится упаковывать/распаковывать данные. Кроме того, репликация выполняется по расписанию во время, лучше подходящее данной организации.

Удаленные вызовы процедур выполняются при отправке сообщений репликации внутри сайта и между сайтами. Протокол RPC используется по умолчанию при всех операциях репликации Active Directory, поскольку является отраслевым стандартом и совместим с большинством типов сетей.

SMTP применяется при репликации между сайтами, не связанными постоянными соединениями (необходимыми для работы RPC). Одно из ограничений при использовании SMTP — он не позволяет реплицировать информацию раздела домена (domain partition information) на DC, входящие в домен. Поскольку SMTP применяется только при репликации между сайтами, проблем с репликацией информации раздела домена внутри домена не возникает (в этом случае автоматически используется RPC). То есть SMTP полезен лишь при репликации схемы и глобального каталога.

Как выполняется репликация

Каждый контроллер домена в сайте представляется объектом-сервером. У каждого объекта-сервера есть дочерний объект NTDS Settings, управляющий репликацией данных контроллера домена внутри сайта, а у каждого объекта NTDS Settings — объект-соединение, в котором хранятся атрибуты соединения и который представляет коммуникационный канал, применяемый при репликации данных с одного контроллера домена на другой. Для репликации нужно, чтобы на обеих сторонах было по объекту-соединению.

Сервис Knowledge Consistency Checker (КСС) автоматически создает набор объек-тов-соединений для репликации с одного контроллера домена на другой. Однако при необходимости можно создать объекты-соединения вручную.

КСС создает различные топологии (т. е. задает местонахождение объектов-соедине-ний и их конфигурацию) для внутрисайтовой и межсайтовой репликации. Кроме того, КСС изменяет созданные им топологии всякий раз, когда вы добавляете и удаляете контроллеры домена или перемещаете их из одного сайта в другой.

Транзитивность связей сайтов

Транзитивность связей сайтов и мосты таких связей

По умолчанию связи сайта являются транзитивными. То есть, если связаны сайты А и В, В и С, то сайты А и С также связаны транзитивным соединением. Вы можете отключить транзитивность связей сайтов для заданного транспорта, но это не рекомендуется, кроме особых случаев, когда:

• нужен полный контроль над репликацией;

• требуется исключить определенный путь репликации;

• сеть не обеспечивает полной маршрутизации или же брандмауэр не позволяет напрямую выполнять репликацию между двумя сайтами.

Отключение транзитивности связей сайтов для транспорта влияет на все связи, использующие этот транспорт, — они станут нетранзитивными. Тогда, чтобы поддерживать транзитивные соединения, вам придется создать мосты связей сайтов.

Мосты связей сайтов (site-link bridges) — логические соединения, использующие связи сайтов в качестве транспорта. Когда транзитивность связей включена, между всеми сайтами автоматически создаются логические мосты связей сайтов. А когда транзитивность связей отключена, вы должны создавать такие мосты вручную. На рис. показана простая группа из четырех сайтов, соединенных связями по принципу карусели. Если транзитивность связей для этих сайтов отключена, вам придется вручную создать мосты связей сайтов, чтобы сделать возможной репликацию между всеми сайтами. В основном такие мосты служат для того, чтобы при отключенной транзитивности связей у каждого сайта был путь репликации к другим сайтам. Рассуждайте следующим образом. Когда транзитивность связей включена, между всеми связями сайтов имеются мосты, поэтому все сайты могут обмениваться данными репликации друг с другом. А когда транзитивность отключена, вы должны самостоятельно создать мосты, поскольку связаны только те сайты, между которыми вручную сконфигурированы связи. Мосты связей сайтов передают трафик репликации между соответствующими сайтами по цепочке из нескольких связей.

Назначение цен связям сайтов

Всем связям сайтов назначается цена, которая определяет, насколько данный путь лучше или хуже других связей. По умолчанию все связи имеют цену 100. Если одну связь сделать дороже другой, то при репликации (и при работе других приложений и служб, например Domain Controller Locator) предпочтение будет отдаваться связи с меньшей ценой.

Серверы — плацдармы

После создания связей сайтов КСС автоматически назначает один или несколько контроллеров в каждом домене на роль серверов-плацдармов (bridgehead servers), или серверов репликации между сайтами.

Данные репликации передаются между этими серверами, а не напрямую между всеми контроллерами домена. Запомните, что внутри сайта контроллеры домена (в том числе и серверы репликации между сайтами) выполняют репликацию, как только в ней возникает необходимость. Затем, когда согласно расписанию связи доступны, серверы-плацдармы инициируют репликацию с аналогичными серверами других сайтов через заданный интервал.

Соединения репликации, создаваемые КСС, случайным образом распределяются между всеми серверами сайта, которые могут быть плацдармами репликации между сайтами, — это делается для распределения нагрузки по поддержке репликации. Обычно КСС распределяет соединения, только когда создаются новые объекты-соединения. Однако в Windows Server 2003 Resource Kit имеется утилита Active Directory Load Balancing (ADLB), которую можно использовать для перераспределения ролей серверов-плацдармов в любое другое время (например, при добавлении новых контроллеров домена).

• Планирование DNS

• Планирование WINS

• Планирование инфраструктуры сети и маршрутизации

• Планирование подключения к Интернету

• Планирование стратегии удаленного доступа