Asp свойства объектов контейнеров adsi


Содержание

Контейнеры и организационные единицы (OU) — взаимосвязь — отличия — Active Directory

Primary tabs

Forums:

Оснастка Active Directory Users and Computers выглядит аналогично Windows Explorer (Проводник). Она содержит значки папок и объектов, содержащихся в этих папках. Эти папки называются организационными единицами (OU) и контейнерами. Организационные единицы — это папки со значком книги в середине. AD поставляется с OU по умолчанию Domain Controllers (Контроллеры домена). Контейнеры — это папки, не содержащие какого-либо значка.

Контейнер аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имён, но, в отличие от объекта, контейнер не обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.

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

В каталоге Active Directory организационные единицы представляют собой объекты типа «контейнер»

то есть получается — что тип сущности уточняется (грубо говоря )в таком порядке =

или типа — даже такой «пиктограммы» =

то есть -контейнер — это объект — как уже сказали — организационная единица — это объект или нет всё-таки?

Управляем объектами в Active Directory. Часть 1

Архив номеров / 2008 / Выпуск №5 (66) / Управляем объектами в Active Directory. Часть 1

Управляем объектами в Active Directory

Управление объектами в Active Directory осуществляется с помощью соответствующих мастеров. Какие поля при этом изменяются в каталоге Active Directory – покрыто тайной.

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

Создание каждого сценария для начинающего программиста или системного администратора – это битва. Чтобы ее выиграть, необходимо проявить смекалку и сообразительность, перерыть множество источников. Не проще ли, как говорят, поставить все точки над «i»?

Типы объектов в Active Directory

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

Тип объекта определяется набором параметров, которые хранятся в Active Directory в массиве objectClass. Некоторые значения присутствуют везде, например Top, другие строго идентифицируют объект. Избыточность значений необходима для совместимости доменов, построенных на основе Windows 2К и Windows NT.

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

Таблица 1. Взаимосвязь типов объектов Active Directory и значений параметра objectClass

Фрагмент поискового запроса

Учетная запись компьютера

Контакт, используется в почтовых приложениях

Учетная запись пользователя, не совместимая с доменами Windows 2k

Папка дерева каталогов Active Directory

Опубликованный в Active Directory сетевой принтер

Опубликованная в Active Directory сетевая папка

Учетная запись пользователя, совместимая с доменами Windows NT

Механизм поиска объектов рассмотрим после того, как вы получите представление об объектной модели Active Directory.

Параметры объектов в Active Directory

Все параметры объектов можно разделить на три группы:

  • Явно задаваемые. Значения этих параметров напрямую задаются системным администратором. Самый яркий пример – имя объекта.
  • Неявно определяемые. Эти параметры администратор задает завуалированно. К ним относятся тип и местоположение объекта.
  • Скрытые объекты. Эти объекты создаются или изменяются системой. С помощью сценария или мастера их, как правило, невозможно изменить. К таким параметрам относятся SID и GUID объекта, время создания объекта.

Объектная модель Active Directory

