Active directory service interfaces: Processing Active Directory Information in SSIS — TechNet Articles — United States (English)

Развертывание Active Directory | Yandex.Cloud

В сценарии приводится пример развертывания Active Directory в Yandex.Cloud.

Чтобы развернуть инфраструктуру Active Directory:

1. Подготовьте облако к работе
2. Необходимые платные ресурсы
3. Создайте облачную сеть и подсети
4. Создайте скрипт для управления локальной учетной записью администратора
5. Создайте ВМ для Active Directory
6. Создайте ВМ для бастионного хоста
7. Установите и настройте Active Directory
8. Настройте второй контроллер домена
9. Проверьте работу Active Directory
10. Удалите созданные ресурсы

Подготовьте облако к работе

Перед тем, как разворачивать серверы, нужно зарегистрироваться в Yandex.Cloud и создать платежный аккаунт:

1. Перейдите в консоль управления, затем войдите в Yandex.Cloud или зарегистрируйтесь, если вы еще не зарегистрированы.
2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его.

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

Подробнее об облаках и каталогах.

Необходимые платные ресурсы

В стоимость инсталляции Active Directory входят:

Создайте облачную сеть и подсети

Создайте облачную сеть ad-network с подсетями во всех зонах доступности, где будут находиться виртуальные машины.

1. Создайте облачную сеть:

   Консоль управления

   CLI

   Чтобы создать облачную сеть:

   1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать облачную сеть.
   2. Нажмите кнопку Создать сеть.
   3. Задайте имя сети: ad-network.
   4. Нажмите кнопку Создать сеть.

   Чтобы создать облачную сеть, выполните команду:

   $ yc vpc network create --name ad-network
   

2. Создайте три подсети в сети ad-network:

   Консоль управления

   CLI

   Чтобы создать подсеть:

   1. Откройте раздел Virtual Private Cloud в каталоге, где требуется создать подсеть.
   2. Нажмите на имя облачной сети.
   3. Нажмите кнопку Добавить подсеть.
   4. Заполните форму: введите имя подсети ad-subnet-a, выберите зону доступности ru-central1-a из выпадающего списка.
   5. Введите CIDR подсети: IP-адрес и маску подсети: 10.1.0.0/16. Подробнее про диапазоны IP-адресов в подсетях читайте в разделе Облачные сети и подсети.
   6. Нажмите кнопку Создать подсеть.

   Повторите шаги еще для двух подсетей ad-subnet-b и ad-subnet-c в зонах доступности ru-central1-b и ru-central1-c с CIDR 10.2.0.0/16 и 10.3.0.0/16 соответственно.

   Чтобы создать подсети, выполните команды:

   yc vpc subnet create \
     --name ad-subnet-a \
     --zone ru-central1-a \
     --network-name ad-network \
     --range 10.1.0.0/16
   
   yc vpc subnet create \
     --name ad-subnet-b \
     --zone ru-central1-b \
     --network-name ad-network \
     --range 10.2.0.0/16
   
   yc vpc subnet create \
     --name ad-subnet-c \
     --zone ru-central1-c \
     --network-name ad-network \
     --range 10.3.0.0/16
   

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

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

#ps1
Get-LocalUser | Where-Object SID -like *-500 | Set-LocalUser -Password (ConvertTo-SecureString "<ваш пароль>" -AsPlainText -Force)

Пароль должен соответствовать требованиям к сложности.

Подробные рекомендации по защите Active Directory читайте на сайте разработчика.

Создайте ВМ для Active Directory

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

Консоль управления

CLI

1. На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

2. В поле Имя введите имя виртуальной машины: ad-vm-a.

3. Выберите зону доступности ru-central1-a.

4. В блоке Образы из Cloud Marketplace нажмите кнопку Выбрать. В открывшемся окне выберите образ 2016 Datacenter.

5. В блоке Диски укажите размер загрузочного диска 35 ГБ.

6. В блоке Вычислительные ресурсы:

   • Выберите платформу: Intel Cascade Lake.
   • Укажите необходимое количество vCPU и объем RAM:
     • vCPU — 4.
     • Гарантированная доля vCPU — 100%.
     • RAM — 8 ГБ.

7. В блоке Сетевые настройки нажмите кнопку Добавить сеть и выберите сеть exchange-network. Выберите подсеть exchange-subnet-a. В блоке Публичный адрес выберите вариант Без адреса.

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

   • В поле Пароль укажите ваш пароль.

