Установка служб федерации active directory (adfs)

Using the Code

To add a new user to Active Directory, we use three classes:

string stringDomainName = 
    System.Net.NetworkInformation.IPGlobalProperties.GetIPGlobalProperties().DomainName;

1. : We want to add another user to our domain, therefore, at first, we should find out our domain name. We find its name by using this code:
2. : is a container of domain against which all operations are performed. To add another user, uses credential specified by username and password. This credential is used to connect to active directory therefore the user with this credential must have permission to add users.
3. : Making another user and adding it to active directory is very simple. We just need to initialize an instance of by using the specified context from the pervious part and also username and password of new user. Then, we just assign input textboxes data to related properties of .

private void button1_Click(object sender, RoutedEventArgs e)
{
    try
    {
        string stringDomainName = 
        System.Net.NetworkInformation.IPGlobalProperties.GetIPGlobalProperties().DomainName;
        PrincipalContext PrincipalContext4 = 
          new PrincipalContext(ContextType.Domain, stringDomainName, 
          textboxOu.Text, ContextOptions.SimpleBind, textboxAdminUsername.Text, 
          passwordboxAdminPassword.Password);
        UserPrincipal UserPrincipal1 = new UserPrincipal(PrincipalContext4, 
          textboxLonOnName.Text, passwordboxUserPass.Password, true);
 
        
        UserPrincipal1.UserPrincipalName = textboxSamAccountName.Text;
        UserPrincipal1.Name = textboxName.Text;
        UserPrincipal1.GivenName = textboxGivenName.Text;
        UserPrincipal1.Surname = textboxSurname.Text;
        UserPrincipal1.DisplayName = textboxDisplayName.Text;
        UserPrincipal1.Description = textboxDescription.Text;
        if (radiobuttonEnable.IsChecked == true)
        {
            UserPrincipal1.Enabled = true;
        }
        else
        {
            UserPrincipal1.Enabled = false;
        }
        UserPrincipal1.Save();
        MessageBox.Show("Saved Successfully");
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.ToString());
    }
}

Настройка фермы AD FSConfigure the AD FS Farm

Завершив работу с предыдущим разделом на каждом AD FS сервере, настройте сведения о клиенте Azure с помощью командлета Set-адфсазуремфатенант .Once you have completed the previous section on each AD FS server, set the Azure tenant information using the Set-AdfsAzureMfaTenant cmdlet. Этот командлет необходимо выполнить только один раз для фермы AD FS.This cmdlet needs to be executed only once for an AD FS farm.

Откройте командную строку PowerShell и введите свой идентификатор tenantId с помощью командлета Set-адфсазуремфатенант .Open a PowerShell prompt and enter your own tenantId with the Set-AdfsAzureMfaTenant cmdlet. Для клиентов, использующих Microsoft Azure для государственных организаций Cloud, добавьте параметр:For customers that use Microsoft Azure Government cloud, add the parameter:

Примечание

Прежде чем эти изменения вступят в силу, необходимо перезапустить службу AD FS на каждом сервере в ферме.You need to restart the AD FS service on each server in the farm before these changes take affect. Для минимального воздействия переведите каждый AD FSный сервер из вращения балансировки сетевой нагрузки по одному за раз и дождитесь завершения всех соединений.For minimal impact, take each AD FS server out of the NLB rotation one at a time and wait for all connections to drain.

Windows Server без последнего пакета обновления не поддерживает параметр командлета Set-адфсазуремфатенант .Windows Server without the latest service pack doesn’t support the parameter for the Set-AdfsAzureMfaTenant cmdlet. Если вы используете облако Azure для государственных организаций, и на предыдущих шагах не удалось настроить клиент Azure из-за отсутствующего параметра, выполните следующие действия, чтобы вручную создать записи реестра.If you use Azure Government cloud and the previous steps failed to configure your Azure tenant due to the missing parameter, complete the following steps to manually create the registry entries. Пропустите эти шаги, если предыдущий командлет правильно зарегистрировал сведения о клиенте или вы не в облаке Azure для государственных организаций:Skip these steps if the previous cmdlet correctly registered your tenant information or you aren’t in the Azure Government cloud:

1. Откройте редактор реестра на AD FS сервере.Open Registry Editor on the AD FS server.