Не так давно на сайте Microsoft появилось описание полей Active Directory (http://msdn2.microsoft.com/en-us/library/ms675090(VS.85).aspx).

Описание сделано в стиле Microsoft, т.е. использовать эту информацию по принципу «как есть» невозможно. В ней приведена вся схема каталога в ужасно сокращенном виде, без примеров.

Чтобы посмотреть «начинку» объекта, рекомендуется использовать утилиту (см. рис. 1), недавно созданную сотрудниками Microsoft – Active Directory Explorer 1.01 (http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx), однако она не так удобна в использовании, как хотелось бы.

Рисунок 1. Внешний вид программы Active Directory Explorer 1.01

Существует более удачный вариант – утилита Softerra LDAP Browser (http://www.ldapbrowser.com), о которой я неоднократно упоминал ранее в своих статьях. Безусловно, эта утилита удобнее, но несколько сложнее в использовании.

Управление объектами в Active Directory

Рассмотрим процессы управления объектами с точки зрения взаимосвязей стандартных инструментов, прилагаемых Microsoft, и объектной модели LDAP.

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

С объектами в Active Directory можно проделывать следующие манипуляции: создавать, читать, изменять (если возможно), удалять и, наконец, искать.

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

Учетная запись пользователя

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

Создание учетной записи пользователя. Основные принципы

Для инициализации процесса создания учетной записи необходимо запустить соответствующий мастер в ММС-оснастке Active Directory. Для этого установите курсор на папку, в которой будет создана учетная запись, и, вызвав контекстное меню папки, выберите в нем пункт «New -> User» (см. рис. 2). Выполнив эти действия, системный администратор неявным образом определил местоположение учетной записи будущего пользователя, а именно часть параметра distinguishedName: CN=User,DC=msk, DC=ru и тип объекта – параметра objectClass.

Рисунок 2. Создание учетной записи пользователя

Замечение: если папка является встроенной, то ее имя определяется параметром CN. Все остальные параметры идентифицируются параметром OU (Organizational Unit), например OU=Test,CN=User,DC=msk, DC=ru.

Работа мастера состоит из трех частей. Рассмотрим последовательно каждую из них.

Во время создания учетной записи пользователя на первом шаге необходимо указать фамилию, имя и отчество пользователя. Необязательно задавать все три параметра: достаточно задать один из них. Полное имя (поле 4) формируется на основе Ф.И.О., заданных с помощью первых трех полей. Его значение формируется автоматически, однако администратор может изменить его на любое другое. Первые четыре параметра могут быть позже изменены (см. рис. 3). Для этого необходимо войти в свойства пользователя во вкладку «General» (отображается по умолчанию).

Рисунок 3. Работа мастера «Создание учетной записи пользователя». Шаг 1

Вторая группа параметров – имя пользователя в сети и дополнительное имя, требуемое для связи доменов, построенных на основе Windows NT и Windows 2K. В Active Directory им соответствуют параметры userPrincipal Name и sAMAccountname. Каждое из этих имен состоит из двух частей: имени пользователя и текущего домена. Имя текущего домена определяется автоматически и не может быть изменено. В таблице 2 приведено описание полей, задействованных на первом шаге работы мастера.

Таблица 2. Параметры учетной записи пользователя. Шаг 1

Контейнер или OU

Подскажите пожалуйста, как создать Контейнер в Оснастке «Active Directory Users and Computers»
т.е. папку без значка книги в середине.

потому что создается Подразделение т.е. папка со значком книги в середине.

Рубрика: Администрирование / Администрирование 23.03.2020, 02:25

С помощью cin.getline считать все строки файла в контейнер (вектор или очередь)
Можете пожалуйсто написать код, где можно с помощью cin.getline считать все строки файла в.

Есть ли в Qt контейнер типа «Дек» (deque) или надо свой написать?
Пока не нашёл. Если нет, то от кого лучше унаследоваться, чтобы реализовать?

Из БД в контейнер
Приветствую!! Пишу программу парсер, выгружаю данные из БД. Подскажите, пожалуйста, наилучший.

Контейнер
Здравствуйте, вопрос таков. Как можно сделать так что бы контейнер который имеет position.

24.03.2020, 23:45 [ТС] 2
26.03.2020, 11:22 3

Решение

Чтобы создать контейнер, а не OU:
1. Быть членом группы Schema Admins
2. Открыть оснастку ADSI Edit, слева нажать ПКМ на элементе самого верхнего уровня (ADSI Edit) и нажать «Connect to. »
3. В появившемся окне, в разделе «Connection point», отметить «Select a well known Naming Context» и выбрать Schema в выпадающем меню. Нажать OK
4. Слева выделить «CN=Schema,CN=configuration,DC=. «, справа найти «CN=Container» и зайти в его свойства
5. Изменить атрибут defaultHidingValue на FALSE и нажать OK.
6. Перезапустить оснастку Active Directory Users and Computers, убедится, что в меню View у вас отмечен пункт Advanced Features.
7. Создать контейнер.

P.S. Переводить названия меню и их пунктов было лень
P.P.S. Гуглится по запросу «how to create container in active directory users and computers» — первая же ссылка нерекламная
P.P.P.S. По запросу «как создать в Active Directory контейнер» гуглится статья на тех-нете — может вам оно и надо

26.03.2020, 11:22

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

Контейнер
Привет. Я Си знаю не очень хорошо. Хочу, чтобы помогли разобраться с заданием, понять его. Дана.

контейнер
Создать контейнер, в который можно добавлять и удалять методы. Размер контейнера должен.

Сценарии для Active Directory. Часть 2

Еще два интерфейса Active Directory Scripting Interfaces, которые необходимо знать специалистам по AD.

В первой части статьи я рассказал о том, что при создании сценария для Active Directory (AD) для выполнения 80% задач из более 50 программных интерфейсов Active Directory Scripting Interfaces (ADSI) необходимо использовать только 3. В частности, рассматривался один из трех основных интерфейсов IADsOpenDSObject. Напомню, что интерфейс IADsOpenDSObject содержит метод OpenDSObject, который применяется для аутентификации при соединении с AD. В первой части также была описана терминология AD, ADSI и составных имен (DN). Во второй части я расскажу о двух оставшихся интерфейсах — IADs и IADsContainer.

Ключи к сценарию

Прежде чем подробно рассматривать интерфейсы IADs и IADsContainer, надо сказать несколько слов о той роли, которую они играют. Даже простые задачи при написании сценариев ADSI невозможно решить без использования хотя бы одного из этих интерфейсов. Свойства и методы, которые обеспечивают IADs и IADsContainer, используются для создания, удаления и изменения почти каждого объекта AD. Поэтому тем, кто хочет заниматься написанием ADSI-сценариев, рекомендую запомнить эти два интерфейса. Они включают только полдюжины свойств интерфейсов и с десяток методов, поэтому задача не так сложна, как может показаться на первый взгляд.

Интерфейс IADs

Интерфейс IADs реализуется всеми объектами AD одинаково. Он содержит шесть свойств и семь методов. Шесть свойств IADs, которые перечислены в Таблице 1, дают нам важную информацию об объекте.

Рассмотрим несколько сценариев, в которых будут использоваться свойства IADs. Допустим, требуется использовать ADSI-поставщика OLEDB/ADO и запрос к AD, а затем модифицировать объекты, возвращенные в результатах запроса. Однако записи набора, который возвращает ADSI-поставщик OLEDB/ADO, являются записями только для чтения, поэтому необходимо осуществлять привязку к каждому объекту из результатов запроса, чтобы иметь возможность модифицировать данный объект. Чтобы это сделать, необходимо иметь действительный ADsPath для выполнения операции связывания. Так как каждый объект предоставляет свой ADsPath через интерфейс IADs, можно идентифицировать ADsPath как одно из значений, возвращаемых в результатах запроса. Такой метод рекомендуется применять всякий раз при запросе AD.

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

Глобальный уникальный идентификатор (GUID) — это единственное свойство объекта, которое никогда не изменяется. Свойство GUID используется для привязки к объекту способом, который не зависит от его перемещения и переименования. Свойство Name — это относительное составное имя (RDN); оно представляет собой первичное имя объекта и уникально идентифицирует объект в текущем контейнере. Можно использовать свойства Parent вместе со свойствами ADsPath и Schema, работая с двоичным информационным деревом Directory Information Tree (DIT).

Листинг 1. Свойства схемы через IADs.

Свойство Schema нужно применять для создания ссылки на схему класса объекта для определения обязательных и дополнительных свойств этого объекта, как показано в Листинге 1. После связывания с целевым объектом я вывожу значения шести свойств IADs (см. Листинг 1, метка A). Меткой B в Листинге 1 я пометил путь, с помощью которого свойство Schema объекта обеспечивает связывание с классом схемы объекта. В ответ я получил ссылку на описание пользовательского класса схемы, базирующегося на типе объекта, который отражен в первой строке Листинга 1. Получив ссылку, я отразил содержимое атрибутов must-Contain и mayContain пользовательского класса. На Экране 1 показана часть результатов исполнения Листинга 1.

Экран 1. Частичный вывод на консоль из Листинга 1.

Семь методов IADs, показанных в Таблице 2, обеспечивают механизмы, которые используются для добавления, изменения и удаления данных объекта. Хотя методы IADs просты в применении, некоторые сценарии бывают весьма коварны. Но прежде, чем я расскажу о них, необходимо понять, что такое кэш свойств ADSI.

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

Кэш свойств является адресным пространством объекта, которое ADSI выделяет в тот момент, когда происходит связывание с объектом. Однако сначала кэш пуст. Методы IADs используются для инициализации и взаимодействия со значениями в локальном кэше свойств и нижележащей базой каталога, как показано на Рисунке 1.

Из семи методов IADs только GetInfo, GetInfoEx и SetInfo непосредственно взаимодействуют с базовым каталогом. Get, GetEx, Put и PutEx взаимодействуют только со значениями в кэше свойств, с одним исключением, о котором чуть позже. Процесс, используемый в работе с данными объекта и кэшем свойств, зависит от конкретной задачи. Например, при создании объекта и инициализации его свойств необходимо использовать следующие методы и функции.

  1. Функцию GetObject VBScript — для связывания с целевым контейнером, который будет содержать новый объект (сетевой трафик).
  2. Метод Create IADsContainer — для создания нового объекта в локальном кэше свойств (нет сетевого трафика).
  3. Метод Put или PutEx IADs или оба вместе — для установки новых обязательных и дополнительных свойств объекта в локальном кэше свойств (нет сетевого трафика).
  4. Метод IADs SetInfo — для фиксации (записи) нового объекта или соответствующих свойств в кэше свойств в базе службы каталога (сетевой трафик).

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

  1. Использовать функцию GetObject VBScript для связывания с целевым объектом (сетевой трафик).
  2. Использовать методы GetInfo или GetInfoEx IADs для извлечения свойств объекта из базы службы каталога, чтобы наполнить (инициализировать) локальный кэш свойств (сетевой трафик).
  3. Использовать методы Get или GetEx IADs или оба вместе для чтения свойств в локальном кэше свойств (нет сетевого трафика).
  4. Использовать методы Put или Put-Ex IADs или оба вместе для модификации свойств в локальном кэше свойств (нет сетевого трафика).
  5. Использовать метод IADs SetInfo для фиксации (записи) модифицированных свойств в кэше свойств в базе службы каталога (сетевой трафик).
  6. Использовать методы GetInfo или GetInfoEx IADs для реинициализации локального кэша свойств, чтобы отразить изменения, которые были сделаны на пятом шаге (сетевой трафик).

Теперь применим приобретенные знания для изменения версии сценария easyadsi.vbs, о котором шла речь в первой части статьи. Я использую код Листинга 2 как основу для дальнейшего обсуждения. Мы не будем проходить по сценарию построчно. Я объясню каждый метод IADs, затем приведу пример метода в Листинге 2. Однако я не показываю все доступные методы IADs, поскольку Листинг 2 можно использовать на практике, а некоторые методы IADs применяются редко.

GetInfo. Метод GetInfo извлекает свойства объекта из AD и загружает значения свойства в локальный кэш свойств, инициализируя его. Метод GetInfo загружает в кэш только те свойства, которые содержат значения.

В Листинге 2 метод GetInfo не используется по двум причинам. Во-первых, я создал новый объект пользователя (см. Листинг 2, метка А), поэтому не могу вызвать GetInfo для объекта, которого еще не существует. И хотя я обновил несколько свойств в метке B Листинга 2, я не затрагивал предыдущие значения свойств. Не нужно инициализировать кэш с существующими значениями, если планируется перезаписать значения (если только не требуется по какой-либо причине сохранить старые значения, к примеру, для фиксации изменений в управлении).

Использовать GetInfo в Листинге 2 нужно только в том случае, если требуется проверить новые значения, установленные в метке B. Чтобы это сделать, нужно вызвать GetInfo после вызова SetInfo и обновить значения в кэше. Если вызвать GetInfo перед SetInfo (и после Put-предложений), GetInfo перезапишет кэшированные значения (которые использовали Put и PutEx для модификации) оригинальными или старыми значениями из базы каталога, и изменения не сохранятся.

Хотя использование GetInfo — неплохой метод обновления кэша, он не считается самым эффективным. Например, я обновил три свойства в метке B Листинга 2. Вызов GetInfo после метки B извлекает все значения для более 50 свойств в метке A Листинга 2. Вместо GetInfo лучше применить GetInfoEx.

GetInfoEx. Метод GetInfoEx также инициализирует локальный кэш свойств, извлекая свойства объекта из AD и загружая значения свойства в кэш. Однако GetInfoEx загружает только свойства, перечисленные в массиве свойств, который является первым параметром GetInfoEx. Следовательно, метод GetInfoEx более эффективен для восстановления обновленных значений. Однако, как и в случае с GetInfo, перед вызовом GetInfoEx с именем обновленного свойства следует вызывать SetInfo.

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

Еще одна ситуация, в которой требуется GetInfoEx, связана с тем, что вызовы ADSI не загружают рабочие атрибуты (например, стандартное canonicalName) в кэш. Необходимо использовать GetInfoEx в запросе рабочего атрибута перед его прочтением, как, например, в коде, показанном на Рисунке 2. В противном случае система выдает сообщение об ошибке: «The Active Directory property cannot be found in the cache.»

Рисунок 2. Кэш свойств ADSI.

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

Get возвращает однозначные свойства как скалярные переменные и многозначные свойства как переменные массивы. Метод GetEx возвращает все значения свойств как переменные массивы, поэтому он возвращает однозначное свойство в одноэлементном массиве.

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

Код в Листинге 2 не вызывает Get или GetEx потому, что в возможностях этих методов нет необходимости в силу особенностей сценария, и сам сценарий не производит вывод на консоль или в файл. Если мне нужно отобразить значения свойства, я должен вставить соответствующее предложение вывода, придерживающееся такого же синтаксиса «объект.метод_свойства» (object.propertymet-hod), который использовался для установки значений свойства в метке A Листинга 2. Код на Рисунке 2 представляет собой пример синтаксиса object.propertymethod, который используется совместно с предложением Wscript.Echo.

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

Как показано в Таблице 2, PutEx использует управляющий код для передачи типа выполняемого обновления. По ADS_PROPERTY_APPEND добавляется новое значение в то время, как существующие значения сохра-няются. ADS_PROPERTY_DELETE удаляет определенное значение и оставляет другие значения нетронутыми. Подобно Put, ADS_PROPERTY_UPDATE заменяет все существующие значения новыми, а ADS_PROPERTY_CLEAR удаляет все значения, очищая свойство.

Метка B Листинга 2 указывает на пример использования Put и PutEx. В случае с PutEx я добавил новое значение атрибуту otherHomePhone (замечу, что управлять порядком величин в многозначных свойствах нельзя).

SetInfo. Метод SetInfo записывает новые или модифицирует существующие значения свойства из кэша в AD. Метод SetInfo всегда вызывается явно; когда кэш свойств не инициализирован, SetInfo никогда не активизируется неявным образом, как это происходит в случае с Get или GetEx, вызывающими GetInfo. Любые изменения значений свойства, сделанные Put или PutEx, теряются при вызове GetInfo или, может быть, перед вызовом SetInfo. Можно использовать один вызов SetInfo для внесения целого ряда изменений, но необходимо понимать, что SetInfo — это бескомпромиссная операция типа «все или ничего». Т. е. SetInfo записывает все изменения, сделанные до вызова SetInfo, в базу каталога или не вносит изменений, если происходит ошибка (например, при нарушении требований системы безопасности).

Синтаксические соглашения object.pro-pertymethod. Синтаксис object.propertymethod — это соглашение, которое OLE-клиенты могут использовать вместо Get или Put. Синтаксис позволяет программистам на Visual Basic (VB) и VBScript использовать привычную нотацию dotMethodOrPro-pertyName. Синтаксис состоит из двух частей, отделенных точкой (.). Имя слева от точки является объектной ссылкой; имя справа от нее — это отображаемое имя атрибута, извлекаемого или записываемого в кэш, написанное по правилам Lightweight Directory Access Protocol (LDAP). Использование синтаксиса object.propertymethod в правой части оператора присваивания или выражении эквивалентно Get. Использование этого синтаксиса в левой стороне оператора присваивания эквивалентно Put. Требования к поведению синтаксиса object.propertymethod — те же самые, что и к Get и Put (т. е. те же типы возвращаемых Get результатов и ограничения на Put при обновлении многозначных свойств).

Я использовал object синтаксис .propertymethod в метке A Листинга 2 для установки исходных значений как для однозначных, так и многозначных свойств. В метке B Листинга 2 я задействовал Put и PutEx, поскольку обновил многозначное свойство под именем otherHomePhone.

Интерфейс IADsContainer

Интерфейс IADsContainer служит для управления жизненным циклом объектов AD. Контейнерные объекты создают иерархию и образуют организацию DIT. Каждый контейнерный объект в AD реализует IADs Container. IADsContainer имеет четыре свойства, которые перечислены в Таблице 3, и пять методов, указанных в Таблице 4.

Из четырех свойств IADsContainer два доступны через провайдера LDAP. Тем не менее можно использовать непосредственно и VBScript, вызвав только одно свойство: Filter. Имя говорит само за себя, свойство Filter позволяет применять фильтр к контейнеру и выбирать отдельные типы объекта. Например, при привязке к OU, когда нужно выбрать только группу объектов, входящих в OU, к OU применяется Group Filter, как показано на Рисунке 3.

Можно добавить в массив другие типы объектов, проводя фильтрацию по различным типам объектов. Например, Array («Group», «Computer») перечисляет все объекты типа Group и Computer. Кроме того, можно еще раз применить фильтр с другими типами объектов и получить совершенно другой перечень. Однако если используется свойство Filter для фильтрации объектов User, то в перечне появятся как объект User, так и Computer, потому что Computer является дочерним по отношению к User в иерархии классов AD. Чтобы избежать такой ситуации, можно применить фильтр для объектов Computer, запомнив список только объектов Computer. Далее создается второй список для фильтра по User, сравниваются два списка, и из списка пользователей удаляются позиции из списка компьютеров. Или же можно полностью заменить фильтр запросом ADO.

Другое свойство IADsContainer, применяемое к провайдеру LDAP, называется NewEnum. Однако непосредственно NewEnum не вызывается; предложение For Each из VBScript осуществляет просмотр контейнера и неявным образом вызывает NewEnum, как показано на Рисунке 3.

Из пяти методов IADsContainer к методам Create, Delete, GetObject и MoveHere нельзя получить доступ с помощью провайдера LDAP. Вместе все четыре метода обеспечивают первичные механизмы управления жизненным циклом объектов AD.

Create. Метод Create применяется для создания новых объектов AD (например, User, OU, Group, Com-puter, Site). Код, показанный меткой A в Листинге 2, осуществляет привязку к соответствующему контейнеру и вызывает Create для создания нового объекта. Некоторых общих ошибок при использовании метода Create можно избежать, если не пропускать установку новых обязательных свойств объекта перед вызовом SetInfo или не забывать указывать «key=» как часть относительного имени RDN объекта. Можно использовать сценарий, подобный приведенному в Листинге 1, для определения обязательных (must-Containe) и дополнительных (may-Containe) свойств объекта.

Система сама присваивает значения большинству обязательных свойств (например, objectClass, objectCategory, objectSid, ntSecurityDescriptor, instanceType). Из семи обязательных свойств пользователя, которые показаны на Экране 1, приходится иметь дело только с cn и sAMAccountName. Установка свойства cn происходит как часть вызова метода Create, а Put используется для установки sAMAc-countName. Обычно обязательные свойства, которые обрабатывает система, не инициализируются.

Delete. Метод Delete несложен (см Листинг 2 метка D). Сначала происходит привязка к родительскому контейнеру объекта, который нужно удалить. Далее вызывается метод Delete контейнера и идентифицируется целевой дочерний объект для удаления. Как и в случае с методом Create, требуется указание соответствующего «key=», как части имени RDN целевого объекта.

Удаление объекта — действие необратимое. Но Delete не может удалить контейнеры, в которых хранятся объекты. Сначала необходимо рекурсивно удалить все дочерние объекты, затем, если требуется использовать метод Delete для удаления целого сегмента дерева каталога, также рекурсивно удалить вложенные контейнерные объекты. Если очевидно, что нужно отрезать целую ветвь дерева каталога, используется метод DeleteObject, предоставляемый интерфейсом IADs-De-leteOps, который обеспечивает удаление контейнера и всех его объектов.

GetObject. Метод GetObject из IADs-Container подобен функции GetObject из VBScript тем, что GetObject из IADs-Container создает ссылку на объект программирования ADSI. Различие между ними заключается в том, что метод GetObject из IADsContainer позволяет привязываться только к дочерним объектам в контейнере ADSI. Это объясняет, почему сигнатуры методов (т. е. списки параметров) двух методов с одним и тем же названием различны. Функции GetObject из VBScript предоставляется ADsPath, в то время как методу GetObject из IADsContainer требуется имя класса и RDN целевого объекта в текущем контейнере. Последний метод обеспечивает легкость просмотра контейнера и привязки к каждому дочернему объекту из списка.

MoveHere. MoveHere используется для переноса объекта из одного контейнера в другой, что происходит при перемещении между доменами или переименовании объекта. Из рассматриваемых четырех методов пользователи чаще всего совершают ошибки с MoveHere. Ошибкой является непонимание того, что MoveHere — это механизм, который используется для переименования объектов AD. Нельзя изменить обязательное свойство cn объекта или эквивалентное ему (например, ou в случае OU), чтобы переименовать объект AD, как это обычно делается при изменении других атрибутов. Нужно использовать MoveHere. Другая общая ошибка — это попытка создать ADsPath для перемещения или переименования объекта. Для решения этой задачи лучше использовать свойство IADs::ADs Path или переменные, пример показан в Листинге 2, метка С.

При использовании MoveHere всегда происходит привязка к целевому контейнеру, который может быть текущим родительским контейнером объекта. При перемещении объекта происходит привязка к целевому контейнеру; при переименовании объекта — к родительскому контейнеру объекта. Если объект и перемещается и переименовывается, осуществляется привязка к целевому контейнеру. После получения интерфейса целевого или родительского контейнера можно вызывать MoveHere. Первый параметр MoveHere — ADsPath объекта для перемещения или переименования — всегда один и тот же, он не зависит от типа операции. Второй параметр — это одно из двух возможных значений. При переименовании объекта вторым параметром является новое имя RDN объекта. Если объект не переименовывается, то вторым параметром будет текущее RDN объекта.

Дополнительные интерфейсы в ADSI

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

  • методы SetPassword и ChangePas-sword, которые интерфейс IADsUser предоставляет для управления паролями пользователей, как показано в Листинге 2, метка А;
  • метод Group, который интерфейс IADsUser предоставляет для перечисления групп, принадлежащих пользователю;
  • методы Members, IsMember, Add и Remove, которые предоставляет интерфейс IADsGroup для управления членством в группах;
  • интерфейсы системы защиты IADs-SecurityDescriptor, IADsAccessCont-rolList и IADsAccessControlEntry для управления безопасностью объектов AD.

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

  1. Идентифицировать тип объекта, с которым вы работаете (например, объекты Computer, Group, User).
  2. Обратиться к документации по ADSI и выяснить, существует ли интерфейс для такого типа объекта. Названия интерфейсов начинаются с IADs, затем идет имя типа объекта (например, IADsComputer, IADsGro-up, IADsOU, IADsUser). Найти полный список интерфейсов можно в Microsoft Developer Network (MSDN) Online Library.
  3. Если интерфейс в ADSI существует, нужно оценить те свойства и методы, которые он предоставляет, чтобы найти подходящий метод или свойство.

Корректный ASP.NET Core

Специально для любителей книг из серии «С++ за 24 часа» решил написать статью про ASP.NET Core.

Если вы раньше не разрабатывали под .NET или под какую-то аналогичную платформу, то смысла заходить под кат для вас нет. А вот если вам интересно узнать что такое IoC, DI, DIP, Interseptors, Middleware, Filters (то есть все то, чем отличается Core от классического .NET), то вам определенно есть смысл нажать на «Читать дальше», так как заниматься разработкой без понимания всего этого явно не корректно.

IoC, DI, DIP

Если театр начинается с вешалки, то ASP.NET Core начинается с Dependency Injection. Для того, чтобы разобраться с DI нужно понять, что такое IoC.

Говоря о IoC очень часто вспоминают голливудский принцип «Don’t call us, we’ll call you». Что означает «Не нужно звонить нам мы позвоним вам сами».

Различные источники приводят различные паттерны, к которым может быть применен IoC. И скорее всего они все правы и просто дополняют друг друга. Вот некоторые их этих паттернов: factory, service locator, template method, observer, strategy.

Давайте разберем IoC на примере простого консольного приложения.

Допустим у нас есть два простых класса, реализующих интерфейс с одним методом:

Они оба зависят от абстракции (в данном случае в виде абстракции выступает интерфейс).

И, допустим, у нас есть объект более высокого уровня, использующий эти классы:

В зависимости от параметра конструктора переменная _instance инициализируется определенным классом. Ну и далее при вызове Write будет совершен вывод на консоль или в Debug. Все вроде бы неплохо и даже, казалось бы, соответствует первой части принципа Dependency Inversion

Объекты более высокого уровня не зависят от объектов более низкого уровня. И те, и те зависят от абстракций.

В качестве абстракции в нашем случае выступает ILayer.

Но у нас должен быть еще и объект еще более высокого уровня. Тот, который использует класс Logging

Инициализируя Logging с помощью 1 мы получаем в классе Logging экземпляр класса, выводящего данные на консоль. Если мы инициализируем Logging любым другим числом, то log.Write будет выводить данные в Debug. Все, казалось бы, работает, но работает плохо. Наш объект более высокого уровня Main зависит от деталей кода объекта более низкого уровня – класса Logging. Если мы в этом классе что-то изменим, то нам необходимо будет изменять и код класса Main. Чтобы это не происходило мы сделаем инверсию контроля – Inversion of Control. Сделаем так чтобы класс Main контролировал то, что происходит в классе Logging. Класс Logging будет получать в виде параметра конструктора экземпляр класса, реализующего интерфейс интерфейс ILayer

И теперь нас класс Main будет выглядеть таким образом:

Фактически мы декорируем наш объект Logging с помощью необходимого для нас объекта.

Теперь наше приложение соответствует и второй части принципа Dependency Inversion:

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

Есть такой термин tight coupling – тесная связь. Чем слабее связи между компонентами в приложении, тем лучше. Хотелось бы заметить, что данный пример простого приложения немного не дотягивает до идеала. Почему? Да потому что в классе самого высокого уровня в Main у нас дважды используется создание экземпляров класса с помощью new. А есть такая мнемоническая фраза «New is a clue» — что означает чем меньше вы используется new, тем меньше тесных связей компонентов в приложении и тем лучше. В идеале мы не должны были использовать new DebugLayer, а должны были получить DebugLayer каким-нибудь другим способом. Каким? Например, из IoC контейнера или с помощью рефлексии из параметра передаваемого Main.

Теперь мы разобрались с тем, что такое Inversion of Control (IoC) и что такое принцип Dependency Inversion (DIP). Осталось разобраться с тем, что такое Dependency Injection (DI). IoC представляет собой парадигму дизайна. Dependency Injection это паттерн. Это то, что у нас теперь происходит в конструкторе класса Logging. Мы получаем экземпляр определенной зависимости (dependency). Класс Logging зависит от экземпляра класса, реализующего ILayer. И это экземпляр внедряется (injected) через конструктор.

IoC container

IoC контейнер это такой объект, который содержит в себе множество каких-то определенных зависимостей (dependency). Зависимость можно иначе назвать сервисом – как правило это класс с определенным функционалом. При необходимости из контейнера можно получить зависимость необходимого типа. Внедрение dependency в контейнер — это Inject. Извлечение – Resolve. Приведу пример самого простого самостоятельно написанного IoC контейнера:

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

Зарегистрировать зависимость (допустим, ConsoleLayer или DebugLayer которые мы использовали в прошлом примере) можно так:

А извлечь из контейнера в необходимом месте программы так:

В реальных контейнерах еще реализуется и Dispose(), позволяющий уничтожать ставшие ненужными ресурсы.

Кстати, имя IoC контейнер не совсем точно передает смысл, так как термин IoC гораздо шире по применению. Поэтому в последнее время все чаще применяется термин DI контейнер (так как все-таки применяется dependency injection).

Service lifetimes + various extension methods in Composition Root

Приложения ASP.NET Core содержат файл Startup.cs который является отправной точкой приложения, позволяющей настроить DI. Настраивается DI в методе ConfigureServices.

Этот код добавит в DI контейнер класс SomeRepository, реализующий интерфейс ISomeRepository. То, что сервис добавлен в контейнер с помощью AddScoped означает, что экземпляр класса будет создаваться при каждом запросе страницы.
Добавить сервис в контейнер можно и без указания интерфейса.

Но такой способ не рекомендуется, так как у вашего приложения теряется гибкость и появляются тесные связи. Рекомендуется всегда указывать интерфейс, так как в таком случае в любой момент времени можно заменить одну реализацию интерфейса другой. И если реализации поддерживают принцип Liskov substitution, то «легким движением руки» сменив название класса реализации вы измените и функционал всего приложения.

Есть еще 2 варианта добавить сервис – AddSingleton и AddTransient.
При использовании AddSingleton сервис создается один раз и при использовании приложения обращение идет к одному и тому же экземпляру. Использовать этот способ нужно особенно осторожно, так как возможны утечки памяти и проблемы с многопоточностью.

У AddSingleton есть небольшая особенность. Он может быть инициализирован либо при первом обращении к нему

либо сразу же при добавлении в конструктор

Вторым способом можно даже добавить параметр в конструктор.
Если хочется добавить параметр в конструктор сервиса, добавленного не только с помощью AddSingleton, но и с помощью AddTransient/AddScoped, то можно использовать лямбда выражение:

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

Если с AddSingleton и AddScoped все должно быть более-менее понятно, то AddTransient требует разъяснений. Официальная документация приводит пример, в котором определенный сервис добавлен в DI контейнер и в качестве параметра конструктора другого сервиса и отдельно самостоятельно. И вот в случае, если он добавлен отдельно с помощью AddTransient, он создает свой экземпляр 2 раза. Приведу очень-очень упрощенный пример. В реальной жизни к применению не рекомендуется, т.к. классы для упрощения не наследуют интерфейсы. Допустим у нас есть простой класс:

И есть второй класс, который содержит первый как зависимый сервис и получает эту зависимость в качестве параметра конструктора:

Теперь совершаем inject двух сервисов:

И в каком-нибудь контроллере в Action добавим получение наших зависимостей и вывод значений в окно Debug.

Так вот в результате мы получим 2 разных значения Guid. А вот если мы заменим AddTransient на AddScoped, то в результате мы получим 2 одинаковых значения.

В IoC контейнере приложений ASP.NET Core по умолчанию содержатся уже некоторые сервисы. Например, IConfiguration – сервис с помощью которого можно получить настройки приложения из файлов appsettings.json и appsettings.Development.json. IHostingEnvironment и ILoggerFactory с помощью которых можно получить текущую конфигурацию и вспомогательный класс, позволяющий проводить логирование.

Извлекают классы из контейнера с помощью следующей типичной конструкции (самый банальный пример):

В области видимости контроллера создается переменная с модификаторами доступа private readonly. Зависимость получается из контейнера в конструкторе класса и присваивается приватной переменной. Далее эту переменную можно использовать в любых методах или Action контроллера.
Иногда не хочется создавать переменную для того, чтобы использовать ее только в одном Action. Тогда можно использовать атрибут [FromServices]. Пример:

Выглядит странно, но для того, чтобы в коде не вызывать метод статического класса DateTime.Now() иногда делают так, что значение времени получается из сервиса в качестве параметра. Таким образом появляется возможность передать любое время в качестве параметра, а значит становится легче писать тесты и, как правило, становится проще вносить изменения в приложение.
Нельзя сказать, что static – это зло. Статические методы выполняются быстрее. И скорее всего static может использоваться где-то в самом IoC контейнере. Но если мы избавим наше приложение от всего статического и new, то получим большую гибкость.

Сторонние DI контейнеры

То, что мы рассматривали и то, что фактически реализует ASP.NET Core DI контейнер по умолчанию, — constructor injection. Имеется еще возможность внедрить зависимость в property с помощью так называемого property injection, но эта возможность отсутствует у встроенного в ASP.NET Core контейнера. Например, у нас может быть какой-то класс, который вы внедряем как зависимость, и у этого класса есть какое-то public property. Теперь представьте себе, что во время или после того как мы внедряем зависимость, нам нужно задать значение property. Вернемся к примеру похожему на пример, который мы недавно рассматривали.
Если у нас есть такой вот класс:

который мы можем внедрить как зависимость,

то используя стандартный контейнер задать значение для свойства мы не можем.
Если вы захотите использовать такую возможность задать значение для свойства OperationId, то вы можете использовать какой-то сторонний DI контейнер, поддерживающий property injection. К слову сказать property injection не особо рекомендуется использовать. Однако, существуют еще Method Injection и Setter Method Injection, которые вполне могут вам пригодится и которые также не поддерживаются стандартным контейнером.

У сторонних контейнеров могут быть и другие очень полезные возможности. Например, с помощью стороннего контейнера можно внедрять зависимость только в контролеры, у которых в названии присутствует определенное слово. И довольно часто используемый кейс – DI контейнеры, оптимизированные на быстродействие.
Вот список некоторых сторонних DI контейнеров, поддерживаемых ASP.NET Core: Autofac, Castle Windsor, LightInject, DryIoC, StructureMap, Unity

Хоть при использовании стандартного DI контейнера и нельзя использовать property/method injection, но зато можно внедрить зависимый сервис в качестве параметра конструктора реализовав паттерн «Фабрика» следующим образом:

В данном случае GetService вернет null если зависимый сервис не найден. Есть вариация GetRequiredService, которая выбросит исключение в случае, если зависимый сервис не найден.
Процесс получения зависимого сервиса с помощью GetService фактически применяет паттерн Service locator.

Autofac

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

Установим NuGet пакет Autofac.Extensions.DependencyInjection.
Изменим возвращаемое методом ConfigureServices значение с void на IServiceProvider. И добавим property

После этого станет возможным добавить в конец метода ConfigureServices класса Startup код вроде следующего (это лишь один из вариантов регистрации сервисов):

Здесь builder.Populate(services); добавляет в контейнер сервисы из IServiceCollection. Ну и далее уже можно регистрировать сервисы с помощью builder.RegisterType. Ах, да. Чуть не забыл. Необходимо изменить с void на IServiceProvider возвращаемое значение метода ConfigureServices.

AOP с помощью ASP.NET Core — Autofac Interseptors

Говоря про аспектно-ориентированное программирование, упоминают другой термин – cross-cutting concerns. Concern – это какая-то часть информации, которая влияет на код. В русском варианте употребляют слово ответственность. Ну а cross-cutting concerns это ответственности, которые влияют на другие ответственности. А в идеале ведь они не должны влиять друг на друга, так ведь? Когда они влияют на друг друга, то становится сложнее изменять программу. Удобнее, когда у нас все операции происходят по отдельности. Логирование, транзакции, кеширование и многое другое можно совершать с помощью AOP не изменяя код самих классов и методов.

В мире .NET часто применяется способ, когда AOP код внедряется с помощью пост-процессора в уже откомпилированный код приложения (PostSharp) Или же альтернативно можно применять интерцепторы – это такие перехватчики событий, которые можно добавлять в код приложения. Эти перехватчики, как правило, используют для своей работы уже рассмотренный нами паттерн декоратор.

Давайте создадим свой интерцептор. Самый простой и типичный пример, который проще всего воспроизвести — это логирование.
Установим дополнительно к пакету Autofac.Extensions.DependencyInjection еще и пакет Autofac.Extras.DynamicProxy
Установили? Добавим простенький класс лога, который будет вызываться при обращении к определенным сервисам.

Добавляем в нашу регистрацию Autofac регистрацию интерцептора:

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

Также мы можем убрать .InterceptedBy(typeof(Logger)); и добавить перехват вызовов только для конкретных сервисов приложения с помощью атрибута [Intercept(typeof(Logger))] – необходимо указать его перед заголовком класса.

Middleware

В ASP.NET существует определенная цепочка вызовов кода, которая происходит при каждом request. Еще до того, как загрузился UI/MVC выполняются определенные действия.


То есть, например, если мы добавим в начало метода Configure класса Startup.cs код

то мы сможем посмотреть в консоли дебага какие файлы запрашивает наше приложение. Фактически мы получаем возможности AOP “out of box”
Немного useless, но понятный и познавательный пример использования middleware я вам сейчас покажу:

При каждом запросе начинает выполнятся цепочка вызовов. Из каждого app.Use после вызова next.invoke() совершается переход ко следующему вызову. И все завершается после того как отработает app.Run.
Можно выполнять какой-то код только при обращении к определенному route.
Сделать это можно с помощью app.Map:

Теперь если просто перейти на страницу сайта, то можно будет увидеть текст “Hello!”, а если добавить к строке адреса /Goodbye, то вам будет отображено Goodbye.

Кроме Use и Map можно использовать UseWhen или MapWhen для того, чтобы добавлять код в цепочку middleware только при каких-то определенных условиях.

До сих пор были все еще useless примеры, правда? Вот вам нормальный пример:

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

Или же вот пример локализации:

Теперь если вы к адресу страницы добавите параметр ?culture=fr то вы сможете переключить язык приложения на французский (если в ваше приложение добавлена локализация, то все сработает)

Filters

Если цепочка middleware относятся к процессам до MVC, то фильтры работают вместе с MVC.
Следующее схематическое изображение показывает, как отрабатывают фильтры

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

Затем отрабатывают фильтры ресурсов. С помощью этих фильтров можно, например, вернуть какую-то информацию из кеша.

Затем происходит привязка данных и выполняются Action фильтры. С их помощью можно манипулировать параметрами передаваемыми Action и возвращаемым результатом.

Exception фильтры как намекает название позволяют добавить какую-то общую обработку ошибок для приложения. Должно быть довольно удобно обрабатывать ошибки везде одинаково. Эдакий AOP-шный плюс.

Result фильтры позволяют совершить какие-то действия до выполнения Action контроллера или после. Они довольно похожи на Action фильтры, но выполняются только в случае отсутствия ошибок. Подходят для логики завязанной на View.

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

Добавляете этот класс в DI контейнер (как обычно в Startup.cs)

И теперь становится возможным добавить какую-то свою авторизацию любому Action добавив следующий атрибут

Забавная штука – можно создать свое middleware и добавлять его каким-то action в качестве фильтра. Для того чтобы сделать так нужно создать класс с произвольным названием и методом Configure

Теперь этот класс можно добавлять Action-ам с помощью следующего атрибута

Asp свойства объектов контейнеров adsi

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

Примечание
Для настройки этого метода обнаружения необходимо разрешение на изменение для класса или экземпляра объектов безопасности сайта. Дополнительные сведения о разрешениях безопасности см. в разделе Классы и экземпляры для безопасности объектов в Configuration Manager.

Настройка обнаружения группы безопасности Active Directory

В консоли Configuration Manager перейдите к разделу System Center Configuration Manager / База данных сайта / Управление сайтом / / Параметры сайта / Методы обнаружения.

Щелкните правой кнопкой мыши пункт Обнаружение группы безопасности Active Directory и выберите пункт Свойства.

Включите метод обнаружения, если он еще не включен.

На вкладке Общие щелкните значок «Создать», чтобы указать новый контейнер Active Directory.

В диалоговом окне Новый контейнер Active Directory укажите контейнер для поиска по расположению. Доступны следующие три параметра:

    Локальный домен: выполняет поиск контейнеров Active Directory в домене, в котором содержится компьютер с консолью Configuration Manager.

Локальный лес: выполняет поиск контейнеров Active Directory в лесу, в котором содержится компьютер с консолью Configuration Manager.

Пользовательский LDAP или GC-запрос: выполняет поиск контейнеров Active Directory при помощи протокола LDAP или GC-запроса.

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

Также выберите любые дополнительные параметры поиска. Доступны два параметра:

    Рекурсивно: определяет, что поиск включает дочерние контейнеры. Этот флажок установлен по умолчанию. Если флажок не установлен, поиск дочерних контейнеров не производится.

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

Нажмите кнопку ОК.

На вкладке Расписание опроса нажмите кнопку Расписание и при необходимости установите пользовательское расписание. По умолчанию метод обнаружения группы безопасности Active Directory выполняет опрос один раз в день.

Чтобы метод обнаружения выполнился немедленно, установите флажок Запустить обнаружение как можно скорее.

Архитектура Membership API

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

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

Для преодоления этой проблемы в ASP.NET 2.0 было добавлено средство под названием , которое в ASP.NET 4, по сути, осталось без изменений. Интерфейс Membership API — это платформа, построенная на основе существующей инфраструктуры аутентификации с помощью форм. При использовании Membership API даже не понадобится реализовывать страницы входа или хранилища удостоверений.

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

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

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

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

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

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

Уровень абстракции, который обеспечивает независимость приложений от конкретного лежащего в основе хранилища данных через классы поставщиков членства. Любая функциональность, перечисленная выше, работает совершенно независимо от конкретного используемого хранилища данных, и одни хранилища данных можно заменять на другие — совершенно без необходимости в какой-либо модификации приложений. По умолчанию Membership API полагается на базу данных SQL Server Express для хранения информации о пользователях и ролях.

На рисунке ниже показана фундаментальная архитектура Membership API, которая состоит из поставщиков, собственно API-интерфейса и элементов управления для создания соответствующих пользовательских интерфейсов:

Платформа Membership API спроектирована для полностью независимой работы от используемого им хранилища данных. Вы, как разработчик приложения, в основном имеете дело с элементами управления, предоставленными ASP.NET, а также классом Membership. Класс Membership предлагает набор методов для программного доступа к пользователям и ролям, находящимся в хранилище. Методы работают с поставщиком членства. Этот поставщик реализует доступ к лежащему в основе хранилищу данных. Все классы, относящиеся к Membership API, размещены в пространстве имен System.Web.Security. Их список с краткими описаниями приведен в таблице ниже:

Классы Membership API

Класс Membership — центральная точка взаимодействия с Membership API. Он предоставляет ряд методов для управления пользователями, их проверки и переустановки паролей

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

Представляет отдельного пользователя, записанного в хранилище данных Membership API. Этот объект содержит всю информацию о пользователе и возвращается несколькими методами класса Membership, например, GetUser()

Коллекция пользователей Membership. Например, метод GetUsers() класса Membership возвращает экземпляр этой коллекции

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

Коллекций доступных поставщиков членства на машине для данного веб-приложения

Реализаций класса MembershipProvider, работающая с базами данных SQL Server

Реализация класса MembershipProvider, работающая со службой Active Directory

Класс, который наследует всю функциональность MembershipUser и добавляет некоторые специфичные для Active Directory свойства

ASP.NET включает готовых поставщиков членства для SQL Server и Active Directory (что позволяет создавать собственные страницы входа для пользователей, хранящихся в Active Directory). Но основная идея поставщиков состоит в том, что они предоставляют возможность полного расширения инфраструктуры. Таким образом, можно реализовать собственный поставщик членства, который будет представлять собой класс, унаследованный от System.Web.Security.MembershipProvider. Поставщик членства конфигурируется, прежде всего, в файле web.config, в новом разделе .

Хотя Membership API и поддерживает службу Active Directory в качестве одного из поставщиков, все же существует большая разница между использованием Windows-аутентификации и Membership API для аутентификации пользователей веб-приложений.

В случае настройки приложения на применение интерфейса Membership API, который в действительности основан на аутентификации с помощью форм, удостоверения пересылаются по сети в виде простого текста (если только не используется SSL) и, как было показано ранее, для аутентификации применяются так называемые билеты аутентификации. С другой стороны, при настройке Windows-аутентификации пользователь аутентифицируется либо через NTLM, либо через Kerberos (в случае доменов Windows Server). Оба метода намного более безопасны, поскольку удостоверения никогда не пересылаются через сеть.

В приведенной таблице присутствует выделенный класс по имени ActiveDirectoryMembershipUser, который применяется в сочетании с ActiveDirectoryMembershipProvider. Однако класса по имени SqlMembershipProviderUser вы не найдете. Это значит, что класс SqlMembershipProviderUser для представления пользователей использует базовый класс MembershipUser. Причина в том, что версия поставщика Active Directory расширяет класс MembershipUser множеством специфичных для Active Directory атрибутов, доступных пользователям Active Directory. Таких специфичных свойств у SqlMembershipProviderUser не предусмотрено, поэтому создание отдельного класса SqlMembershipProviderUser просто не понадобилось.

Интерфейс Membership API служит только для управления и аутентификации пользователей. Он не реализует никакой функциональности авторизации и не предоставляет функциональности управления пользовательскими ролями. Для этой цели предназначен интерфейс Roles API рассматриваемый позже.

Asp свойства объектов контейнеров adsi

На вкладке «Разрешения» дополнительных параметров безопасности отсутствует пункт «Заменить все разрешения дочернего объекта на разрешения, наследуемые от этого объекта», есть только «Добавить разрешения, наследуемые от родительских объектов»

Ответы

А там эта галка не предусмотрена.

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

  • Предложено в качестве ответа Dmitriy Razbornov 18 февраля 2013 г. 13:52
  • Помечено в качестве ответа Гладких Александр 19 февраля 2013 г. 7:33
  • Снята пометка об ответе Гладких Александр 19 февраля 2013 г. 7:59
  • Помечено в качестве ответа Гладких Александр 19 февраля 2013 г. 13:40

да, такой инструмент имеется. Это всеми любимый dsacls , хотя я Вам рекомедую в этом случае посмотреть на удобные Get-Acl | Set-Acl , вроде

Get-Acl ‘ou=redoctober,dc=,kasp,dc=ru’).access | ft identityreference, accesscontroltype -AutoSize

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

У Сергея в блоге хорошо расписано с использованием квеста.

Статья 10: Управление объектами Active Directory и DFS

Основные экзамены Windows 2000 за 15 минут в неделю

Управление объектами Active Directory и DFS

Автор: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Добро пожаловать в десятую статью моей серии. Она охватывает вопросы управления объектами в домене и распределенной файловой системы (DFS). Мы рассмотрим пользователей домена, группы, управление контейнерами, профили пользователей, концепцию DFS и ее администрирование. Это третья статья, посвященная экзамену 70-215, в предыдущих двух мы рассмотрели основы внедрения и администрирования Active Directory (Службы Каталогов, как обычно переводят это понятие).

Материалы этой статьи включают в себя:

  • Управление объектами Active Directory
  • Пользователи домена, группы, компьютеры и OU (организационные единицы)
  • Профили пользователей
  • Распределенная файловая система (DFS)

Управление объектами Active Directory

Администрирование Active Directory включает в себя управление объектами домена и их свойствами. Объекты, которые управляются в домене, включают в себя учетные записи пользователей, групп, компьютеров и OU. В отличие от NT 4, где мы использовали один инструмент для управления пользователями и группами (User Manager for Domain (Диспетчер пользователей для домена)) и совсем другой для учетных записей компьютера (Server Manager (Диспетчер серверов)), в домене Windows 2000 все управление этими объектами осуществляется при помощи инструмента, называемую Active Directory Users and Computers (Пользователи и компьютеры Active Directory), оснастки ММС. Заметьте, что этот инструмент можно быстро запустить из командной строки, командой dsa.msc. Когда оснастка запущена, она настроена на особый контроллер домена. Это контроллер домена, на котором все обновления и дополнения записываются. Правым щелчком мышки на объекте Домен вы можете соединиться с другим контроллером домена. Это очень удобно, т.к. репликация между сайтами подчинена расписанию и вы можете решить внести изменения свойств пользователя на его локальном контроллере домена, чтобы изменения вступили в силу сразу. Программа AD Users and Computers отображает объект Домен и серию контейнеров, как показано ниже:

Прежде всего, все папки, которые показаны под объектом Домен, являются на самом деле контейнерами. Существует два вида контейнеров – built-in (встроенные) и OU. Встроенные контейнеры изображены как чистые папки, а OU – как папка с изображением книги на ней. Заметьте, что к OU можно применять групповые политики, в то время как к встроенным контейнерам – нельзя. Однако оба типа контейнеров позволяют делегировать административный контроль. Контейнеры, которые создаются автоматически, описаны ниже:

Built-in (встроенный): В этот контейнер помещены все учетные записи встроенных пользователей и групп, создаваемых при установки Active Directory.

Computers (компьютеры): Этот контейнер включает в себя любые учетные записи компьютеров, которые были обновлены до Windows 2000, а также любые новые учетные записи, которые добавляются в процессе присоединения к домену с клиентской системы.

Domain Controllers (контроллеры домена): Этот контейнер содержит все контроллеры в домене.

ForeignSecurityPrincipals (внешние участники безопасности): Контейнер для SID (идентификаторов безопасности) учетных записей пользователей из внешних доверенных доменов.

Users (Пользователи): Это контейнер, где хранятся обновленные учетные записи пользователей. Вы можете также найти здесь учетные записи Администратора домена и Гостя домена.

Но существуют не только встроенные контейнеры, однако. Если вы выберете Advanced Features (дополнительные возможности) из меню View (Вид), вы обнаружите еще и такие контейнеры:

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

System (системный): Этот контейнер содержит установки, относящиеся к текущей информации о домене, такой как служба DNS, интегрированная в AD, конфигурация DFS и так далее.

Внутри данных контейнеров (или в корне домена) могут создаваться другие объекты, такие как пользователи, компьютеры, группы и т.д. Заметьте, что не существует рекомендации создавать пользователей в контейнере Users или компьютеры в контейнере Computers. Вы можете использовать любой из них, а также создать дополнительную OU в соответствии с потребностями вашей организации. Вы можете также просто перемещать объекты между контейнерами, щелкая правой кнопкой мыши на объекте и выбирая команду Move. Для создания нового объекта внутри контейнера необходимо щелкнуть правой кнопкой мыши на контейнере и выбрать команду New, а затем соответствующий тип объекта, который вы хотите создать, как показано ниже:

Объект Пользователь

Каждому пользователю, которому необходимо входить в домен, требуется учетная запись пользователя. Заметьте, что учетная запись может быть создана внутри любого контейнера (встроенного или созданного вами), в то время как все они технически остаются «доменными» учетными записями. Пользователь продолжает нуждаться в ресурсах домена, в который он входит, а не только контейнера, в котором его учетная запись создана. В отличие от NT 4, где свойства, относящиеся к учетной записи пользователя были весьма ограниченными, в Active Directory эти свойства более обширны. Большинство из них не настраивается в процессе создания учетной записи, но может быть настроено позднее. Как и в NT 4 вы можете менять свойства множества учетных записей одновременно, выбрав несколько учетных записей и затем обратившись к их свойствам. Вкладки свойств, открывающиеся на учетной записи пользователя, зависят от набора установленных служб. Например, если установлена Exchange 2000, почтовая конфигурация пользователя появится в перечне свойств. Заметьте, что для того, чтобы увидеть некоторые из вкладок, вы должны выбрать опцию Advanced Features из меню View. Вкладки, появляющиеся по умолчанию и их назначение перечислены ниже:

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

Address (Адрес) – домашний адрес пользователя.

Account (учетная запись) – детали учетной записи, включая имя для входа в систему, часы входа в систему, свойства учетной записи и окончание действия учетной записи.

Profile (Профиль) – профиль пользователя и информация о сценарии входа, а также подробности о домашней папке.

Telephones (Телефоны) – различные телефонные номера пользователя.

Organization (Организация) – информация о названии, подразделении и руководителе.

Environment (Среда) – информация о запуске Службы Терминалов.

Sessions (Сессии) – установки, относящиеся к сессиям Службы Терминалов, такие как отключение бездействующих сессий.

Remote Control (Удаленный Контроль) – установки, относящиеся к настройкам удаленного контроля Службы Терминалов.

Terminal Services Profile (Профиль Службы Терминалов) – информация, относящаяся к профилю Службы Терминалов, домашней папки, и разрешения/запрещения входа на Сервер.

Published Certificates (Опубликованные сертификаты) – список пользовательских Х.509 сертификатов.

Member Of (Членство в группах) – перечислены группы, в которые входит пользователь.

Dial-in (Набор) – Установки для набора данного пользователя, включая такие детали, как настройка обратного звонка.

Object (объект) – показывает fully qualified name (полностью определенное имя) объекта Пользователь, когда он создается.

Security (Безопасность) – показывает Access Control List (список контроля доступа), связанный с объектом.

Группы

Учетные записи групп тоже отличаются в Windows 2000. В отличие от NT 4, где существуют только Глобальные и Локальные группы, в Windows 2000 включены новые типы групп, областей и возможностей. Прежде чем обсудить все это, однако, мы должны рассмотреть нечто, что называют «режимом» домена. По умолчанию, все домены создаются в состоянии, которое именуется смешанным режимом. В этом режиме резервные контроллеры домена NT 4 продолжают существовать и многие правила, связанные с доменами NT 4 продолжают действовать. Когда все контроллеры домена переходят на Windows 2000, домен может быть переключен в состояние, которое называется Основной режим. Это однонаправленный процесс, перевести домен обратно в смешанный режим нельзя. Заметьте, что Windows 2000 домены всегда создаются в Смешанном режиме и для того, чтобы новые возможности групп и пользователей вступили в силу, необходимо перевести домен в Основной режим.

Windows 2000 поддерживают два типа групп. Первый из них очень похож на группы в NT 4 и называется Security groups (группы безопасности). Достаточно просто, группа безопасности имеет SID (идентификатор безопасности) и, как следствие, может быть частью Discretionary Access Control List (DACL) (список разграничительного контроля доступа), списка пользователей и групп, которые имеют различные разрешения на доступ к ресурсу. Второй тип групп называется Distribution group (группа распределения) и существует для целей посылки сообщений электронной почты группе пользователей. Эта возможность в основном существует для целей интеграции с Exchange 2000. Группы распределения не имеют SID и, как следствие, не могут быть добавлены в DACL. Вы можете спросить, зачем необходимо делать такие различия. Причина кроется в том, что происходит, когда пользователь входит в систему – создается метка безопасности, в которой перечислены его SID и все SID групп, членом которых пользователь является. Чем больше число групп безопасности, тем больше метка безопасности для пользователя, и дольше время входа пользователя в систему. Группы распределения предоставляют более простой и использующий меньше ресурсов способ для внедрения технологий посылки сообщений в Active Directory.

После того, как мы рассмотрели типы групп, мы должны рассмотреть области их применения. В Windows 2000 если три области применения групп – Локальные группы домена, глобальные и универсальные. Описания каждой из них приведены ниже:

Domain Local (Локальные группы домена): Эти группы существуют на контроллерах домена и могут быть применены к любой системе в домене. Эти группы также используются для применения разрешений, как это делалось в NT 4. Выгодное отличие от локальных групп в NT 4 состоит в том, что в Windows 2000 вы создаете локальную группу в Active Directory и затем применяете к любой системе. В Основном режиме локальные группы домена могут включать в себя Пользователей (из любого домена леса), Глобальные группы (из любого домена леса), Универсальные группы и другие локальные группы из того же домена. Заметьте, что в Смешанном режиме локальные группы домена могут включать только глобальные группы и пользователей из любого домена, также как и в NT 4.

Global Groups (Глобальные группы): Эти группы в основном используются для объединения пользователей со сходными потребностями. В Основном режиме глобальные группы могут включать в себя другие глобальные группы из своего домена. В Смешанном режиме глобальные группы могут включать в себя только пользователей из своего домена.

Universal Groups (Универсальные группы): Они создаются только в Основном режиме и могут включать в себя пользователей и глобальные группы из любого домена всего леса.

Вы должны прочитать все это очень внимательно. Windows 2000 в Основном режиме поддерживает вложение групп, например, включение одной глобальной группы в другую глобальную группу. Это возможность предоставляет дополнительную гибкость в администрировании, но также может породить путаницу, если вложения будут чрезмерно многоуровневыми. Мой совет – избегать вложение групп одинакового типа (например, глобальную в глобальную и т.д.). Также вы должны заметить, что в Windows 2000 вы можете помещать в группы учетные записи компьютеров, по тем же правилам, что мы привели для учетных записей пользователей.

Как только вы соберетесь создать группу, щелкните правой кнопкой мыши на объекте, в который вы планируете поместить группу и выберите из списка опцию New Group (Новая Группа). Вы увидите следующее окно:

Заметьте, что если опция Универсальная Группа закрашена серым – это верный признак того, что домен находится в Смешанном режиме. Для того, чтобы увидеть, членом каких групп является данная группа, необходимо открыть свойства группы и перейти на вкладку Member of (Членство в группах). Обсуждение каждой из встроенных групп, а также права, связанные с ними, мы рассмотрим в статьях, посвященных Active Directory.

Учетные записи компьютеров

Active Directory требует, чтобы учетные записи компьютеров создавались как для Windows 2000, так и для Windows NT. Как и в NT 4, системы, работающие под Windows 9x не требуют создания учетных записей и, следовательно, эти системы не получают SID. Учетные записи компьютера могут создаваться во встроенном контейнере Computers или любых других контейнерах. Если вы создаете учетную запись компьютера в процессе присоединения к домену, учетная запись автоматически будет помещена в контейнер Computers. Конечно, вы можете переместить ее в другой контейнер в любое время, руководствуясь своими управленческими и административными нуждами.

Organizational Units (Организационные единицы)

Как было отмечено ранее, базовое отличие между встроенными контейнерами и OU состоит в том, что к OU может быть применена групповая политика. Другое преимущество состоит в том, что OU могут быть вложенными друг в друга, что также позволяет получить выигрыш в умении OU наследовать групповые политики. Заметьте, что OU могут перемещаться внутри домена, как и любые другие объекты в домене. Просто нажмите правой кнопкой мыши на OU и выберите опцию “Move”. Будьте осторожны, так как удаляя OU, вы также удаляете все объекты, которые она содержит.

OU существуют, в основном, для целей организации ресурсов в соответствии с нуждами администрирования. Например, я могу делегировать контроль над OU, называемой «Серверы» группе поддержки серверов и не давать им больше никаких административных привилегий. Или применить политику к OU (например, содержащую учетные записи всех банковских служащих), которая позволит мне отключать рабочую среду именно данной категории пользователей. Как мы знаем из предыдущей статьи, групповая политика может быть применена на 4 различных уровнях, в следующем порядке:

  1. Локально
  2. К сайту
  3. К домену
  4. К OU, а затем к вложенным OU, если они есть.

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

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

Мне кажется, я знаю, что вы сейчас думаете. Что кто-нибудь может создать политику на уровне OU, которая будет преобладать над политиками на уровне домена или сайта – и вы будете абсолютно правы. Для того, чтобы контролировать подобную ситуацию, в Windows 2000 добавлены две новые возможности: No Override (Не перекрывать) Block Inheritance (Блокировать наследование). Возможность применения No Override основывается на принципе, позволяющем получить больший контроль на более высоком уровне. Опция No Override может быть применена к политике на уровне сайта, домена и OU. Если она установлена, как показано ниже, то эта политика будет преобладать над всеми другими в случае конфликта. Заметьте, что установки разных политик будут по-прежнему сливаться, если не конфликтуют друг с другом.

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

Это порождает еще один интересный вопрос – что случиться, если Администратор установит опцию No Override на политике уровня домена, а другой Администратор установит Block Inheritance на политике, примененной к OU? Понятно, что возникает конфликтная ситуация, но ответ прост — опция No Override всегда выигрывает!

Вы должны быть в курсе, что установки групповой политики будут автоматически обновляться на клиентских системах приблизительно каждые 90 минут (со случайным разбросом в 30 минут) и на контроллере домена – каждые 5 минут по умолчанию. Если вы хотите форсировать обновление групповой политики немедленно, то вы можете использовать утилиту командной строки secedit.exe (инструмент для настройки и анализа безопасности). Синтаксис этой команды такой:

Для обновления части групповой политики, применяемой к компьютеру: secedit /refreshpolicy machine_policy

Для обновления части групповой политики, применяемой к пользователю: secedit /refreshpolicy user_policy

И последняя заметка, относящаяся к объекту Групповая политика. Когда она устанавливается, с ней связаны некоторые разрешения безопасности. По умолчанию, группе Authenticated Users (Аутентифицированные пользователи) дано право “Apply Group Policy” (применить групповую политику) и “Read” (Чтение) по отношению к GRO (Групповой политике). Если вы хотите фильтровать политику в дальнейшем, вы можете изменить разрешения, связанные с политикой. Например, если я удалю разрешение, данное группе Authenticated Users и затем дам такое же разрешение для группы Sales в том же домене, тогда установки групповой политики будут действовать только на членов группы Sales. Запомните, что групповая политика не может быть приложена к группе, однако, теперь вы знаете, что установки групповой политики могут фильтроваться для достижения подобной цели.

Профили пользователя

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

Локальный профиль наиболее простой. По умолчанию, каждый раз, когда пользователь входит в систему первый раз, профиль по умолчанию загружается для этого пользователя и сохраняется в системе в папке, носящей его имя. Эта папка сохраняется в директории Document and Settings (документы и настройки). Любые изменения, производимые пользователем сохраняются при его выходе из системы. Когда пользователь входит в систему снова для него загружается та среда, которую он покинул в прошлый раз. Природа локального профиля такова, что он не может «следовать» за пользователем. Это означает, что если пользователь входит в систему на другом компьютере, он снова получит профиль по умолчанию и для него будет создан другой локальный профиль.

При использовании перемещаемого профиля рабочая среда «следует» за пользователем, когда он переходит на другие системы в сети. Этот профиль хранится на сервере и копируется туда и обратно, когда пользователь входит и выходит из системы. Для того, чтобы использовать перемещаемый профиль, место хранения профиля должно быть сохранено в свойствах учетной записи пользователя, в секции User Profile (профиль пользователя) на вкладке Profile (профиль), как показано ниже:

Раз уж мы коснулись перемещаемого профиля, то стоит отметить, что их существует тоже два вида, персональные и обязательные. Персональный перемещаемый профиль – это профиль по умолчанию и он разрешает пользователю делать изменения в профиле. Обязательный профиль, напротив, не дает пользователю вносить изменения в профиль. Все изменения, которые пользователь внес в профиль в процессе работы, не копируются на сервер при выходе пользователя из системы. Персональный профиль превращается в обязательный при переименовании файла профиля Ntuser.dat в файл Ntuser.man. Обычно, когда используется обязательный профиль пользователя, многие учетные записи пользователей обращаются к одному и тому же месту хранения профиля. Хорошей иллюстрацией необходимости применения обязательного профиля является необходимость ограничения рабочей среды для таких пользователей, как банковские служащие, например. Вы можете захотеть, чтобы их рабочая среда (рабочий стол) оставались неизменными, не зависимо от компьютера, с которого они входят в сеть.

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

Распределенная файловая система

Distributed File System (DFS) – распределенная файловая система, первоначально была создана в NT 4, но теперь получила свое новое воплощение. Распределенная файловая система (давайте будем называть ее для краткости DFS) позволяет вам организовать общие ресурсы сети в одну логическую структуру, несмотря на то, что сами ресурсы могут быть расположены физически на разных серверах. Для каждого пользователя ресурсы, которые фактически хаотично разбросаны по сети, будут представлены в виде стройной иерархической структуры. Это позволяет вам не только управлять тем, как пользователь видит ресурсы (вы можете использовать различные имена для существующих общих ресурсов), но также тем, как они будут получать доступ к ресурсам (вы можете создать разную структуру в зависимости от нужд пользователей). Например, данные могут быть физически разбросаны, как показано ниже:

Sales data files \\server13\salesdata

Sales quota files \\server2\s-quotainfo

Sales report files \\server1\rpt

Используя DFS, вы можете создать корень DFS и назвать его Sales, используя пустую общую папку Sales на сервере Server1 и создав следующую иерархию:

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

В Windows 2000 существует два типа структуры DFS – изолированная DFS и доменная DFS. Заметьте, что хотя в домене вы можете создавать несколько корней DFS, любой из серверов может хранить только один корень DFS, независимо от его типа (изолированного или доменного).

Изолированная структура DFS может быть создана на любом сервере, работающем под Windows 2000 с установленной DFS (она устанавливается по умолчанию). Для изолированной DFS не требуется Active Directory. Создание структуры DFS начинается с создания на сервере «корня» DFS. Это общий ресурс, к которому клиент будет подключаться первоначально. Для изолированной DFS этот корень может храниться только на единичном сервере. Как следствие, если сервер выйдет из строя, пользователи перестанут иметь доступ к дереву DFS (конечно, они будут иметь возможность получать доступ к самим ресурсам, если они расположены физически на других серверах и клиент знает их местоположение). Изолированная DFS не может иметь «реплик» корня, хоть вы и можете создать реплики ниже корня. Это позволяет пользователям распределять нагрузку на общие ресурсы, которые расположены на различных серверах, но содержат одинаковую информацию. Заметьте, что в изолированной DFS, репликация данных между репликами не происходит автоматически – вы должны периодически проводить репликацию данных используя такие утилиты, как robocopy, например.

Доменная DFS использует преимущества Active Directory, храня информацию о топологии DFS в Active Directory. Этот тип DFS поддерживает возможность создания реплик корня, что позволяет обеспечить распределение нагрузки и отказоустойчивость. Например, если создано несколько реплик корня DFS структуры и одна из реплик окажется отключенной от сети, пользователь сможет получить доступ к DFS простым перенаправлением на другую реплику. А самое главное – для созданных реплик может быть настроена репликация, которая будет происходить автоматически при помощи службы репликации файлов (FRS – file replication service) – она поддерживает до 32 реплик. В случае доменной DFS, корень указывает не на сервер, а на домен. Например, корень DFS может выглядеть так: \\2000trainers.com\dfsroot. Используя информацию о сайтах, хранящуюся в Active Directory, попытка пользователя соединиться с корнем DFS будет перенаправлена на реплику корня, расположенную на сайте пользователя, а не на реплику, подсоединяться к которой придется через линии WAN. Заметьте, что для доступа к корню доменного DFS, клиентам, работающим под Windows 9x или Windows NT 4 необходимо установить клиентское программное обеспечение для работы с Active Directory.

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

Редактировалось Дата: Пятница, 07 Июнь 2013

TCP/IP и DNS

Хранилище зоны DNS

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

Сохранение информации зоны в текстовом файле

Информации зоны в текстовом файле по умолчанию сохраняется в папке %systemroot%\system32\dns . Имя файла может быть любым; обычно оно имеет вид [имя_зоны].DNS (например, microsoft.com.dns ). Файл зоны изменяется через консоль MMC для DNS, однако при остановке службы DNS это можно сделать напрямую, отредактировав текстовый файл зоны. Если запись занимает несколько строк, то разрывы строк должны заключаться в скобки. Комментарии в файле зоны DNS определяются точками с запятой («;»), расположенными перед ними. На рисунке 8.10 показан пример файла зоны DNS.

Ниже приводится описание записей, находящихся в файле зоны DNS.

Запись SOA . Первая запись в файле зоны DNS является записью Start of Authority (Начало полномочий). Запись SOA состоит из следующих полей:

Исходный компьютер. Определяет узел, на котором создан файл.

Контактный адрес электронной почты. Адрес электронной почты лица, ответственного за данный файл зоны. Символ «@» в адресе электронной почты заменяется на символ точки («.»).

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

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

Время повтора. Информирует вторичный сервер о промежутке времени, по прошествии которого нужно повторить неудавшуюся попытку передачи зоны.

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

Минимальное время жизни (TTL). Передается вместе с запросом на преобразование имени. Означает минимальный промежуток времени (с), в течение которого запрашивающий кэширует имя для отображения в IP-адрес. Значение по умолчанию – 1 час. При значении, равном 0, кэширования данных не происходит.

Другие записи. Другие записи в файле зоны DNS наследуют TTL из записи ресурса SOA , однако могут игнорироваться в индивидуальных записях. Синтаксис для индивидуальной записи имеет вид: .

  • Имя. Имя узла или записи, подлежащей преобразованию.
  • Класс. Содержит стандартный текст, означающий класс записи источника. IN означает, что запись источника принадлежит классу Internet. Это единственный класс, поддерживаемый Windows DNS.
  • Тип. Указывает тип записи источника. Например, A означает, что запись источника хранит информацию об адресе узла.
  • Данные. Это поле содержит особые данные записи. Формат может быть различным в зависимости от типа записи.

Сохранение информации зоны в Active Directory

Интегрированные зоны Active Diectory содержатся в контейнере, расположенном в дереве Active Directory под контейнером объекта домена. База данных Active Directory представляет собой расширяемое хранилище с названием ntds . dit . Он создается при создании контроллера домена. Объекту контейнера присваивается имя по имени зоны, присвоенного ей при ее создании.

Преимущества интеграции с Active Directory

Хранение зон DNS в Active Directory является рекомендуемым методом для серверов WS03, поскольку он дает следующие преимущества.

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

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

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

Безопасность. Интегрированные с Active Directory зоны позволяют использовать списки контроля доступа (ACL) для ограничения доступа к зонам или записям в них. Например, только некоторым пользователям или компьютерам разрешено обновлять записи в данной зоне. Этот процесс известен как безопасное динамическое обновление, и он используется по умолчанию для интегрированных с Active Directory зон.

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

Динамическое обновление DNS

Службы DNS системы WS03 позволяют проводить динамическое обновление, посредством которого клиенты могут вводить свои собственные записи A (Address) и PTR ( Pointer Resource ) в DNS . Обычная DNS является статической, поэтому при изменении IP -адресов соответствующие записи DNS становятся рассинхронизированными. Раньше это не представляло особой проблемы, поскольку записи DNS располагались только на серверах, а IP -адреса серверов в большинстве случае являются статическими. Кроме того, основная часть задач по преобразованию имен выполнялась системой WINS. Теперь Windows опирается, в основном, на DNS , и самое главное – все компьютеры содержатся в DNS . Многие клиенты располагаются на DHCP и могут получать различные IP -адреса, поэтому без обновления DNS при изменении адресов IP все может пойти наперекосяк. Здесь-то и вступает в игру динамическая DNS . При получении новых IP -адресов клиенты регистрируют свои записи, и администратору не приходится выполнять задачи, связанные с их обновлением.

При создании зоны DNS можно использовать безопасное динамическое обновление (от него потом можно отказаться). А теперь обсудим различия между двумя типами обновлений – обычным и безопасным.

Обычное динамическое обновление

При использовании динамических обновлений клиент или сервер DHCP является ответственным за обновление записей DNS A и PTR . Поскольку имя может зарегистрировать каждый, невозможно предотвратить злоумышленную регистрацию IP-адреса на имя, представляющее важность. Такая возможность является не безопасной; поэтому была разработана система безопасного динамического обновления.

Безопасное динамическое обновление

Безопасное динамическое обновление доступно только для интегрированных с Active Directory зон. Оно позволяет аутентифицировать клиентов, регистрирующих имена. Безопасные зоны имеют стандартные списки контроля доступа ACL, поэтому обновлять записи могут только те клиенты, которые отвечают разрешениям безопасности. Такой подход удобен следующим: можно заблокировать зоны, чтобы свои записи обновляли только серверы и DHCP-сервер. Таким образом, произвольная регистрация имен становится невозможной.

Илон Маск рекомендует:  Что такое код asp referer
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Компонент Описание
Membership
MembershipCreateUserException
MembershipUser
MembershipUserCollection
MembershipProvider
MembershipProviderCollection
SqlMembershipProvider
ActiveDirectoryMembershipProvider
ActiveDirectoryMembershipUser