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


Содержание

Получить активные объекты контейнера каталога для нового пользователя

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

Как будет выглядеть запрос LDAP для захвата дочерних элементов node, подходящих для пользовательского объекта? Есть ли лучший способ сделать это?

Я использую С#, System.DirectoryServices и .net 3.5, если вам интересно.

Ознакомьтесь с отличной статьей MSDN «Управление принципами безопасности каталогов» в .NET Framework 3.5 о том, как использовать новые функции в System.DirectoryServices.AccountManagement в .NET 3.5, если вы еще этого не сделали.

Чтобы привязываться к вашему контейнеру, вам нужно знать его путь LDAP, и с этим вы можете установить контекст, основанный на этом контейнере:

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

Это работает для вас? Это то, что вы ищете?

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

Я думаю, вы можете получить ответ из раздела схемы AD. Я быстро проверил свой раздел схемы, который работает под управлением Windows 2003 AD. Объекту User разрешено назначать OU, контейнеру, builtinDomain и domainDNS.

Я не проверял Windows 2008, но считаю, что он должен быть таким же. Многие люди знают, что такое OU и контейнер. Мало кто знает, что такое builtinDomain и domainDNS. Я сомневаюсь, что это полезно в вашем случае. builtinDomain — специальный контейнер, используемый для хранения встроенной учетной записи. По умолчанию AD создал встроенный домен в CN=Builtin,DC=yourdomain,DC=com . domainDNS — это путь вашего корневого домена DC=yourdomain,DC=com .

Вот функция поиска всех объектов в Active Directory под определенным node. Если вы считаете, что builtinDomain и domainDNS не имеют смысла в вашем случае, просто выньте его из фильтра LDAP.

Как скрыть контейнеры в 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 в «расширенный вид».


get active directory container objects for new user

I want to create a tree of container objects in an active directory domain that a new user can be added to. I can recurse through the domain and get everything within the directory, but I want to limit my scope to ONLY containers that are valid for users.

What would an LDAP query look like to grab the children of a node that were suitable for a user object? Is there a better way to do this?

I’m using c#, System.DirectoryServices, and .net 3.5 if you are curious.

2 Answers 2

Check out the excellent MSDN article Managing Directory Security Principals in the .NET Framework 3.5 on how to use the new features in System.DirectoryServices.AccountManagement in .NET 3.5, if you haven’t already.

In order to bind to your container, you need to know it’s LDAP path and with this, you can establish a context based on that container:

With this context, you can now e.g. search for certain types of principals in that context:

Does that work for you? Is that what you’re looking for?

If I understand your question correctly, what you want to know is what kind of objects in Active Directory can contain User object.

I think you can get the answer from the AD schema partition. I had a quick check on my schema partition which is running Windows 2003 AD. The User object is allowed to be assigned to OU, container, builtinDomain and domainDNS.

I didn’t check Windows 2008 but I believe it should be the same. Many people know what OU and container are. Few people know what builtinDomain and domainDNS are. I doubt if it’s useful in your case. builtinDomain is a special container used to contain the built-in account. By default, AD created a builtinDomain at CN=Builtin,DC=yourdomain,DC=com . domainDNS is your root domain path DC=yourdomain,DC=com .

Here is a function to find all kinds of objects in Active Directory under a particular node. If you think builtinDomain and domainDNS is not meaningful in your case, just take it out from the LDAP filter.

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 выполняться не будут.

Илон Маск рекомендует:  Что такое код wml

Безопасность. Интегрированные с 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-сервер. Таким образом, произвольная регистрация имен становится невозможной.

Прикручиваем LDAP-авторизацию к Kubernetes

Небольшая инструкция о том, как используя Keycloak можно связать Kubernetes с вашим LDAP-сервером и настроить импорт пользователей и групп. Это позволит настраивать RBAC для ваших пользователей и использовать auth-proxy чтобы защитить Kubernetes Dashboard и другие приложения, которые не умеют производить авторизацию самостоятельно.