2. Перейдите к .Navigate to . Создайте следующие значения разделов реестра:Create the following registry key values:

   Раздел реестраRegistry key	ЗначениеValue
   SasUrlSasUrl	https://adnotifications.windowsazure.us/StrongAuthenticationService.svc/Connector
   стсурлStsUrl	https://login.microsoftonline.us
   ResourceUriResourceUri	https://adnotifications.windowsazure.us/StrongAuthenticationService.svc/Connector

3. Прежде чем эти изменения вступят в силу, перезапустите службу AD FS на каждом сервере в ферме.Restart the AD FS service on each server in the farm before these changes take affect. Для минимального воздействия переведите каждый AD FSный сервер из вращения балансировки сетевой нагрузки по одному за раз и дождитесь завершения всех соединений.For minimal impact, take each AD FS server out of the NLB rotation one at a time and wait for all connections to drain.

После этого вы увидите, что Azure MFA доступен в качестве основного метода проверки подлинности для использования в интрасети и экстрасети.After this, you will see that Azure MFA is available as a primary authentication method for intranet and extranet use.

Публикация приложения через Web Application Proxy

После того, как установлены роли ADFS и Web Application Proxy (которая работает еще и как ADFS Proxy), можно перейти непосредственно к публикации наружу конкретного приложения. Сделать это можно с помощью консоли Remote Access Management Console.

Запустите мастер публикации и укажите, хотите ли вы использовать для преаутентификации службу ADFS (это именно наш вариант).

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

Совет. Если необходимо перенаправить внешнее приложение на альтернативный порт, необходимо задать его в URL, указаывающем на внутренний сервер. Например, если необходимо перенаправить внешние https запросы (443 порт) на 4443 порт, нужно указать:

Backend server URL: lync.winitpro.local:4443

Завершите работу мастера, и на этом публикация приложений окончена. Теперь, если попытаться с помощью браузера зайти на опубликованный внешний URL-адрес, то браузер сначала будет перенаправлен на службу аутентификации (ADFS Proxy), а после успешной аутентификации пользователь будет отправлен  непосредственно на внутренний сайт (веб приложение).

Благодаря новой службе Web Application Proxy в Windows Server 2012 R2 возможно реализовать функционал обратного прокси сервера с целью публикации внутренних служб предприятия наружу без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront и пр.

Регистрация пользователей для Azure MFA с помощью AD FSRegistering users for Azure MFA with AD FS

AD FS не поддерживает встроенную проверку «» или регистрацию сведений о проверке безопасности Azure MFA, таких как номер телефона или мобильное приложение.AD FS does not support inline «proof up», or registration of Azure MFA security verification information such as phone number or mobile app. Это означает, что https://account.activedirectory.windowsazure.com/Proofup.aspx прежде чем использовать Azure MFA для проверки подлинности в AD FSных приложениях, пользователи должны пройти проверку.This means users must get proofed up by visiting https://account.activedirectory.windowsazure.com/Proofup.aspx prior to using Azure MFA to authenticate to AD FS applications.
Если пользователь, который еще не выполнил проверку подлинности в Azure AD, пытается пройти аутентификацию в Azure MFA на AD FS, он получит AD FS ошибку.When a user who has not yet proofed up in Azure AD tries to authenticate with Azure MFA at AD FS, they will get an AD FS error. Как администратор AD FS вы можете настроить этот интерфейс с ошибками, чтобы указать пользователю страницу подтверждения вверху.As an AD FS administrator, you can customize this error experience to guide the user to the proofup page instead. Это можно сделать с помощью onload.js настройки, чтобы определить строку сообщения об ошибке на странице AD FS и отобразить новое сообщение, чтобы пользователи могли посетить https://aka.ms/mfasetup , а затем повторить попытку проверки подлинности.You can do this using onload.js customization to detect the error message string within the AD FS page and show a new message to guide the users to visit https://aka.ms/mfasetup, then re-attempt authentication. Подробные инструкции см. в разделе «Настройка веб-страницы AD FS, чтобы помочь пользователям зарегистрировать методы проверки подлинности MFA» ниже в этой статье.For detailed guidance see the «Customize the AD FS web page to guide users to register MFA verification methods» below in this article.

Примечание