9. Нажмите кнопку Создать ВМ.

Повторите операцию для ВМ с именем ad-vm-b в зоне доступности ru-central1-a и подключите ее к подсети exchange-subnet-b

$ yc compute instance create \
    --name ad-vm-a \
    --hostname ad-vm-a \
    --memory 8 \
    --cores 4 \
    --zone ru-central1-a \
    --network-interface subnet-name=exchange-subnet-a,ipv4-address=10.1.0.3 \
    --create-boot-disk image-folder-id=standard-images,image-family=windows-2016-gvlk \
    --metadata-from-file user-data=setpass

$ yc compute instance create \
    --name ad-vm-b \
    --hostname ad-vm-b \
    --memory 8 \
    --cores 4 \
    --zone ru-central1-b \
    --network-interface subnet-name=exchange-subnet-b,ipv4-address=10.2.0.3 \
    --create-boot-disk image-folder-id=standard-images,image-family=windows-2016-gvlk \
    --metadata-from-file user-data=setpass

Обзор служб федерации Active Directory (ADFS)

Уже очень давно хотел начать серию материалов о службах федерации Active Directory (ADFS). За время работы с данным компонентом Windows Server у меня накопился внушительный список практических кейсов. К ним можно отнести аутентификацию в веб-приложениях, гибридную аутентификацию c Azure Active Directory, публикацию веб-приложений и многое другое.В далеком 2014-м году мной частично была затронута тематика ADFS в разрезе публикации Exchange. Увы, тогда обзор возможностей служб федерации ограничился контекстом продукта Exchange и должным образом раскрыт не был.
Этой статьей я планирую исправить данное упущение, объяснив назначение и принцип работы этого сервиса. Сам же функционал и ключевые возможности планирую рассмотреть в будущих статьях. Поехали.

Обзор служб федерации Active Directory

ADFS (Active Directory Federation Services) — это компонент Windows Server обеспечивающий функционал провайдера аутентификации для веб-приложений. Для лучшего понимания вышесказанного весь последующий обзор будет строится вокруг практического кейса. И так, рассмотрим следующею задачу: необходимо «прикрутить» возможность входа для корпоративных пользователей Active Directory к веб приложению, которое работает в сети Интернет. Схематически эту задачу можно изобразить следующим образом:

Веб-приложение и Active Directory Domain Services

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

Интернет веб-приложение с сетевой инфраструктурой

А вот и обещанные подводные камни — проблемы с безопасностью и сложная техническая реализация.

Первое — протоколы аутентификации используемые в Active Directory не рассчитаны для работы в сети Интернет. Kerberos полноценно работать не будет, так как для полной его поддержки требуется членство веб-сервера в домене AD. Остается аутентификация по NTLM и LDAP, но даже с ними реализация не внушает оптимизма.

Второе — чтобы реализовать подобный сценарий, с сетевой точки зрения, необходимо проделывать «дырки» используя DNAT. Это связано с фактом использования приватных диапазонов IP адресов в корпоративной сети.

Выходом может быть использование Site-to-Site VPN. Далее, стандартные протоколы аутентификации. Хоть и отпадают сложности на сетевом уровне, но все же это «костыльный» вариант. Он потребует специфические условия для реализации, что в свою весьма усложнит конечный дизайн решения.

Чтобы все же решить данную задачу, начиная с Windows Server 2003 R2, были представлены службы федерации Active Directory. Реализация отдельного веб-провайдера аутентификации увенчалась успехом, и вот почему:

Во-первых, для взаимодействия клиентов и серверных компонентов приложений используется протокол HTTPS. Это предоставляет приемлемый уровень безопасности транспорта, так как используются протоколы SSL/TLS. Сценарии высокой доступности реализуется стандартными средствами NLB.

Во-вторых, в основе аутентификации лежит использование токенов доступа или утверждений «Claim». Они могут быть основаны на ряде стандартов, таких как OAuth, SAML и WS-Federation. Сам же маркер доступа представляет конструкцию содержащею конечный набор параметров и цифровую подпись провайдера аутентификации. Разметка токена будет осуществляться одним из распространенных форматов: Simple Web Token (SWT), JSON Web Token (JWT) или Security Assertion Markup Language (SAML).