Установка Keycloak

Предположим что у вас уже есть LDAP-сервер. Это может быть Active Directory, FreeIPA, OpenLDAP или что-либо еще. Если LDAP-сервера у вас нет, то в принципе вы можете создавать пользователей прямо в интерфейсе Keycloak, либо использовать публичные oidc-провайдеры (Google, Github, Gitlab), результат получится почти такой же.


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

Для хранения данных Keycloak вам понадобится база данных. По умолчанию используется h2 (все данные хранятся локально), но возможно также использовать postgres , mysql или mariadb .
Если вы все же надумали установить Keycloak отдельно, более подробные инструкции вы найдете в официальной документации.

Настройка федерации

Первым делом создадим новый realm. Realm — это пространство нашего приложения. Каждое приложение может иметь свой realm с разными пользователями и настройками авторизации. Master realm используется самим Keycloak и использовать его для чего-нибудь еще неправильно.

Нажимаем Add realm

Option Value
Name kubernetes
Display Name Kubernetes
HTML Display Name

Kubernetes по умолчанию проверяет подтвержден у пользователя email или нет. Так как мы используем собственный LDAP-сервер, то тут эта проверка почти всегда будет возвращать false . Давайте отключим представление этого параметра в Kubernetes:

Client scopes Email Mappers Email verified (Delete)

Теперь настроим федерацию, для этого перейдем в:

User federation Add provider. ldap

Приведу пример настройки для FreeIPA:

Option Value
Console Display Name freeipa.example.org
Vendor Red Hat Directory Server
UUID LDAP attribute ipauniqueid
Connection URL ldaps://freeipa.example.org
Users DN cn=users,cn=accounts,dc=example,dc=org
Bind DN u >
Bind Credential
Allow Kerberos authentication: on
Kerberos Realm: EXAMPLE.ORG
Server Principal: HTTP/freeipa.example.org@EXAMPLE.ORG
KeyTab: /etc/krb5.keytab

Пользователя keycloak-svc нужно создать заранее на нашем LDAP-сервере.

В случае с Active Directory, достаточно просто выбрать Vendor: Active Directory и необходимые настройки подставятся в форму автоматически.

Нажимаем Save

User federation freeipa.example.org Mappers First Name

Option Value
Ldap attribure givenName

Теперь включим маппинг групп:

User federation freeipa.example.org Mappers Create

Option Value
Name groups
Mapper type group-ldap-mapper
LDAP Groups DN cn=groups,cn=accounts,dc=example,dc=org
User Groups Retrieve Strategy GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

На этом настройка федерации закончена, перейдем к настройке клиента.

Настройка клиента

Создадим нового клиента (приложение которое будет получать пользователей из Keycloak). Переходим:

Clients Create

Option Value
Client ID kubernetes
Access Type confidenrial
Root URL http://kubernetes.example.org/
Valid Redirect URIs http://kubernetes.example.org/*
Admin URL http://kubernetes.example.org/

Так же создадим scope для групп:


Client Scopes Create

Option Value
Template No template
Name groups
Full group path false

И настроим mapper для них:

Client Scopes groups Mappers Create

Option Value
Name groups
Mapper Type Group membership
Token Claim Name groups

Теперь нам нужно включить маппинг груп в нашем client scope:

Clients kubernetes Client Scopes Default Client Scopes

Выбираем groups в Available Client Scopes, нажимаем Add selected

Теперь настроим аутентификацию нашего приложения, переходим:

Clients kubernetes

Option Value
Authorization Enabled ON

Нажимем save и на этом настройка клиента завершена, теперь на вкладке

Clients kubernetes Credentials

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

Настройка Kubernetes