Ранее пользователям требовалось пройти проверку подлинности с помощью MFA для регистрации ( https://account.activedirectory.windowsazure.com/Proofup.aspx например, с помощью ярлыка https://aka.ms/mfasetup ).Previously, users were required to authenticate with MFA for registration (visiting https://account.activedirectory.windowsazure.com/Proofup.aspx, for example via the shortcut https://aka.ms/mfasetup). Теперь AD FS пользователь, который еще не зарегистрировал сведения об аутентификации MFA, может получить доступ к странице Azure AD»подтверждения вверху с помощью ярлыка, https://aka.ms/mfasetup используя только первичную проверку подлинности (например, встроенную проверку подлинности Windows или имя пользователя и пароль через веб-страницы AD FS).Now, an AD FS user who has not yet registered MFA verification information can access Azure AD»s proofup page via the shortcut https://aka.ms/mfasetup using only primary authentication (such as Windows Integrated Authentication or username and password via the AD FS web pages). Если у пользователя нет настроенных методов проверки, Azure AD будет выполнять встроенную регистрацию, в которой пользователь видит сообщение, «администратору требуется настроить эту учетную запись для дополнительной проверки безопасности», и пользователь сможет «настроить его».If the user has no verification methods configured, Azure AD will perform inline registration in which the user sees the message «Your admin has required that you set up this account for additional security verification», and the user can then select to «Set it up now».
Пользователям, у которых уже настроен по крайней мере один метод проверки MFA, по-прежнему будет предложено предоставить MFA при посещении страницы подтверждения вверху.Users who already have at least one MFA verification method configured will still be prompted to provide MFA when visiting the proofup page.

Изменение настроек безопасности

Некоторые параметры настроек безопасности созданного Replying Party Trust необходимо изменить. Для перехода к этим настройкам выберите имя Replying Party Trust, которое вы ввели на этапе создания проверяющей стороны, затем выберите Actions в Properties.

• Вкладка Advanced — в поле «Secure hash algorithm» выберите SHA-256. Не следует выбирать SHA1, так как он больше не поддерживается современными браузерами и считается небезопасным;
• Endpoints — добавьте SAML как конечную точку и выберите SAML Logout; Choose Post for the Binding;
• Trusted URL —  создайте URL, используя веб-адрес вашего ADFS сервера и конечную точку ADFS SAML, добавленную ранее, а также строку ‘?wa=wsignout1.0’. URL должен выглядеть примерно так: https://sso.yourdomain.tld/adfs/ls/?wa=wsignout1.0. 

Сохраните изменения, в результате будет создана работающая проверяющая сторона для UseResponse.

Что такое описания утвержденийWhat are claim descriptions?

Описания утверждений представляют собой список типов утверждений, которые AD FS поддерживает и которые могут быть опубликованы в метаданных федерации.Claim descriptions represent a list of claims types that AD FS supports and that may be published in federation metadata. Типы утверждений, упомянутые в предыдущей таблице, настраиваются как описания утверждений в оснастке управления AD FS — в.The claim types mentioned in the previous table are configured as claims descriptions in the AD FS Management snap-in.

Коллекция описаний утверждений, которые будут опубликованы в метаданных федерации, хранится в базе данных конфигурации AD FS.The collection of claim descriptions that will be published to federation metadata is stored in the AD FS configuration database. Эти описания утверждений используются разными компонентами службы федерации.These claim descriptions are used by various components of the Federation Service.

Каждое описание утверждения включает универсальный код ресурсов (URI), имя, статус публикации и описание.Each claim description includes a claim type URI, name, publishing state, and description. Управлять коллекцией описаний утверждений можно с помощью узла описания утверждений в оснастке управления AD FS — в.You can manage the claim description collection by using the Claim Descriptions node in the AD FS Management snap-in. Состояние публикации описания утверждения можно изменить с помощью оснастки — в.You can modify the publishing state of a claim description using the snap-in. Доступны следующие параметры.The following settings are available:

• Опубликовать это утверждение в метаданных федерации как тип утверждения, который может принимать ( этот служба Федерации Опубликовать как принятое ) — указывает типы утверждений, которые будут приниматься от других поставщиков утверждений данным служба Федерации.Publish this claim in federation metadata as a claim type that this Federation Service can accept (Publish as Accepted)—Indicates the claim types that will be accepted from other claims providers by this Federation Service.

• Опубликовать это утверждение в метаданных федерации как тип утверждения, который служба федерации может отправить ( Опубликовать как отправленный ) — указывает типы утверждений, предлагаемые этой служба Федерации.Publish this claim in federation metadata as a claim type that this Federation Service can send (Publish as Sent)—Indicates the claim types that are offered by this Federation Service. Это типы утверждений, публикуемые службой федерации для других сторон как разрешенные к отправке.These are the claim types the Federation Service publishes to others as those it is willing to send. Типы утверждений, фактически отправляемые поставщиком утверждений, часто представляют собой подмножество этого списка.The actual claim types sent by the claims provider are often a subset of this list.

Дополнительные сведения о том, как задать состояние публикации для типа утверждения, см. в разделе Добавление описания утверждения в руководство по развертыванию AD FS.For more information about how to set the publishing state of a claim type, see Add a Claim Description in the AD FS Deployment Guide.

При создании метаданных федерацииWhen generating Federation Metadata

Метаданные федерации включают все описания утверждений, помеченные для публикации.Federation Metadata includes all the claim descriptions that are marked for publishing.

Пара слов о MAC-адресах

Прежде чем мы приступим, нам нужно понимать что на всех наших нодах будет настроен одинаковый IP и одинаковый mac-адрес, по запросу на который они будут поочередно давать ответы.

Проблема в том, что каждый коммутатор работает таким образом, что во время работы он составляет свою таблицу коммутации, в которой каждый mac-адрес связывается с определенным физическим портом. Таблица коммутации составляется автоматически, и служит для разгрузки сети от «ненужных» L2-пакетов.

Так вот, если mac-адрес есть в таблице коммутации, то пакеты будут отправляться только в один порт за которым и закреплен этот самый mac-адрес.

К сожалению, нам это не подходит и нам необходимо удостовериться в том, что бы все наши хосты в кластере одновременно «видели» все эти пакеты. В противном случае эта схема работать не будет.

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

Также вам вероятно придется отключить функцию Dynamic ARP Inspection, если она поддерживается вашим коммутатором, так как она может стать причиной блокировки arp-ответов от ваших хостов.

Usage

To disable all AD users that has been inactive for 180 days or more (without deleting them):

Same thing as before, plus creating a logFile.csv file containing a list of all disabled users:

To disable all AD users that has been inactive for 180 days or more and also delete those that have been previously disabled more than 180 days ago.

Same thing as before, plus creating a logFile.csv file containing a list of all disabled users and a deleteLogFile.csv file containing a list of all deleted users:

In case you get permissions issues when disabling/deleting AD users, you can bypass them using the Bypass Execution Policy Flag in the following way:

Создание локальных учетных записей через GP AD

Работа с групповыми политиками происходит через оснастку AD Group Policy Management (). Для того чтобы понять, как это работает на практике, давай создадим политику, после применения которой на компьютере будет создан локальный пользователь с правами администратора.

Оснастка gpmc.msc
Другие статьи в выпуске:

Хакер #182. Все о Bitcoin

• Содержание выпуска
• Подписка на «Хакер»

Конфигурация данной политики будет сохранена в файл  в директории текущего домена — \dc.test\SYSVOL\dc.test{XX-X-X-X-XX}\Machine\Preferences\Groups\, где XX-X-X-X-XX — GUID созданной политики. Графический интерфейс — это, конечно, здорово, но давай взглянем на то, как же выглядит наша новая политика.

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

Why do companies use ADFS?

ADFS was born out of the need to overcome the authentication challenges created by AD in an increasingly connected online world. AD and IWA have set limitations when it comes to modern authentication, and cannot authenticate users accessing AD integrated applications externally. This is a challenge in the modern workplace, where users often need to access applications that are not owned or managed by their AD organization.

ADFS is able to resolve and simplify these third-party authentication challenges, but does come with certain risks and disadvantages.

ADFS solves the problem of users who need to access AD integrated applications while working remotely, offering a flexible solution whereby they can authenticate using their standard organizational AD credentials via a web interface. It allows users from one organization to access the applications of another organization beyond the realm of their AD domain. Examples include applications in a partner organization or modern cloud services, which now form part of many organizations’ extended IT landscape.

Over 90% of organizations use Active Directory, which means many use ADFS as well.

Использование Attribute Editor в консоли Active Directory Users and Computer

Итак, чтобы воспользоваться редактором атрибутов AD вам нужно установить оснастку dsa.msc (или ADUC — Active Directory Users and Computer).

Попробуйте открыть свойства любого пользователя в AD. Как вы видите доступны несколько вкладок с атрибутами пользователя. Основные из них:

• Общие (General) – основные свойства пользователя, которые задаются при создании учетной записи в AD (имя, фамилия, телефон, email и т.д.);
• Адрес (Address);
• Учетная запись (Account) – имя учетной записи (samAccountName, userPrincipalName). Здесь можно указать список компьютеров, на которых разрешено работать пользователю (LogonWorkstations), опции: пароль не истекает, пользователь не может сменить пароль, включена ли учетная запись и ее срок действия и т.д.;
• Профиль (Profile) – можно настроить путь к профилю пользователя (в сценариях с перемещаемыми профилями); скрипт, выполняемый при входе, домашнюю папку, сетевой диск;
• Телефоны (Telephones);
• Организация (Organization) – должность, департамент, компания пользователя, имя менеджера.

В этом окне вам доступен только базовый набор свойств пользователя, хотя в классе User в AD гораздо больше атрибутов (200+).

Чтобы отобразить расширенный редактор атрибутов, вам нужно в меню ADUC включить опцию View -> Advanced Features (Вид -> Дополнительные компоненты).

Теперь еще раз откройте свойства пользователя и обратите внимание, что появилась отдельная вкладка Attribute Editor. Если перейти на нее, перед вами откроется тот самый редактор атрибутов пользователя AD

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

Из редактора атрибутом можно скопировать значение поля distinguishedName (в формате CN=Sergey A. Ivanov,OU=Users,OU=Msk,DC=winitpro,DC=ru — уникальное имя объекта в AD), CN (Common Name), узнать дату создания учётной записи (whenCreated) и т.д.

Внизу окна редактора атрибутов AD присутствует кнопка Filter. По умолчанию в окне атрибутов отображаются только непустые атрибуты (включена опция Show only attributes that have values / Отображать только атрибуты со значениями). Если вы отключите эту опцию, в коноли будуут показаны все атрибуты класса User

Также обратите внимание на опцию Show only writable attributes. Если включить ее, вам станут доступны только те атрибуты, на правку которых вам делегированы полномочия (если у вас нет полномочий на изменение атрибутов данного пользователя, список атрибутов будет пуст)

Для большинства атрибутов AD имеется встроенная функция декодирования значений. Например:

• можно найти информацию о последнем входе пользователя в домен — атрибут lastLogonTimestamp (как вы видите в консоли редактора атрибутов время отображается в нормальном виде, но если щелкнуть по нему, вы увидите, что на самом деле время хранится в виде timestamp);
• состояние учетной записи хранится в атрибуте userAccountControl. Вместо битовой маски вы видите более удобное представление. Например, 0x200 = (NORMAL_ACCOUNT) вместо цифры 512;
• однако фото пользователя в AD (атрибут thumbnailPhoto) не отображается, и хранится в бинарном виде;

Why does any of this matter?

Because after you stand-up ADFS, people will start knocking on your door telling you how they want to federate with some cloud-based application and one of your first questions to them should be:

Is the application claims aware and does it support either WS-FED, SAML, or OAuth?

This is a perfect segue into my next blog, which is what questions should you be asking when installing and configuring ADFS or configuring federated applications. Stay Tuned.

Dave “Ghost Protocol” Gregory

Next Part in the Series : http://blogs.technet.com/b/askpfeplat/archive/2014/11/24/adfs-deep-dive-planning-and-design-conside…

Mixing and Matching?

While in theory you can mix and match sign-in protocols, authentication protocols, and tokens types, in practice you wouldn’t want to do this. Of these three, the one you might see change depending on the circumstances is the authentication protocol. I.E. – Outside the firewall forms-based, inside the firewall Kerberos, or perhaps a specific application wants ADFS to enforce certificate-based authentication.

WS-Fed is actually token agnostic but ADFS was written so that WS-Fed will always reply with a SAML 1.1 token.

So here is the breakdown:

• WS-Fed Sign-In Protocol = SAML 1.1 Token
• SAML Sign-In Protocol = SAML 2.0 Token
• Authentication Type = Forms-Based, Kerberos, NTLM, Certificate, MFA, etc.