Архитектура и принципы работы служб федерации Active Directory (ADFS)

Рассмотрим архитектуру на примере нашей задачи перерисовав схему:

Веб-приложение вместе с ADFS

Службы федерации будут состоят из двух компонентов — Active Directory Federation Services (ADFS) и Web Application Proxy (WAP)

Задача первого состоит в обеспечении взаимодействия со службами каталога Active Directory используя стандартные протоколы аутентификации (Kerberos, NTLM). ADFS выступают в качестве сервиса маркеров доступа. Его задача, на основании успешной аутентификации Active Directory, выдавать цифровые удостоверения (Claims). Эти выданные удостоверения будут являеться достаточным основанием для успешной аутентификации и авторизации в веб-приложении.

Компонент Web Application Proxy (WAP) принимает входящие запросы из сети Интернет и перенаправляет их на сервера ADFS для последующей обработки. Ответы от серверов ADFS пересылаются на него и он, в свою очередь, пересылает их клиенту. Параллельно этот компонент может выступать в роли реверс прокси сервера для публикации веб-приложений в Интернет. Например, веб-приложение Exchange Web Access (OWA) поддерживает аутентификацию ADFS, а сами службы WAP могут опубликовать OWA в Интернет для доступа внешними пользователями.

Сам же процесс аутентификации в веб-приложении будет происходить следующим образом:

Как работают службы федерации Active Directory (ADFS)

Для конечного пользователя, весь процесс прохождения аутентификации останется прозрачным. Единственный нюанс будет в отработке сценария Single Sign On или нет. Дело в том, что аутентификация предполагает использование доменных учетных данных пользователя. Если на 3-м этапе запрос происходит с доменного компьютера, при настроенном SSO, у пользователя не будут запрошены стандартные аутентификационые данные (логин и пароль). Вместо этого, будут взяты сессионные данные, и, с их помощью, произойдёт последующая аутентификация в службах каталога.

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

Установка служб федерации Active Directory (ADFS)

Active Directory: Использование LDAP-фильтров (ru-RU) — TechNet Articles — United States (English)

Установка служб федерации Active Directory (ADFS)

В обзоре служб федерации Active Directory (ADFS) было дано развернутое объяснение назначения  и принципов работы данного сервиса. Сейчас же, пришло время познакомится с практической стороной вопроса, а именно с установкой служб ADFS. Ранее, мной уже рассматривался этот процесс, но тогда фокус статьи был смещен в сторону Exchange Server и, по прошествии времени,  у меня появились замечания к качеству проработки материала.

Архитектура развертывания служб федерации Active Directory (ADFS)

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

• Высокая доступность
• Планирование пространства имен DNS
• Использование сертификатов безопасности
• Размещение хранилище конфигурации

Высокая доступность

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

Архитектура высокой доступности служб федерации Active Directory (ADFS)

Он обусловлен дублированием компонентов, как серверов федерации, так и пограничных северов (Web Application Proxy). Внешние и внутренние запросы от клиентов будут терминироваться на балансировщиках сетевой нагрузки NLB. Это важный момент, так как игнорирование подобного дизайна может привести к серьезным последствиям. Например, если аутентификация в Office 365 или G Suite связана с ADFS и архитектура не предполагает высокую доступность, во время отказа все новые аутентификации будут провальными. Те, кто успел аутентифицироваться до отказа продолжат работу пока не истечет время жизни токена.

Планирование пространства имен DNS

Еще одним важным вопросом будет планирование DNS имен. Лучшим решение будет использование DNS Split зоны. Будет происходить дублирование внешней доменной зоны на DNS серверах контроллеров домена. Это позволит разрешать один и тот же FQDN фермы серверов федерации в разные IP (публичный и приватный). Публичный для внешних клиентов, приватный для внутренних. Схематически, это будет выглядеть следующим образом:

Архитектура пространства имен в службах федерации Active Directory (ADFS)

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

Использование сертификатов безопасности

Для функционирования сервиса необходимы сертификаты безопасности. Они будут служить для поддержки SSL/TLS сессий между клиентами и сервисом, а также для внутренней коммуникации компонентов ADFS. Рекомендуется использовать сертификаты, подписанные внутренними и внешними центрами сертификатов. Сертификаты с внутреннего ЦС будут использоваться для работы серверов ADFS в периметре организации. Доверие клиентов к ним будет обеспечено PKI инфраструктурой. Внешние сертификаты, выданные внешними ЦС, должны обеспечивать работу клиентов внешних клиентов. Например, не доменные рабочие станции или мобильные телефоны.