Настройка Kubernetes для OIDC-авторизации достаточно тривиальна и не является чем-то очень сложным. Все что вам нужно это положить CA-сертификат вашего OIDC-сервера в /etc/kubernetes/pki/oidc-ca.pem и добавить необходимые опции для kube-apiserver.
Для этого обновите /etc/kubernetes/manifests/kube-apiserver.yaml на всех ваших мастерах:

А так-же обновите kubeadm конфиг в кластере, что бы не потерять эти настройки при обновлении:

На этом настройка Kubernetes завершена. Вы можете повторить данные действия во всех ваших Kubernetes-кластерах.

Начальная авторизация

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

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

Для настройки Kuberos достаточно описать template для kubeconfig и запустить со следующими параметрами:

Для более детальной информации смотрите Usage на Github.

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

Полученный kubeconfig можно проверить на сайте jwt.io. Просто скопируейте значение users[].user.auth-provider.config.id-token из вашего kubeconfig в форму на сайте и сразу получите расшифровку.

Настройка RBAC

При настройке RBAC можно ссылаться как на имя пользователя (поле name в jwt-токене), так и на группу пользователей (поле groups в jwt-токене). Вот пример настройки прав для группы kubernetes-default-namespace-admins :


Больше примеров для RBAC можно найти в официальной документации Kubernetes

Настройка auth-proxy

Есть замечательный проект keycloak-gatekeeper, который позволяет защитить любое приложение, предоставляя пользователю возможность аутентифицироваться на OIDC-сервере. Я покажу как можно настроить его на примере Kubernetes Dashboard:

Сценарии для 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

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

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

    Thank you for your examples. I had try the codes,
    but I do not know «o=BSP». If I have a domain name
    called «mksh.phc.edu.tw», how can I set the «o=??»

    Thanks for your advice.

    Sincerely,
    ZenJohn Sign In· View Thread

    LDAP query slows down too long

    emmpergul 1-Aug-06 11:02
    Hi Christian!

    Great example. I’ve modified it and worked perfect but when trying to view the page containing the ldap query takes too long to be displayed(between 10 seconds and 1 min)

    Do you know what can i do for it to take a little time to be displayed?

    Any suggestions are welcomed

    pguths 24-Nov-05 8:55
    I get a message «The page cannot be found»
    after clicking the Abschiken button.
    I think a index_exchange.asp file is needed.

    Paulo Cesar

    Sign In· View Thread
    Re: Where is index_exchange.asp?

    Christian Kiefer 30-Nov-05 22:15

    This is a fault in the Script.

    This script calls himself, so please change the filename in the form-tag from «index_exchange.asp» to «example_exchange.asp».

    regards
    christian kiefer

    Sign In· View Thread
    LDAP:// protocol in web browser

    Spanish Poop 31-Oct-05 12:38
    I wonder if it is possible to pass ldap parameters by typing in the address bar the following:


    In my case it will open wab.exe, the MS Outlook directory lookup program.

    It does not work (in my case) probably because either I am putting the wrong parameter values, the way to pass parameters is different (i.e. ldap://exchange01?cd=recipients&ou=Mannheim&o=BSP) or I have no access to ldap

    «Exchange01» is the server
    «o=BSP» the organisation
    «ou=Mannheim» the location

    Did it work with anybody?

    Christian Kiefer 1-Nov-05 0:20

    First of all, it must be assured that the internet user or the user which wil start the script, has got access to the LDAP directory.

    regards
    christian kiefer

    Sign In· View Thread
    where is the exchange server?

    explosure999 15-Aug-05 0:17
    I am a new guy in LDAP, can I know the hostname of exchange server or IP, so that I can test the code and learn. Aaron31 18-Jul-05 17:29
    WHY IS IT SOOO HARD TO GET A CODE SAMPLE THAT JUST WORKS. Christian Kiefer 26-Jul-05 23:18

    The script must have the correct rigths to access the Exchenge-Server

    regards
    christian kiefer

    Sign In· View Thread
    Exchange 5.5

    Offlinesurfer 30-Sep-04 12:46
    Hi, I have been using vbscript to manipulate Recipient Containers and DL’s, how can this be done with C#? Christian Kiefer 28-Oct-04 23:40

    regards
    christian kiefer

    Sign In· View Thread
    select box is empty

    lizm100 23-Jul-04 6:50
    Hi,
    Thank you for this. I have a problem though, the select box is empty.

    I can get your search_exchange script to work brilliantly by adding.
    oConn.Open «Ads Prov
    (before this I got a ‘permission denied’ error)

    I’m guessing I need to add the user and password to this script aswell for it to work for me, but am unsure of where to put it as you use ‘GetObject’.

    Any help would be appreciated.

    Thanks

    Sign In· View Thread
    Re: select box is empty

    Anonymous 8-Oct-04 2:20
    I’ve created an User which has rights to use Exchange.
    The script runs under this User
    Sign In· View Thread
    Thank you Thomas Felting 10-May-04 23:46
    Thank you for this example
    Sign In· View Thread
    Last Visit: 12-Nov-19 1:15 Last Update: 12-Nov-19 1:15 Refresh 1

    General News Suggestion Question Bug Answer Joke Praise Rant Admin

    Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

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

    Все сертификаты центра сертификации (ЦС) в домене Active Directory текущего леса хранятся в контейнере NTAuthCertificates. Сертификаты ЦС предприятия автоматически добавляются при установке нового центра сертификации.


    Если сертификат ЦС не добавляется автоматически при создании нового ЦС, например автономного ЦС, созданного пользователем, который не является участником группы «Администраторы предприятия», сертификат ЦС, тем не менее, можно добавить в контейнер NTAuthCertificates вручную. Эту процедуру также можно использовать для добавления сертификата ЦС, созданного сторонним центром сертификации, который используется для выпуска сертификатов входа с помощью смарт-карт или контроллера домена. Публикуя сертификаты таких ЦС в хранилище NTAuth предприятия, администратор тем самым показывает, что ЦС является доверенным для выпуска сертификатов этих типов.

    Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы предприятия или аналогичной.

    Добавление сертификата в контейнер NTAuthCertificates с помощью интерфейса Windows

    Экспортируйте сертификат ЦС в CER-файл, который поддерживает либо двоичный формат в кодировке DER (Distinguished Encoding Rules), либо формат X.509 в кодировке base-64.

    Откройте оснастку «PKI предприятия», правой кнопкой мыши щелкните PKI предприятия в дереве консоли и выберите команду Управление контейнерами AD.

    Выберите контейнер NTAuthCertificates.

    Нажмите кнопку Добавить и перейдите к CER-файлу добавляемого сертификата. Нажмите кнопку ОК.

    Добавить сертификат в контейнер NTAuthCertificates можно и при помощи программы командной строки Certutil.

    Добавление сертификата в контейнер NTAuthCertificates с помощью командной строки

    Выполните экспорт сертификата ЦС в CER-файл, который поддерживает либо двоичный формат в кодировке DER, либо формат X.509 в кодировке base-64.

    Откройте окно командной строки, введите следующую команду и нажмите клавишу ВВОД:

    Getting Started with ASP for ADSI

    ADSI can be used to access directory data using an ASP page. This can be a convenient way to run administration tasks and queries from a webpage or provide information to employees on an intranet.

    One advantage of using ADSI with ASP is that you can create a richer user experience because you can use Visual Basic to create an ADSI application and offer it to a user through a standard webpage. For example, you could create a webpage that enables employees to enter the last name of an employee and get back a phone number for that employee, or create a form that allows employees to update personal information in a company human resources database.

    ASP code starts with ‘ ‘. You can add ADSI code as VBScript or Visual Basic.

    To create an ASP page, you can use a webpage editor, Notepad or other text editor, or the Microsoft Visual Studio .NET development system.

    Before you run your ASP page, set up your application or IIS server according to the instructions found in Authentication Issues for ADSI with ASP.

    A Simple ASP Sample: Enumerating Objects in a Container

    Using a webpage editor, create a new html page which accepts the distinguished name of a container object. Enter the following code example.

    This page can now accept a container name that is passed to it and use ADSI to enumerate objects in the container.

    Обзор Active Directory. Введение в службы каталогов. Объекты, схема и компоненты Active Directory , страница 3

    r Подписываемый и зашифрованный трафик LDAP. Инструменты Active Directory в со­ставе Windows Server 2003 подписывают и шифруют весь трафик LDAP по умолча­нию. Это гарантирует получение пакетов данных из известного источника и исклю­чает злонамеренное вмешательство.

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

    Рисунок 2. Объекты и атрибуты Active Directory

    Существует категория объектов, в состав которых могут входить другие объекты. Они называются контейнерами(containers). К примеру, домен, являясь контейнером, может содержать объекты учетных записей пользователей и компьютеров. Изображенная на рис. 2 папка Users представляет собой контейнер, включающий в себя объекты пользо­вательских учетных записей.

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

    Схема определяется двумя типами объектов: объектами классов схемы (которые так­же называются классами схемы) и объектами атрибутов схемы (атрибутами схемы). Как видно на рис. 3, объекты классов и объекты атрибутов определены в разных списках схемы. У объектов классов схемы и объектов ее атрибутов есть два собирательных на­звания: объекты схемы (schema objects) и метаданные (metadata).

    Объекты классов схемы(schema class objects) описывают объекты, которые можно со­здавать в Active Directory. Класс схемы исполняет роль шаблона для создания новых объек­тов Active Directory. Каждый класс схемы представляет собой совокупность объектов ат­рибутов схемы. При создании класса схемы информация, характеризующая объект, со­храняется именно в их составе, например класс Userсостоит из множества атрибутов схе­мы, — в том числе, Network Addressи Ноте Directory. Каждый объект, управляемый Active Directory, фактически является экземпляром того или иного объекта класса схемы.

    Объекты атрибутов схемы(schema attribute objects) определяют объекты классов схе­мы, с которыми они ассоциированы. Несмотря на то, что атрибуты схемы определяются единожды, их можно задействовать во множестве классов. Взять хотя бы атрибут Description применяемый в самых разных классах, он определен только в одной схеме, за счет чего обеспечивается непротиворечивость.

    Рисунок 3. Объекты классов и атрибутов схемы

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

    • АлтГТУ 419
    • АлтГУ 113
    • АмПГУ 296
    • АГТУ 266
    • БИТТУ 794
    • БГТУ «Военмех» 1191
    • БГМУ 172
    • БГТУ 602
    • БГУ 153
    • БГУИР 391
    • БелГУТ 4908
    • БГЭУ 962
    • БНТУ 1070
    • БТЭУ ПК 689
    • БрГУ 179
    • ВНТУ 119
    • ВГУЭС 426
    • ВлГУ 645
    • ВМедА 611
    • ВолгГТУ 235
    • ВНУ им. Даля 166
    • ВЗФЭИ 245
    • ВятГСХА 101
    • ВятГГУ 139
    • ВятГУ 559
    • ГГДСК 171
    • ГомГМК 501
    • ГГМУ 1967
    • ГГТУ им. Сухого 4467
    • ГГУ им. Скорины 1590
    • ГМА им. Макарова 300
    • ДГПУ 159
    • ДальГАУ 279
    • ДВГГУ 134
    • ДВГМУ 409
    • ДВГТУ 936
    • ДВГУПС 305
    • ДВФУ 949
    • ДонГТУ 497
    • ДИТМ МНТУ 109
    • ИвГМА 488
    • ИГХТУ 130
    • ИжГТУ 143
    • КемГППК 171
    • КемГУ 507
    • КГМТУ 269
    • КировАТ 147
    • КГКСЭП 407
    • КГТА им. Дегтярева 174
    • КнАГТУ 2909
    • КрасГАУ 370
    • КрасГМУ 630
    • КГПУ им. Астафьева 133
    • КГТУ (СФУ) 567
    • КГТЭИ (СФУ) 112
    • КПК №2 177
    • КубГТУ 139
    • КубГУ 107
    • КузГПА 182
    • КузГТУ 789
    • МГТУ им. Носова 367
    • МГЭУ им. Сахарова 232
    • МГЭК 249
    • МГПУ 165
    • МАИ 144
    • МАДИ 151
    • МГИУ 1179
    • МГОУ 121
    • МГСУ 330
    • МГУ 273
    • МГУКИ 101
    • МГУПИ 225
    • МГУПС (МИИТ) 636
    • МГУТУ 122
    • МТУСИ 179
    • ХАИ 656
    • ТПУ 454
    • НИУ МЭИ 641
    • НМСУ «Горный» 1701
    • ХПИ 1534
    • НТУУ «КПИ» 212
    • НУК им. Макарова 542
    • НВ 777
    • НГАВТ 362
    • НГАУ 411
    • НГАСУ 817
    • НГМУ 665
    • НГПУ 214
    • НГТУ 4610
    • НГУ 1992
    • НГУЭУ 499
    • НИИ 201
    • ОмГТУ 301
    • ОмГУПС 230
    • СПбПК №4 115
    • ПГУПС 2489
    • ПГПУ им. Короленко 296
    • ПНТУ им. Кондратюка 119
    • РАНХиГС 186
    • РОАТ МИИТ 608
    • РТА 243
    • РГГМУ 118
    • РГПУ им. Герцена 124
    • РГППУ 142
    • РГСУ 162
    • «МАТИ» — РГТУ 121
    • РГУНиГ 260
    • РЭУ им. Плеханова 122
    • РГАТУ им. Соловьёва 219
    • РязГМУ 125
    • РГРТУ 666
    • СамГТУ 130
    • СПбГАСУ 318
    • ИНЖЭКОН 328
    • СПбГИПСР 136
    • СПбГЛТУ им. Кирова 227
    • СПбГМТУ 143
    • СПбГПМУ 147
    • СПбГПУ 1598
    • СПбГТИ (ТУ) 292
    • СПбГТУРП 235
    • СПбГУ 582
    • ГУАП 524
    • СПбГУНиПТ 291
    • СПбГУПТД 438
    • СПбГУСЭ 226
    • СПбГУТ 193
    • СПГУТД 151
    • СПбГУЭФ 145
    • СПбГЭТУ «ЛЭТИ» 380
    • ПИМаш 247
    • НИУ ИТМО 531
    • СГТУ им. Гагарина 114
    • СахГУ 278
    • СЗТУ 484
    • СибАГС 249
    • СибГАУ 462
    • СибГИУ 1655
    • СибГТУ 946
    • СГУПС 1513
    • СибГУТИ 2083
    • СибУПК 377
    • СФУ 2423
    • СНАУ 567
    • СумГУ 768
    • ТРТУ 149
    • ТОГУ 551
    • ТГЭУ 325
    • ТГУ (Томск) 276
    • ТГПУ 181
    • ТулГУ 553
    • УкрГАЖТ 234
    • УлГТУ 536
    • УИПКПРО 123
    • УрГПУ 195
    • УГТУ-УПИ 758
    • УГНТУ 570
    • УГТУ 134
    • ХГАЭП 138
    • ХГАФК 110
    • ХНАГХ 407
    • ХНУВД 512
    • ХНУ им. Каразина 305
    • ХНУРЭ 324
    • ХНЭУ 495
    • ЦПУ 157
    • ЧитГУ 220
    • ЮУрГУ 306

    Полный список ВУЗов

    Чтобы распечатать файл, скачайте его (в формате Word).

    Илон Маск рекомендует:  Что такое код domnode >node_type
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL