Asp методы объектов контейнеров adsi


Контейнер или 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 Service Interface (ADSI): провайдер WinNT

Понятие об ADSI

Технология ADSI (Active Directory Service Interface, интерфейс службы активного каталога) разработана фирмой Microsoft для доступа к службам каталогов. Под службой каталога (Directory Service) понимается та часть распределённой компьютерной системы (компьютерной сети), которая предоставляет средства для поиска и использования имеющихся сетевых ресурсов различных типов (зарегистрированные пользователи, сетевые папки и принтеры и т.д.). В неоднородной компьютерной сети могут одновременно функционировать несколько различных служб каталогов, например, Windows Directory Service для Windows NT 4.0 или Active Directory для Windows 2000 / Windows Server 2003. Технология ADSI обеспечивает единообразный, не зависящий от конкретного сетевого протокола доступ к функциям различных каталогов.

Все примеры сценариев WSH в настоящей статье будут приводиться на языке VBScript.

COM-объекты ADSI включены в операционные системы Windows XP/2000/2003, а также могут быть установлены в более ранних версиях, для чего их нужно скачать с сервера Microsoft.

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

Обращение Описание
LDAP:// Для службы каталогов, созданной на основе протокола LDAP (Lightweight Directory Access Protocol, упрощённый протокол для доступа к каталогу), в том числе для Active Directory в Windows 2000/2003.
WinNT:// Для службы каталогов в сети Windows NT 4.0 или на локальной рабочей станции Windows XP/2000.
NDS:// Для службы каталогов NetWare NDS (Novell Directory Service).
NWCOMPAT:// Для службы каталогов NetWare Bindery.

Вторая часть строки ADsPath определяет расположение объекта в конкретном каталоге (для каждого провайдера ADSI — по-своему).

ADSI может выступать в роли провайдера OLE DB, что позволяет с помощью ADO (ActiveX Data Object) выполнять «естественные» запросы к пространству имён службы каталога (провайдер «ADsDSOObject»). Использовать ADSI в качестве провайдера OLE DB можно в запросах к пространствам имён LDAP и NDS.

Провайдер WinNT

Строка связывания для провайдера WinNT имеет следующий формат:

  • ComputerName — имя компьютера.
  • ObjectName — имя объекта (группы, пользователя, принтера, сервиса и т.д.)
  • > Указав в качестве строки ADsPath просто «WinNT», можно выполнить связывание с корневым объектом-контейнером, содержащим все остальные объекты службы каталога.

Для того, чтобы в сценарии использовать объект ADSI, соответствующий указанной строке связывания, необходимо применить функцию GetObject():

Для уменьшения времени считывания и установки свойств в ADSI применяется модель кэширования свойств (property caching) с помощью методов GetInfo() и SetInfo().

Метод GetInfo() вызывается неявно всякий раз при запросе новых данных. Например:

Если далее в коде применить ещё раз конструкцию User.FullName, то ADSI возвратит значение из кэша свойств, а не будет выполнять повторный поиск в каталоге. Явный же вызов метода GetInfo() приведёт к повторному считыванию данных из каталога:

При изменении объекта в пространстве имён можно использовать несколько свойств этого объекта, но только одну операцию записи обновления в каталоге. Метод SetInfo() вызывается явно и только один раз:

Ниже описываются интерфейсы IADs, IADsDomain и IADsContainer. Зная название интерфейса, вы можете воспользоваться поиском по библиотеке MSDN, чтобы получить исчерпывающую информацию о его свойствах и методах. Интерфейсы IADs, IADsDomain и IADsContainer позволяют перечислить все доступные домены, управлять политикой учётных записей доменов, перечислить объекты, входящие в домены, создать и удалить учётные записи компьютеров и пользователей, создать и удалить группы.

Перечисление доступных доменов

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

Объект домена

Объект домена представляет интерфейс IADsDomain:

Работа с контейнерами

Интерфейс IADsContainer позволяет, подключившись к контейнеру, перечислить все объекты контейнера:

В качестве имени контейнера (ContainerName в скрипте выше) может выступать, например, имя домена или имя компьютера в формате DomainName/ComputerName.

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

Методы Create() и Delete() интерфейса IADsContainer позволяют создавать и удалять учётные записи компьютеров, пользователей, создавать и удалять группы в домене.