Размещение хранилище конфигурации

Вся конфигурация фермы ADFS хранится в MSSQL базе данных. Во время развертывания сервиса, мастер предлагает один из способов ее хранения — внутренняя база Windows Internal Database (WID) или на выделенная MSSQL инфраструктура. Для подавляющего большинства установок ADFS, первый вариант является предпочтительным. Это обусловлено легкостью развертывания, отсутствием дополнительных задач по обеспечению работы SQL и маленьким количеством запросов. Именно последние является ключевым фактом при выборе размещения хранилища конфигурации. При работе с WID, будет определена master и slave ноды. Изменения в конфигурацию могут быть внесены только на master ноде. В последствии, они будут реплицированы средствами внутренней репликации ADFS на все slave ноды. В случае использования выделенной SQL инфраструктуры, изменения возможно вносить на любой из нод фермы, остальные члены их увидят и применят.

Установка служб федерации Active Directory (ADFS)

Согластно дизайну, для минимальной установки сервиса потребуется минимум 4-е сервера:

В качестве серверной ОС, я буду использовать Windows Server 2019 на борту которого службы федерации версии 5.0. Сразу же стоит сделать ремарку — более удобное администрирование сервиса предоставит редакция с GUI. Это обусловлено тем, что в пакете RSAT отсутствует GUI консоль управления сервисом. Службы ADFS можно поставить в Core редакции, но тогда все последующее управление необходимо выполнять сугубо через PowerShell.

Установка первого сервера и создание фермы ADFS

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

Add-WindowsFeature ADFS-Federation

После установки, из Server Manager запускаем мастер установки служб федерации Active Directory (ADFS)

Запуск мастера установки служб федерации Active Directory

На следующем шаге необходимо задать учетные данные администратора домена Active Directory:

Указание учетных данных администратора домена Active Directory

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

• Сертификат должен обладать EKU «Server Authentication» и возможностью экспорта закрытого ключа. Это важно, так как на всех серверах фермы должен использоваться единый сертификат. Другими словами, после установки первого сервера фермы, сертификат подлежит экспорту и импорту на последующий сервер. Использовать разные сертификаты с не совпадающими thumbprint не представляется возможным.
• Для создания сертификата может служить шаблон веб сервера или другой на его основе. Главное, чтобы EKU был верным. Я предпочитаю использовать его более стойкую модифицированную версию с новой криптографией. Еще одним важным моментом будет правильные subject name и subject alternative name:

1. В subject name и subject alternative name должно присутствовать полное доменное имя фермы ADFS, например, sts.ait.in.ua;
2. В subject alternative name должны присутствовать записи enterpriseregistration и certauth в таком виде: enterpriseregistration.<внешнее доменное имя> и certauth.<имя ADFS>.<внешнее доменное имя>  Например, enterpriseregistration.ait.in.ua и certauth.sts.ait.in.ua:

Правильные subject name и subject alternative name в SSL сертификате ADFSВозможность экспорта сертификата служб федерации Active Directory

enterpriseregistration используется для возможности клиентов регистрации посредству Workplace Join. Это даст необходимые механизмы для реализации задач условного доступа (Condition Access) в веб приложениях, аутентификация оных настроена через ADFS.

certauth предоставит возможность использовать аутентификацию посредству смарт-карт, в том числе виртуальных. Более подробно о виртуальных смарт-картах можно прочитать в заметке — Виртуальная смарт-карта. Используем?

Установка ADFS может быть продолжена и на следующем шаге производим выбор сертификата SSL

Выбор сертификата SSL в мастере установки служб федерации Active Directory

На следующем шаге, необходимо выбрать учетную запись из-под которой будет работать сервис служб федерации. В качестве типа аккаунта, я рекомендую использовать Group Managed Service Accounts, далее gMSA. Подробно об этом типе можно прочитать тут. Ключевая особенность аккаунтов данного типа состоит в автоматическом обновлении пароля сервисного аккаунта на всех серверах фермы.

В случае, если в лесу Active Directory еще не разу не использовались gMSA, необходимо создать KDS Root Key для генерирования паролей gMSA. Если этого не сделать, в процессе создания будет получена следующая ошибка:

Group Managed Service Accounts are not available because the KDS Root Key has not been set

Сам же KDS Root Key создается с помощью следующего PowerShell командлета:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Права должны быть администратора предприятия. Успешным результатом его создания будет вывод его GUID:

PS C:\Users\administrator.CORP> Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Guid
—-
0edbe8ee-f883-a6ec-2121-e98889a4a0d2

PS C:\Users\administrator.CORP>

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

Задание сервисного аккаунта в мастере установки служб федерации Active Directory

Указываем место размещение хранилище конфигурации новой фермы:

Указание расположения SQL базы данных в мастере установки служб федерации Active Directory

На завершающем этапе, мастер проверит введенную ранее конфигурацию перед установкой:

Установка служб федерации Active Directory

После чего, установка первого сервера фермы федерации ADFS завершена:

Завершение работы мастера установки служб федерации Active Directory

Добавление второго сервера в ферму ADFS

Добавление второго и более сервера в ферму ADFS осуществляется проще. Для успешного добавления потребуется предварительный импорт SSL сертификата, который использовался при создании новой фермы, и сетевая связность по tcp/443 с первым сервером ADFS.

Выполняем установку бинарых файлов и доходим до мастера установки ADFS. На первом шаге выбираем добавление сервера в существующею ферму ADFS:

Добавление второго сервера в ферму ADFS

Указываем FQDN первого сервера в фермы ADFS:

Указание FQDN первого сервера в ферме ADFS

Сертификат и сервисный аккаунт указываем такие же, как и при создании первого сервера фермы:

Задание сервисного аккаунта на втором сервере фермы ADFS

После проверки конфигурации мастером выполняем установку:

Успешное добавление второго сервера в ферму ADFS

После завершения процесса установки и конфигурирования обеих нод фермы, необходимо настроить балансировщик сетевой нагрузки. DNS записи фермы федерации, enterpriseregistration и certauth должны указывать на VIP адрес NLB балансировщика.

Установка и настройка Web Application Proxy

Установка первой и второй нод Web Application Proxy является однотипной операцией, для которой необходимо выполнить ряд условий:

• Добавление в доверенные ЦС внутреннего корневого центра сертификатов, которым подписан SSL сертификат фермы ADFS. PKI инфраструктура должна быть настроена соответствующим образом для возможности проверки CRL листов отзыва. Публикации в LDAP недостаточно, так как сервера WAP не будут являться членом домена Active Directory;
• Наличие SSL сертификата, подписанного внешним коммерческим ЦС. Рекомендую использовать SAN тип сертификатов, так как wildcard не будет покрывать домен certauth.sts.ait.in.ua. Напомню, он будет использоваться для аутентификации по средству смарт-карт. Минимальный набор доменов в сертификате то же что использовалось при создании сертификата для фермы ADFS + те домены, веб приложения которых планируется к публикации. Например, если речь идет об Exchnage, это может быть mail и autodiscover.

Задание имени и доменного суффикса на WAP сервере

Используя PowerShell, устанавливаем бинарники служб Web Application Proxy:

Add-WindowsFeature Web-Application-Proxy

После чего, открываем мастер конфигурирования Web Application Proxy из Server Manager:

Мастер настройки Web Application Proxy

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

На следующем шаге выбираем коммерческий SSL сертификат, который будет предоставляться внешним клиентам:

Выбор коммерческого сертификата на сервере Web Application Proxy

Работа мастера завершена успешно:

Успешное завершение работы мастера настройки Web Application Proxy

Аналогичным образом необходимо настроить второй сервер Web Application Proxy. Как и в случае с фермой ADFS, далее следует конфигурирование балансировщика сетевой нагрузки. DNAT c публичного IP адреса необходимо будет выполнить именно на VIP балансировщика, за которым находятся сервера WAP.

Касаемо портов, это tcp/80 и tcp/443. Интересной особенностью будет необходимость ручного создания правила для 80-го порта в локальной брандмауэре. В время работы мастера, нужно исключение не создается.

Выводы

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

В статье » Установка служб федерации Active Directory (ADFS)» детально был рассмотрен процесс установки и конфигурации ADFS в отказоустойчивом режиме.  Работа над материалом заняла две недели и как результат он получился довольно объемным и детализированным. Надеюсь, он поможет в развертывании и последующему освоению данного сервиса.

Linux машина в домене Windows AD с помощью sssd и krb5 / Хабр

Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.

Для примера будем использовать:

Домен = contoso.com
Контроллер домена = dc.contoso.com

Запускаем терминал Ubuntu:

1. Переключаемся под рута

sudo -i

2. Устанавливаем необходимые пакеты

apt install sssd heimdal-clients msktutil

3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция

[libdefaults]
	default_realm = CONTOSO.COM

[realms]
	CONTOSO.COM = {
		kdc = DC 
		admin_server = dc.contoso.com
		default_domain = contoso.com
	}

[login]
	krb4_convert = true
	krb4_get_tickets = false
	
[domain_realm]
        .contoso.com = CONTOSO.COM
        contoso.com = CONTOSO.COM

4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

127.0.0.1       localhost
127.0.1.1       <hostname>.contoso.com  <hostname>

5. Пробуем получить Kerberos ticket от имени администратора домена:

root@ubuntu:~# kinit YourDomainAdmin
[email protected]'s Password:

Проверяем:

root@ubuntu:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: [email protected]

  Issued                Expires               Principal
Dec  1 15:08:27 2018  Dec  2 01:08:22 2018  krbtgt/[email protected]

Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:

msktutil -c -b 'CN=YourComputersOU' -s HOST/HOSTNAME.contoso.com -k /etc/sssd/HOSTNAME.keytab --computer-name HOSTNAME --upn HOSTNAME$ --server dc.contoso.com —user-creds-only

msktutil -c -b 'CN=YourComputersOU' -s HOST/HOSTNAME -k /etc/sssd/HOSTNAME.keytab --computer-name HOSTNAME --upn HOSTNAME$ --server dc.contoso.com --user-creds-only

Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:

kdestroy

6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:

[sssd]

services = nss, pam
config_file_version = 2
domains = contoso.com


[nss]

entry_negative_timeout = 0
debug_level = 3


[pam]

debug_level = 3


[domain/contoso.com]

debug_level = 3

ad_domain = contoso.com
ad_server = dc.contoso.com
enumerate = false

id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = simple
simple_allow_groups = users #каким группам разрешено логиниться, через запятую. Есть ограничение — названия групп должны быть с маленькой буквы.
ldap_schema = ad
ldap_id_mapping = true
fallback_homedir = /home/%u
default_shell = /bin/bash
ldap_sasl_mech = gssapi
ldap_sasl_authid = <HOSTNAME>$
ldap_krb5_init_creds = true
krb5_keytab = /etc/sssd/<HOSTNAME>.keytab

Описание параметров конфигфайла sssd можно посмотреть тут

Устанавливаем права доступа для файла sssd.conf:

chmod 600 /etc/sssd/sssd.conf

Перезапускаем SSSD service

service sssd restart

7. Редактируем настройки PAM

Плохое решение:

редактируем файл /etc/pam.d/common-session, после строки

session required        pam_unix.so

добавляем строку

session required pam_mkhomedir.so skel=/etc/skel umask=0022

Хорошее решение:

переопределить параметры через системные настройки PAM, вызываем

pam-auth-update

и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.

Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.

P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его

visudo -f /etc/sudoers.d/ваш_файл

добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):

%Domain\ Admins ALL=(ALL) ALL

P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:

1. Устанавливаем нужные пакеты:

sudo apt install realmd samba-common-bin samba-libs sssd-tools krb5-user adcli

2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

127.0.0.1       localhost
127.0.1.1       <hostname>.contoso.com  <hostname>

3. Проверяем, что наш домен виден в сети:

realm discover contoso.com

4. Вводим машину в домен:

sudo realm --verbose join contoso.com -U YourDomainAdmin --install=/

5. Редактируем настройки PAM

sudo pam-auth-update

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

Для того чтоб при входе не указывать дополнительно к логину домен, можно добавить суффикс по умолчанию. В файле /etc/sssd/sssd.conf, в блоке [sssd] добавляем строку:

default_domain_suffix = contoso.com

интерфейсов службы Active Directory — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

Назначение

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

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

Примечание

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

Где применимо

Сетевые администраторы

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