Добавление новой учётной записи компьютера:

Удаление учётной записи компьютера:

Добавление новой учётной записи пользователя:

Удаление учётной записи пользователя:

Метод MoveHere() интерфейса IADsContainer позволяет переименовать учётную запись пользователя. При этом идентификатор безопасности (SID — Secutity Identifier) пользователя остаётся неизменным:

Контейнеры и организационные единицы (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

Сразу после установки нового домена Active Directory в корне консоли Active Directory User and Computers (ADUC) появляется несколько предопределенных служебных контейнеров (OU). Большинство из них редко используются при повседневном администрировании Active Directory, однако занимают место в консоли, и «мозолят» глаза администратору AD. В этой статье мы разберемся, как можно скрыть ненужные контейнеры AD в консоли AD Users and Computers.

Напомним, по-умолчанию, в консоли ADUC отображаются следующие контейнеры:


На самом деле объектов верхнего уровня намного больше, чтобы отобразить все, в том числе скрытые объекты AD с расширенными атрибутами, в консоли ADUC нужно в меню View отметить опцию “Advanced Features”.

Microsoft таким образом просто «скрыла» достаточно редко используемые стандартные элементы каталога AD, ежедневный доступ к которым не требуется (если вообще нужен). Каким образом любой OU в AD сделать скрытым, чтобы он не отображался в обычном режиме работы консоли ADUC?

Для этого нужно изменить атрибут, управляющий видимостью любого контейнера в AD под названием showInAdvancedViewOnly. Данный атрибут впервые появился еще в версии AD Windows 2000 Server. Для его правки в Windows 2000/Windows 2003 нужно было устанавливать специальную консоль ADSIEDIT (входящую в состав утилит администратора Windows — Support Tools). В Windows 2008 /2008 R2 Microsoft сделала функционал этого инструмента частично доступным прямо в консоли AD Users and Computers (в расширенном режиме работы при включенной Advanced Features), для этого достаточно в окне свойств объекта выбрать вкладку Attribute Editor.

Например, у контейнера ForeignSecurityPrincipals значение showInAdvancedViewOnly=False. Это означает, что данный контейнер не является скрытым.

Поменяем значение параметра showInAdvancedViewOnly на true, в результате данный контейнер перестанет отображаться в консоли ADUC.

Какие же из стандартных контейнеров в AD можно скрыть?

Builtin: можно скрыть. В этом контейнере содержатся стандартные (встроенные) группы AD: Account Operators, Backup Operators, Event Log Readers, Guests, Server Operators и т.д. Состав этих групп меняется редко.

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

Users: можно скрыть. Несмотря на свое название, данный контейнер не рекомендуется использовать для создания и хранения пользовательских учетных записей. В OU Users хранятся такие важные доменные группы, как Domain Admins, Enterprise Admins, Schema Admins и т.д.

Managed Service Accounts: контейнер появился в Windows 2008 R2 и используется для управления сервисными учетными записями. Также можно скрыть.

Computers: стандартный OU для компьютеров, добавляемых в домен (например, с помощью первого способа, описанного в статье Как включить Windows 8 в домен). Согласно документации Microsoft, не рекомендуется использовать данный контейнер для повседневной работы. Учетные записи, появляющиеся здесь нужно переносить в продуктивные OU (в зависимости от структуры каталога), либо же с помощью команды redircmp перенаправлять компьютеры сразу в новую OU (подробнее описано в статье Замена стандартного OU Computers в AD).

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

Корректный 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-ам с помощью следующего атрибута

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

Многие системные администраторы Windows 2000 и Windows NT убедились, что разработка обычных сценариев для управления инфраструктурой принципиально отличается от использования традиционных графических инструментальных средств. Тем, кто придерживается такой точки зрения, я советую изучить технологию Windows Script (WS) и сопутствующие ей, в частности Active Directory Service Interfaces (ADSI). Писать пользовательские сценарии для управления средой не требуется, а создавать сценарии для Active Directory (AD), позволяющие осуществлять администрирование, становится намного проще. В этой статье я расскажу о трех основных интерфейсах в ADSI (IADsOpenDSObject, IADs и IADsContainer) и покажу, каким образом, используя эти основные интерфейсы, можно выполнить более 80% обычных задач управления AD.

Что такое ADSI?

Интерфейс ADSI — это набор COM-объектов для программирования, которые позволяют единообразно манипулировать многочисленными гетерогенными каталогами. Интерфейс ADSI — это основной программный интерфейс к AD, разработанный Microsoft, его используют все графические средства управления AD.

Изначально ADSI поддерживал протоколы Lightweight Directory Access Protocol version 3 (LDAPv3), NT 4.0 SAM, Novell Directory Services (NDS) и NetWare Bindery. Поскольку ADSI поддерживает LDAP, он может использоваться для управления каталогами, основанными на LDAP/X.500, включая Windows 2000 AD, Microsoft Exchange Server 5.5 и Site Server 3.0. Хотя я буду рассматривать именно AD, многие принципы, обсуждаемые в этой статье, применимы и к другим каталогам.

Так как интерфейс ADSI предназначен для программирования, его можно применять для написания сценариев управления каталогом в любой COM-совместимой среде, включая Windows Script Host (WSH), VBScript, JScript и ActivePerl. Интерфейс ADSI также поддерживает быстродействующие, только для чтения, запросы ActiveX Data Objects (ADO) через OLE DB.

ADSI устанавливает интерфейсы на стороне клиента. Это означает, что инсталлировать его нужно только на тот компьютер, который запускает сценарии. Дополнительно устанавливать ADSI на целевые контроллеры домена не требуется. Система Win-dows 2000 включает ADSI, но если планируется запускать сценарии ADSI на компьютерах с Windows NT или Windows 9x, то его необходимо загрузить и установить. ADSI 2.5 — это текущая версия, которую можно загрузить с Web-сайта Microsoft по ADSI (http://www.microsoft.com/adsi). На сайте также размещены связанные с ADSI официальные документы и средства для разработчиков, например набор инструментальных средств разработки для ADSI (SDK).

Терминология AD и ADSI

Чтобы эффективно использовать ADSI, необходимо изучить терминологию сценариев AD.

AD — это служба каталогов (DS) Win-dows 2000. DS — сетевая служба, которая идентифицирует и хранит информацию обо всех сетевых ресурсах и обеспечивает пользователям и приложениям доступ к ней. Служба каталогов AD — это распределенный иерархический тиражируемый каталог информации (Distributed information tree, DIT), который хранится в каталоге \%systemroot% tds на всех контроллерах домена Windows 2000 в фaйле ntds.dit. Можно обновить любую копию AD, и изменения AD будут тиражироваться на все контроллеры домена.

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

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

Компонент «схема» — это коллекция описаний классов и атрибутов; она определяет, какую информацию может хранить AD. Класс подобен шаблону для объекта, а атрибут — это свойство объекта (например, общее имя, описание, отличительное имя (DN)). Схема описывает обязательные и дополнительные атрибуты объекта. В рамках ADSI-сценариев можно получить доступ к схеме для установки обязательных и дополнительных свойств объектов. Кроме того, схема определяет структуру дерева каталога DIT. Объекты, которые могут содержать другие объекты, называются контейнерами; объекты, которые не могут содержать другие объекты, называются листьями.

Служба каталогов AD представляет сетевые ресурсы как объекты. С точки зрения AD объект есть заданный именованный набор свойств и связанных с ними значений, которые представляют конкретные сетевые ресурсы (например, компьютер, названный US-E-FN-01; группа, имеющая имя Investors, организационное подразделение OU с именем Finance, пользователь Джуди). С точки зрения программы или сценария объект есть экземпляр класса схемы.

Интерфейсы в ADSI являются механизмами, которые используются для модификации свойств объектов. Термин «интерфейс» — не единственный в ADSI. В программировании COM-интерфейс — это набор методов и свойств, которые предоставляет COM-объект. Методы оказывают некоторое воздействие на объект, а свойства характеризуют состояние объекта. Объекты COM могут предоставлять разнообразные интерфейсы. Например, ADSI обеспечивает более 50 интерфейсов. Однако всего три базовых интерфейса позволят выполнить многие задачи в AD.

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

Каждый объект в AD имеет несколько имен. Отличительное имя DN и относительное отличительное имя (RDN) являются основными в соглашении об именовании для обращения к объектам из сценариев ADSI. Имя DN определяет точное расположение объекта в дереве DIT, основанном на именах атрибутов. Имя RDN — это обязательный атрибут «имя» объекта. Соотношение между именами DN и RDN в AD подобно соотношению между полностью определенным путем к файлу и именем файла в файловой системе.

Каждый DN-компонент есть RDN, а каждый RDN есть строка, состоящая из двух частей (параметр и значение), которая изображается как «key=va-lue». Key идентифицирует реальный тип атрибута, а value является значением атрибута.

В документе Internet Engineering Task Force (IETF) Request for Comments (RFC) 2253, «Lightweight Directory Access Protocol (v.3): UTF-8 String Representation of Distinguished Na-mes», описаны параметры и типы атрибутов, которые используются для создания имен DN в LDAPv3. В Таблице 1 перечислены некоторые из обычно применяемых параметров и соответствующие типы атрибутов.

Приведу пример связи между DN и RDN. На Рисунке 1 показаны DN и RDN для пользователя Джуди Шнайдер. RDN для Джуди — это «cn=Judy Schneider»; cn — это параметр для общего имени атрибута, а строка «Judy Schneider» является значением. Мы можем проверить имя DN Джуди, чтобы определить его точное месторасположение в DIT. Джуди входит в подразделение Finance OU, а то, в свою очередь, относится к домену acme.com. Можно представить DN как комбинацию всех объектов RDN при перемещении от объекта к корню дерева.

Рисунок 1. Имена DN и RDN.

Имя DN объекта должно быть уникальным во всем каталоге, а RDN объекта должно быть уникальным в текущем контейнере. Параметр и знак равенства — это обязательные компоненты RDN. Типы объектов, которые не имеют конкретного параметра, используют по умолчанию общее имя параметра «cn=».


Общие задачи AD

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

Процесс написания любого ADSI-сценария включает несколько основных этапов. В следующем сценарии я перечислил действия, необходимые для создания объекта «пользователь» и управления им.

Компания Acme Widgets приглашает Джуди Шнайдер на работу в качестве инспектора. Джуди будет работать в финансовом подразделении компании — Finance OU. Вместе с системным администратором Acme Widgets совершим четыре шага для создания нового пользователя.

  1. Используя функцию GetObject VBScript, подсоединимся к целевому контейнеру («ou=Finance» в этом примере), который будет содержать нового пользователя.
  2. Используя метод Create из ADSI, создадим новый объект «пользователь» в локальном кэше свойств. Интерфейс IADsContainer предоставляет метод Create.
  3. Используя методы Put и PutEx из ADSI, установим обязательные и дополнительные свойства объекта «новый пользователь». Интерфейс IADs обеспечивает методы Put и PutEx.
  4. С помощью метода SetInfo из ADSI запишем новый объект в каталог. SetInfo также является частью интерфейса IADs.

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

Джуди выдвигается на пост финансового директора компании (CFO). Необходимо перевести Джуди из финансового подразделения (Finance OU) в руководство (Executive OU), для этого выполняем два шага.

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

  • Используя функцию GetObject из VBScript, подключаемся к целевому контейнеру («ou=Executive»), который содержит объект пользователя.
  • С помощью метода Delete из ADSI удаляем объект пользователя. Интерфейс IADsContainer предоставляет метод Delete.
  • В этом примере показаны основные шаги, которые являются общими для большинства сценариев ADSI. Приступая к выполнению каждой задачи, нужно подключиться к объекту. После подключения к объекту используются методы, содержащиеся в двух основных интерфейсах IADs и IADs-Container, с помощью которых и происходит управление жизненным циклом объекта.

    Эти основные шаги можно применять и к другим объектам в каталоге. Для этого нужно отвлечься от основных интерфейсов в ADSI и выполнить перечисленные шаги в сценарии на базе функций. Я использую easyadsi.vbs в качестве примера и исследую основной интерфейс IADsOpenDSObject. В Листинге 1 показана часть сценария, которая выполняет первые четыре шага для создания нового объекта пользователя. Полностью листинг можно загрузить с Web-сайта Win-dows 2000 Magazine по адресу: http://www.win2000mag.com/. (Введите 9168 в текстовом окне InstantDoc ID и загрузите файл 9168.zip.)

    Листинг 1. Файл Easyadsi.vbs.

    Подключение к AD

    Подключение — это первый шаг для взаимодействия с AD; соединение с объектом в LDAP называют запросом на привязку (bind request). Привязка — это точка в сценарии ADSI, в которой происходит процесс аутентификации. Внутренние LDAP-провайдеры интерфейса ADSI (adsldp.dll и wldap32.dll) создают и возвращают ссылку на указанный объект (например, домен, OU, группа, пользователь, принтер, служба, совместно используемый ресурс, сайт, класс схемы).

    Используем функцию GetObject из VBScript для привязывания к объекту AD. Строка, передаваемая в Get-Object, — это ADSI LDAP — путь, который идентифицирует целевой объект. Для связывания с объектом можно использовать несколько подходов, которые основаны на синтаксисе LDAP-пути. ADSI LDAP-путь необходимо начать с «LDAP:». Далее может следовать строка с дополнительными элементами, как показано в примере на Рисунке 2.

    Обязательный префикс «LDAP:» — это программный идентификатор (ProgID) для провайдера LDAP в ADSI. Идентификатор ADSI ProgIDs определяет ADSI провайдера DLL, через который сценарий поддерживает связь с каталогом. Идентификатор ADSI ProgIDs является чувствительным к регистру, поэтому для префикса «LDAP:» необходимо всегда использовать заглавные буквы. Остаток ADSI LDAP-пути нечувствителен к регистру.

    Дополнительные элементы LDAP-пути включают имя целевого сервера, IP-адрес, номер порта LDAP и DN. Элементы, добавляемые к префиксу «LDAP:», определяют, как ADSI привязывается к AD.

    Серверные привязки создаются при добавлении имени целевого сервера или IP-адреса как части LDAP-пути, что показано в примерах на Рисунке 3. Следует избегать привязок с явным указанием имени сервера или IP-адреса, потому что сценарий выдаст ошибку, если сервер окажется отключенным. Можно установить номер порта LDAP, если DS прослушивает другой порт, а не порт LDAP по умолчанию (порт 389). Однако не нужно беспокоиться о прослушивании AD по другому порту, потому что контроллеры домена Windows 2000 резервируют порт 389 для AD. Запросы без привязки к серверу удаляют зависимость, связанную с LDAP-путями, которые содержат явно указанные имена серверов. Поэтому целесообразнее использовать пути без имени сервера. Если не указать имя целевого сервера или его IP-адрес, ADSI выдает запрос к новому Win32 API (DSGetDCNa-me), который запрашивает DNS для поиска контроллера в домене, где зарегистрировался данный пользователь. Интерфейс ADSI пытается определить местоположение контроллера домена и подключиться к нему в локальном узле рабочей станции, основываясь на IP подсети. Если ADSI не может определить контроллер домена в узле, он использует первый ответивший сервер каталога.

    Пути LDAP без указания сервера обычно включают имя DN, которое идентифицирует целевой объект. В запросе на привязку, показанном в Листинге 1 под меткой А, я сделал привязку к Finance OU, которая находится в домене acme.com. Строковое значение в переменной strContainer указывает его местоположение.

    На Рисунке 4 показаны запросы на привязку, которые содержат другие виды путей LDAP без указания сервера. В первом примере на Рисунке 4 я выполнил привязку точно к de-faultNamingContext (где находятся объекты «пользователь», «компьютер», «группа» и OU) из домена acme.com. Во втором примере я сделал привязку к объекту конкретного пользователя. Третий пример является запросом на привязку без указания DN. При таком типе запроса ADSI создает привязку к специальному LDAPv3-объекту, Root Directory Ser-vice Entry (rootDSE), и использует свойство defaultNamingContext объекта rootDSE для привязки к корню DIT. Результат такой же, как и в первом примере, но использование запроса без указания DN снимает зависимость от специфики домена.

    Можно также явно сделать привязку к объекту rootDSE. Введенный в версии LDAPv3 rootDSE находится на вершине дерева DIT каждого контроллера домена. В отличие от принципа привязки без DN (например «LDAP:»), в котором rootDSE возвращает только имя DN для defaultNamingContext, привязка напрямую к rootDSE позволяет получить доступ ко всей информации о каталоге сервера, предоставившего объект rootDSE. В этой информации будут и имена DN для всех контекстов именования каталога. Как показано в Листинге 2, я использовал свойства defaultNa-mingContext, schemaNa-mingContext и configura-tionNamingContext объекта rootDSE, отмеченные как A, B и C, для привязки к корню каждого контекста именования каталога и просмотра высокоуровневых объектов.

    Листинг 2. Файл RootDSE.vbs.

    До сих пор я надеялся на имеющиеся у меня разрешения при проверке запроса на привязку. Хотя такой метод аутентификации достаточно эффективен, в некоторых случаях бывает необходимо указать другие учетные данные или соответствующий тип аутентификации. Интерфейс IADSOpenDSOb-ject из ADSI предоставляет для выполнения привязки к объекту метод OpenDSObject, который предполагает использование указанных пользователем учетных данных. Метод Open-DSObject допускает четыре параметра, которые перечислены в Таблице 2.

    В Листинге 1 показано, как использовать OpenDSObject вместо текущих учетных данных пользователя (метка B). Замените код с меткой A в Листинге 1 кодом с меткой B в Листинге 1 для использования Open-DSObject. Перед тем как обратиться к Open-DSObject, нужно ввести

    чтобы получить ссылку на провайдера LDAP. В качестве имени пользователя можно указать DN, User Principal Name (UPN), низкоуровневое учетное имя SAM (pre-Windows 2000) или Anonymous.

    Советы по привязкам

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

    1. Используйте текущие учетные данные всегда, когда это возможно.
    2. Никогда не применяйте явно указанные пароли в своих сценариях. При необходимости использовать пароль нужно создать запрос, адресованный пользователю, или извлечь пароль из системы безопасности. Затем следует сохранить его во временной переменной и уничтожить содержимое переменной сразу же после запроса на привязку.
    3. Используйте rootDSE, когда сценарий делает привязку к корню текущего домена.
    4. Избегайте явного указания имен серверов в путях LDAP.
    5. Делайте привязки к контейнерам для создания, перемещения и удаления объектов в контейнере.
    6. Делайте привязки к объектам-листьям для модификации свойств объекта.

    В следующей статье, посвященной ADSI, я планирую рассказать о двух других основных интерфейсах ADSI — IADs и IADsContainer. А пока рекомендую читателям попробовать привязаться к некоторым объектам в своем каталоге. Для большего эффекта советую включить Network Monitor и попытаться задействовать несколько методов привязки.

    БОБ УЭЛЛС — консультант по программному обеспечению; специализируется на вопросах проектирования и реализации инфраструктуры информационных систем, основанных на NT. Имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: bobwells@win2000mag.com.

    Таблица 1. LDAPv3 DNs.

    Key Attribute Type
    CN commonName
    L localityName
    ST stateOrProvinceName
    O organizationName
    OU organizationalUnitName
    C countryName
    STREET streetAddress
    DC domainComponent
    UID userid

    Поделитесь материалом с коллегами и друзьями

    Использование службы каталогов Active Directory Service Interface (ADSI)

    Использование службы каталогов Active Directory Service Interface (ADSI)

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

    Что касается компьютерных сетей (локальных или глобальных), здесь также уместно говорить о каталогах, содержащих объекты разных типов: зарегистрированные пользователи, доступные сетевые принтеры и очереди печати и т.д. Для пользователей сети важно уметь находить и использовать такие объекты (а их в крупной сети может быть огромное количество), администраторы же сети должны поддерживать эти объекты в работоспособном состоянии. Под службой каталога (directory service) понимается та часть распределенной компьютерной системы (компьютерной сети), которая предоставляет средства для поиска и использования имеющихся сетевых ресурсов. Другими словами, служба каталога — это единое образование, объединяющее данные об объектах сети и совокупность служб, осуществляющих манипуляцию этими данными.

    В гетерогенной (неоднородной) компьютерной сети могут одновременно функционировать несколько различных служб каталогов, например, NetWare Bindery для Novell Netware 3.x, NDS для Novell NetWare 4.x/5.x, Windows Directory Service для Windows NT 4.0 или Active Directory для Windows 2000. Естественно, для прямого доступа к разным службам каталогов приходится использовать разные инструментальные средства, что усложняет процесс администрирования сети в целом. Для решения этой проблемы можно применить технологию ADSI — Active Directory Service Interface фирмы Microsoft, которая предоставляет набор объектов ActiveX, обеспечивающих единообразный, не зависящий от конкретного сетевого протокола, доступ к функциям различных каталогов.

    Объекты ADSI включены в операционные системы Windows ХР/2000, а также могут быть установлены в более ранних версиях, для чего их нужно скачать с сервера Microsoft (http://www.microsoft.com/NTWorkstation/downloads/Other/ADSI25.asp).

    Для того чтобы находить объекты в каталоге по их именам, необходимо определить для этого каталога пространство имен (namespace). Скажем, файлы на жестком диске находятся в пространстве имен файловой системы. Уникальное имя файла определяется расположением этого файла в пространстве имен, например:

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

    ? «LDAP://» — для службы каталогов, созданной на основе протокола LDAP (Lightweight Directory Access Protocol), в том числе для Active Directory в Windows 2000;

    ? «WinNT://» — для службы каталогов в сети Windows NT 4.0 или на локальной рабочей станции Windows ХР/2000;

    ? «NDS://» — для службы каталогов NetWare NDS (Novell Directory Service);

    ? «NWCOMPAT://» — для службы каталогов NetWare Bindery.

    Вторая часть строки ADsPath определяет расположение объекта в конкретном каталоге. Приведем несколько примеров полных строк ADsPath:

    В этом разделе мы подробно рассмотрим несколько простых сценариев, использующих объекты ADSI для автоматизации некоторых распространенных задач администрирования на отдельной рабочей станции с операционной системой Windows ХР; поняв принцип их работы, вы без труда сможете написать аналогичные сценарии для локальной сети, которая функционирует под управлением Active Directory или контроллера домена с Windows NT 4.0 (множество подобных примеров приведено в [18]).

    Напомним, что на выделенном компьютере с Windows ХР имеется база данных, содержащая информацию обо всех локальных пользователях этого компьютера. Пользователи компьютера определяются своими атрибутами (имя регистрации, полное имя, пароль и т.п.) и могут объединяться в группы. Ниже мы приведем примеры сценариев WSH, с помощью которых можно:

    ? получить список имеющихся в локальной сети доменов;

    ? получить список всех групп, определенных на компьютере;

    ? добавить и удалить пользователя компьютера;

    ? определить всех пользователей заданной группы или все группы, в которые входит определенный пользователь;

    ? просмотреть атрибуты пользователя и изменить его пароль.

    Для получения более полной информации по технологии ADSI следует обратиться к документации Microsoft или специальной литературе (см. введение).


    Скрываем неиспользуемые контейнеры в Active Directory

    Открыв оснастку Active Directory Users and Computers (ADUC), первое что мы видим — это контейнеры (Organization Unit, OU), в которые помещаются учетные записи пользователей, компьютеров и групп. В зависимости от размера и структуры организации количество OU может быть весьма большим.

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

    Вот так выглядит оснастка ADUC сразу после установки служб Active Directory. По умолчанию в ней отображаются следующие контейнеры:

    • Builtin — контейнер, который содержит встроенные группы безопасности (Administrators, Backup Operators, Event Log Readers и т.п);
    • Computers — контейнер для компьютеров по умолчанию;
    • Domain Controllers — контейнер для контроллеров домена;
    • ForeignSecurityPrincipals — контейнер, исползуемый для хранения идентификаторов безопасности (SID), связанных с доверенными доменами;
    • Managed Service Accounts — контейнер для управляемых учетных записей служб;
    • Users — контейнер для пользователей и групп по умолчанию. В нем содержатся такие важные группы, как Domain, Enterprise и Schema Admins.

    Но это далеко не все, на самом деле контейнеров намного больше. Чтобы увидеть их все, надо в меню View отметить опцию «Advanced Features», переключив тем самым оснастку ADUC в расширенный режим.

    А вот так выглядит оснастка ADUC в расширенном режиме. Как видите, редко используемые (по мнению Microsoft) объекты скрыты и отображаются только в расширенном режиме. Впрочем, любой контейнер в AD можно сделать скрытым, и он не будет виден в стандартном режиме.

    Для этого нужно изменить атрибут showInAdvancedViewOnly, который и отвечает за видимость контейнера в AD. Начиная с Windows Server 2008 сделать это можно прямо из оснастки ADUC, работающей в расширенном режиме (при включенной Advanced Features).

    Итак, предположим мы хотим скрыть контейнер Users. Кликаем по нему правой клавишей и в контекстном меню выбираем пункт Свойства (Properties).

    Открывается окно свойств объекта. Находим в нем атрибут showInAdvancedViewOnly и смотрим на его значение. Для данного контейнера оно равно False, то есть контейнер не является скрытым. Для редактирования атрибута жмем кнопку Edit.

    Изменяем значение на True и жмем ОК. Теперь контейнер будет виден только в расширенном режиме работы оснастки ADUC.

    То же самое можно сделать с помощью редактора ADSI Edit. Запускаем его и подключаемся с настройками по умолчанию.

    Находим нужный контейнер (напр. CN=Users), кликаем на нем правой клавишей и выбираем «Properties».

    Находим нужный атрибут и редактируем его.

    Таким образом мы можем убрать из оснастки ADUC все лишнее, оставив только самые необходимые контейнеры. Вот так выглядит оснастка после «зачистки», ничего лишнего.

    Архитектура 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 рассматриваемый позже.

    Как скрыть контейнеры в Active Directory

    Сразу после установки нового домена Active Directory в корне консоли Active Directory User and Computers (ADUC) появляется несколько предопределенных служебных контейнеров (OU). Большинство из них редко используются при повседневном администрировании Active Directory, однако занимают место в консоли, и «мозолят» глаза администратору AD. В этой статье мы разберемся, как можно скрыть ненужные контейнеры AD в консоли AD Users and Computers.

    Напомним, по-умолчанию, в консоли ADUC отображаются следующие контейнеры:

    На самом деле объектов верхнего уровня намного больше, чтобы отобразить все, в том числе скрытые объекты AD с расширенными атрибутами, в консоли ADUC нужно в меню View отметить опцию “Advanced Features”.

    Microsoft таким образом просто «скрыла» достаточно редко используемые стандартные элементы каталога AD, ежедневный доступ к которым не требуется (если вообще нужен). Каким образом любой OU в AD сделать скрытым, чтобы он не отображался в обычном режиме работы консоли ADUC?

    Для этого нужно изменить атрибут, управляющий видимостью любого контейнера в AD под названием showInAdvancedViewOnly. Данный атрибут впервые появился еще в версии AD Windows 2000 Server. Для его правки в Windows 2000/Windows 2003 нужно было устанавливать специальную консоль ADSIEDIT (входящую в состав утилит администратора Windows — Support Tools). В Windows 2008 /2008 R2 Microsoft сделала функционал этого инструмента частично доступным прямо в консоли AD Users and Computers (в расширенном режиме работы при включенной Advanced Features), для этого достаточно в окне свойств объекта выбрать вкладку Attribute Editor.

    Например, у контейнера ForeignSecurityPrincipals значение showInAdvancedViewOnly=False. Это означает, что данный контейнер не является скрытым.

    Поменяем значение параметра showInAdvancedViewOnly на true, в результате данный контейнер перестанет отображаться в консоли ADUC.

    Какие же из стандартных контейнеров в AD можно скрыть?

    Builtin: можно скрыть. В этом контейнере содержатся стандартные (встроенные) группы AD: Account Operators, Backup Operators, Event Log Readers, Guests, Server Operators и т.д. Состав этих групп меняется редко.

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

    Users: можно скрыть. Несмотря на свое название, данный контейнер не рекомендуется использовать для создания и хранения пользовательских учетных записей. В OU Users хранятся такие важные доменные группы, как Domain Admins, Enterprise Admins, Schema Admins и т.д.

    Managed Service Accounts: контейнер появился в Windows 2008 R2 и используется для управления сервисными учетными записями. Также можно скрыть.

    Computers: стандартный OU для компьютеров, добавляемых в домен (например, с помощью первого способа, описанного в статье Как включить Windows 8 в домен). Согласно документации Microsoft, не рекомендуется использовать данный контейнер для повседневной работы. Учетные записи, появляющиеся здесь нужно переносить в продуктивные OU (в зависимости от структуры каталога), либо же с помощью команды redircmp перенаправлять компьютеры сразу в новую OU (подробнее описано в статье Замена стандартного OU Computers в AD).

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

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