Независимые поставщики программного обеспечения и разработчики конечных пользователей могут использовать ADSI для «включения каталогов» своих продуктов и приложений. Службы могут публиковать себя в каталоге, клиенты могут использовать каталог для поиска служб, и оба могут использовать каталог для поиска других интересующих объектов и управления ими.Поскольку интерфейсы службы Active Directory не зависят от базовой службы каталогов, продукты и приложения с поддержкой каталогов могут успешно работать в нескольких сетевых средах и средах каталогов.

Аудитория разработчиков

Вы можете писать клиентские приложения ADSI на многих языках. Для большинства административных задач ADSI определяет интерфейсы и объекты, доступные из языков, совместимых с Automation, таких как Microsoft Visual Basic, Microsoft Visual Basic Scripting Edition (VBScript) и Java, до языков с большей производительностью и эффективностью, таких как C и C ++.Программисту ADSI пригодится хорошая основа программирования на COM.

Требования к времени выполнения

Active Directory работает на контроллерах домена Windows Server. Однако клиентские приложения, использующие ADSI, можно писать и запускать в Windows. Кроме того, разработчикам понадобится Platform Software Development Kit (SDK), также доступный на веб-сайте MSDN. Чтобы исследовать содержимое Active Directory, используйте оснастку MMC «Пользователи и компьютеры Active Directory». Эта оснастка заменяет инструмент Adsvw, который был доступен в предыдущих версиях Windows.

В разделе

Об ADSI

Общие сведения об ADSI.

Использование ADSI

Руководство программиста по использованию ADSI.

Учебные пособия по ADSI

Использование ADSI с автоматизацией для управления каталогами.

Ссылка ADSI

Документация по интерфейсам и методам ADSI.

Модель компонентных объектов

COM-клиенты и серверы

Доменные службы Active Directory

.

Использование интерфейсов служб Active Directory — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

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

Интерфейсы службы

Active Directory соответствуют модели компонентных объектов (COM) и поддерживают стандартные функции COM.

ADSI предоставляет интерфейсы, совместимые с автоматизацией, для контроллеров с привязкой к имени, таких как Java, система разработки Microsoft Visual Basic и Visual Basic Scripting Edition (VBScript). ADSI также может предоставить интерфейс, который может оптимизировать производительность интерфейсов, несовместимых с автоматизацией, для использования с языковыми средами, такими как C и C ++.

ADSI также предоставляет неавтоматизированные интерфейсы, IDirectoryObject и IDirectorySearch , для поддержки управления объектами каталога и запросов.

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

Веб-приложения

, использующие Active Server Pages, также могут программировать доступ к службам каталогов через ADSI.

Клиенты

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

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

.

интерфейсов службы Active Directory — приложения Win32

• 11.01.2019
• 18 минут на чтение

В этой статье

Обзор технологии интерфейсов служб Active Directory.

Для разработки интерфейсов служб Active Directory необходимы следующие заголовки:

Руководство по программированию этой технологии см .:

Перечисления

Функции

.

Об интерфейсах служб Active Directory — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

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

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

ADSI позволяет разработчикам легко «каталогизировать» свои приложения. Администраторы и разработчики обрабатывают единый набор интерфейсов службы каталогов, независимо от того, какие службы каталогов установлены.

Во введении обсуждаются следующие темы:

Что следует знать перед прочтением этого руководства

В этом руководстве предполагается, что вы знакомы с компонентной объектной моделью (COM) и автоматизацией и знаете, как программировать на Visual Basic или C / C ++.

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

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

Brockschmidt, Kraig. Внутри OLE , 2-е издание. Редмонд, Вашингтон: Microsoft Press, 1995.

.

Чаппелл, Дэвид. Общие сведения об ActiveX и OLE . Редмонд, Вашингтон: Microsoft Press, 1996.

.

Хан, Стивен. Справочник программиста ADSI ASP . Wrox Press Ltd., 1998.

Харрисон, Ричард. Веб-безопасность ASP / MTS / ADSI . Прентис Холл, 1999.

Справочник программиста Microsoft OLE DB, версия 1.0, 1996 г.

Справочник программиста OLE 2, том второй . Редмонд, Вашингтон: Microsoft Press, 1994.

Роджерсон, Дейл. Внутри COM . Редмонд, Вашингтон: Microsoft Press, 1997.

.

Спецификация проектирования службы Active Directory версии 2.0 .

Спецификация модели компонентных объектов .

(Эти ресурсы могут быть недоступны для некоторых языков и стран / регионов.)

.