Squid и kerberos-авторизация через active directory

Авторизация на основе групп AD

Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.

Для начала, создаем 2 группы пользователей, например:

1. squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
2. squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.

Теперь на прокси-сервере открываем конфигурационный файл squid:

vi /etc/squid/squid.conf

Добавляем после настройки аутентификации:

external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type squid_superusers_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type squid_users_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d

* где 

• squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidusers в домене DOMAIN.LOCAL.
• squid_superusers_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidsuperusers в домене DOMAIN.LOCAL.
• squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.

В секции acl:

#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_superusers_acl_krb external squid_superusers_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers
acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers

*  где 

• squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb; 
• squid_superusers_acl_krb — произвольное название acl для всех, кто входит в squid_superusers_from_ad_krb; 
• squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm;
• squid_superusers_acl_ntlm — произвольное название acl для всех, кто входит в squid_superusers_from_ad_ntlm;

* предыдущую acl для общей аутентификации комментируем.

В секции allow:

#http_access allow auth
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm

* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.

Перечитываем конфигурацию прокси-сервера:

squid -k reconfigure

Поддержка технологии для отношений доверия

Отношения доверия используют различные службы и функции, такие как DNS, для поиска контроллеров домена в партнерских лесах. Отношения доверия также используют протоколы проверки подлинности NTLM и Kerberos и механизмы управления доступом и авторизации на основе Windows, чтобы обеспечить безопасную инфраструктуру связи между доменами и лесами в AD DS. Следующие службы и компоненты помогают поддерживать успешные отношения доверия.

DNS

AD DS требуется DNS для расположения и именования контроллера домена. Для успешной работы AD DS предоставляется следующая поддержка DNS:

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

Обычно развертывается пространство имен домена DNS, отражающее пространство имен домена AD DS. Если перед развертыванием AD DS существует пространство имен DNS, это пространство имен DNS обычно секционируется для AD DS, а также создается поддомен DNS и делегирование для корня леса AD DS. Затем добавляются дополнительные доменные имена DNS для каждого дочернего домена AD DS.

DNS также используется для поддержки расположения контроллеров домена AD DS. Зоны DNS заполняются записями ресурсов DNS, которые позволяют узлам и службам сети обнаруживать контроллеры домена AD DS.

Приложения и сетевой вход в систему

Приложения и служба сетевого входа в систему являются компонентами модели распределенного канала безопасности Windows. Приложения, интегрированные с Windows Server и AD DS, используют протоколы проверки подлинности для взаимодействия со службой сетевого входа в систему, чтобы можно было установить защищенный путь для проверки подлинности.

Протоколы проверки подлинности

Контроллеры домена AD DS проверяют подлинность пользователей и приложений с помощью одного из следующих протоколов:

• Протокол проверки подлинности Kerberos версии 5

  • Протокол проверки подлинности Kerberos версии 5 по умолчанию используется локальными компьютерами под управлением Windows и поддерживает сторонние операционные системы. Этот протокол указан в RFC 1510 и полностью интегрирован с AD DS, SMB, HTTP и RPC, а также клиентскими и серверными приложениями, использующими эти протоколы.
  • Если используется протокол Kerberos, серверу не нужно обращаться к контроллеру домена. Вместо этого клиент получает билет для сервера, запрашивая его у контроллера домена в домене учетной записи сервера. Затем сервер проверяет билет без консультации с другими центрами.
  • Если какой-либо из компьютеров, участвующий в транзакции, не поддерживает протокол Kerberos версии 5, используется протокол NTLM.

• Протокол проверки подлинности NTLM

  • Протокол NTLM — это классический сетевой протокол проверки подлинности, используемый в старых операционных системах. В целях совместимости он используется доменами AD DS для обработки сетевых запросов проверки подлинности, поступающих из приложений, предназначенных для более ранних клиентов и серверов под управлением Windows, а также сторонних операционных систем.
  • Если между клиентом и сервером используется протокол NTLM, сервер должен обратиться к службе проверки подлинности домена на контроллере домена, чтобы проверить учетные данные клиента. Сервер выполняет проверку подлинности клиента, пересылая учетные данные клиента контроллеру домена в домене учетной записи клиента.
  • Когда между двумя доменами или лесами AD DS существуют отношения доверия, можно направить запросы на проверку подлинности, созданные с помощью этих протоколов, для предоставления доступа к ресурсам в обоих лесах.

Prerequisites¶

Server Environment

The server environment must include a Microsoft Domain Controller as
well as a typical OVD server farm.

The Microsoft Domain Controller (DC) must have the following
characteristics:

• Active Directory is installed and functional
• DNS Server is installed and functional
• Configured as an NTP host server
• Microsoft functional level 2008R2, or 2012R2

The OVD server farm must be able to access the Domain Controller and
vice-versa. The OVD farm consists of the following:

• A server that has the OVD Session Manager, Web Access and Admin
  Console
• An OVD Application Server (ApS), either Windows or Linux or both
• An OVD File Server (OFS)

Note

• If OVD was configured to use the internal authentication method, any
  publications will need to recreated after changing the
  authentication method.
• It is important to perform backups of your running OVD farm and
  Microsoft Active Directory server prior to executing any integration
  steps outlined from this point onwards. It is preferable to test
  your integration by cloning the servers or to re-create a new
  isolated environment so that you can conduct comprehensive testing
  of the OVD SSO integration. An isolated environment is required so
  that your production environment will not recognize the cloned
  Domain Controller to avoid any negative Domain Controller policy
  propagation.
• The ApS and OFS cannot be installed on the same server as the
  Session Manager. There will be a configuration conflict otherwise
  which will prevent the system from working correctly.
• All passwords are case sensitive

Session Manager IP Configuration

The Session Manager IP address may be established either by using DHCP
or by using a static IP configuration. In the case that a DHCP
configuration is used and the DHCP service is not provided by the Active
Directory server, the following must be ensured:

• The DHCP server must always provide the same IP to the Session
  Manager (MAC address match)
• The DHCP server must provide the Session Manager with the IP address
  of the active Directory server as the primary DNS server

It is highly recommended to perform the above steps before proceeding
further in the documentation.If it is not possible to validate the above
steps then a possible workaround is to configure the Session Manager
with a static IP address.

Workstation and Domain Account

SSO integration requires that the user login with a user account managed
by Microsoft Active Directory and also that the workstation is joined to
the domain.

Client Compatibility

The SSO feature is compatible with OVD clients running on a Windows
workstation that is joined to the Active Directory domain. SSO is
compatible with the OVD Enterprise Desktop Client and OVD Web Access
clients using a Windows workstation. It is not compatible with the
Enterprise Mobile Client (Android, iOS) or the Enterprise Desktop Client
on Linux and Mac platforms or the Web Access clients running on Linux or
Mac.

Integrating Microsoft Active Directory with OVD

OVD must be configured to use the Active Directory authentication
method. Please refer to the Microsoft Active Directory Integration
Guide for detailed instructions. For information about the «Domain
Integration Settings» in the OVD Administration Console, please refer to
the OVD Administration Guide.
In the
section of the configuration page, ensure that the Full OVD integration
option is selected.
Neither the Hybrid integration nor the Full Active Directory integration
options are compatible with Single Sign-On.

After changing the authentication method, users must be assigned to the
relevant user groups and publications created so that they can create a
session. Session Data and user profiles that were created when Internal
Authentication was enabled will no longer be accessible after switching
to Active Directory.

After creating the publications, verify that users can create access OVD
correctly by having them login in and confirm that they see the same
applications as before the modifications for Active Directory.

Создание учетных данных альтернативной учетной записи службы в доменных службах Active Directory

Все серверы Exchange, на которые запущены службы клиентского доступа с одинаковыми пространствами имен и URL-адресами, должны использовать одни и те же учетные данные альтернативной учетной записи службы или (учетные данные ASA). Как правило, достаточно иметь одну учетную запись для леса для каждой версии Exchange.

Важно!

Exchange 2010 и Exchange 2016 не могут использовать одинаковые учетные данные ASA. Если учетные данные ASA были созданы для Exchange 2010, необходимо создать новую для Exchange 2016.

Хотя для общих пространств имен поддерживаются записи CNAME, Майкрософт рекомендует использовать записи A. Так клиент будет правильно отправлять запрос билета Kerberos (по общему имени, а не полному доменному имени сервера).

Примечание.

Групповые управляемые учетные записи служб (gMSA) не поддерживаются в локальных Exchange Server средах и поэтому не могут использоваться в этом сценарии.

При настройке учетных данных ASA помните о следующем.

• Тип учетной записи. Рекомендуется создать учетную запись компьютера вместо учетной записи пользователя. Ученая запись компьютера не поддерживает интерактивный вход и может использовать более простые политики безопасности, чем учетная запись пользователя. При создании учетной записи компьютера срок действия пароля не истекает, но мы все равно рекомендуем периодически обновлять пароль. Локальная групповая политика может определять максимальный срок хранения учетных записей компьютера и использовать скрипты для периодического удаления учетных записей компьютера, не соответствующих текущим политикам. Локальная политика безопасности также определяет, когда необходимо изменить пароль. Хотя мы рекомендуем использовать учетную запись компьютера, вы можете создать учетную запись пользователя.

• Имя учетной записи. Нет никаких требований к имени учетной записи. Можно использовать любое имя, соответствующее схеме именования.

• Группа учетных записей. Учетной записи, используемой для учетных данных ASA, не требуются специальные привилегии безопасности. Если вы используете учетную запись компьютера, она должна быть только членом группы безопасности «Компьютеры домена». Если вы используете учетную запись пользователя, она должна быть только членом группы безопасности «Пользователи домена».

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

Создание учетных данных ASA как учетной записи компьютера

1. На присоединенном к домену компьютере выполните команду Оболочка Windows PowerShell или Командная консоль Exchange.

   Импортируйте модуль Active Directory с помощью командлета Import-Module.

2. Выполните командлет New-ADComputer, чтобы создать учетную запись компьютера Active Directory, используя следующий синтаксис:

   Пример:

   Где EXCH2016ASA — это имя учетной записи, описание учетных данных альтернативной учетной записи службы для Exchange — это все, что вы хотите, а значение параметра SamAccountName , в данном случае EXCH2016ASA, должно быть уникальным в вашем каталоге.

3. С помощью командлета Set-ADComputer можно включить поддержку шифра AES 256, используемого в Kerberos, используя следующий синтаксис:

   Пример:

   Где EXCH2016ASA — это имя учетной записи, а атрибут для изменения — msDS-SupportedEncryptionTypes с десятичным значением 28, что позволяет использовать следующие шифры: RC4-HMAC, AES128-CTS-HMAC-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96.

Дополнительные сведения об этих командлетах см. в статьях Import-Module и New-ADComputer.

Kerberos Tickets:

As mentioned in the previous section, the client requests and granted a ticket. This method is common and used in other programs such as ssh.

How to check and delete Kerberos tickets:

To view or delete Kerberos tickets you can use the Kerberos List (Klist.exe). The Klist.exe is a command-line tool you can find in the Kerberos resource kit. You can only use it to check and delete tickets from the current logon session.
If you wish to use it your computer must be a member of a Kerberos realm. The Klist.exe uses the following syntax:

We recommend destroying your Kerberos tickets after your use. To do that, you can add the to your .logout file.

How to create a Kerberos ticket:

Some scenarios may require you to create. For example, when your ticket expires. To create a Kerberos ticket using the ‘kinit’ command:

Статистика пользователей

Остался последний этап — отображать красивую статистику посещений сайтов пользователями. Самый простой и красивый инструмент для этого — LightSquid.

Настраиваем Apache

Приводим файл /etc/apache2/conf-available/lightsquid.conf в такой вид (доступ на просмотр даем всем):

Alias   /lightsquid/    /usr/lib/cgi-bin/lightsquid/

<Location "/lightsquid/">
        Options +ExecCGI
        Require local
        Require ip 192.168.1.0/24
</Location>

Раскомментируем строку 219 в файле /etc/apache2/mods-enabled/mime.conf

AddHandler cgi-script .cgi .pl

Запускаем все это дело:

# a2enmod cgi
# a2enconf lightsquid
# service apache2 restart

Настраиваем LightSquid

Необходимо поставить пакет libnet-ldap-perl:

# apt-get install libnet-ldap-perl

Очень хочется чтобы в отчете фигурировало полное ФИО пользователя, а не доменное имя или IP-адрес. Для этого нужно заменить оригинальный файл /usr/share/lightsquid/ip2name/ip2name.squidauth следующим:

#contributor: esl
#specialy for squid with turned on user authentication
#simple version
 
use strict;
use warnings;
use Net::LDAP;
use Encode;
 
my $ldap;
my $message;
my %hDisplayName;
 
sub StartIp2Name() {
        my $server = "ldap://dc.mydomain.ru";
        $ldap = Net::LDAP->new( $server );
        return if(!defined $ldap);
        $message = $ldap->bind(q(mydomain.ru\lightsquid), password => "my_password");
}
 
sub Ip2Name($$$) {
  # $Lhost,$user,$Ltimestamp
  my $Lhost=shift;
  my $user =shift;
  $user    =URLDecode($user); #decode user name
  $user = substr($user, , index($user, "\@mydomain.ru"));
  return $Lhost if ($user eq "-");
  return $user if (!defined $ldap);
  return $user if ($message->code());
 
  if (!defined $hDisplayName{$user})
  {
 
    my $result = $ldap->search(
    base        => "dc=mydomain,dc=ru",
    filter      => "(&(objectCategory=person)(objectClass=user)(sAMAccountName=" . $user . "))",
    );
 
my $first_entry = $result->entry();
if (!defined $first_entry)
  {
    return $Lhost;
  }
 
my $pure_displayName = $first_entry->get_value("displayName");
$pure_displayName =~ s/ /_/g;
Encode::from_to($pure_displayName, 'utf-8', 'windows-1251');
 
  $hDisplayName{$user}=$pure_displayName;
  }
 
  return $hDisplayName{$user};
}
 
 
sub StopIp2Name() {
        return if (!defined $ldap);
        $message = $ldap->unbind;
}
 
#warning !!!
1;

В этом файле исправляем нижеуказанные строки на свои:

...
        my $server = "ldap://dc.mydomain.ru";
...
        $message = $ldap->bind(q(MYDOMAIN.RU\LightSquid), password => "PASSWORD");
...
    base        => "dc=MYDOMAIN,dc=RU",
...

Теперь в /etc/lightsquid/lightsquid.cfg включаем преобразование логина в ФИО:

$ip2name="squidauth"

Запускаем /usr/share/lightsquid/check-setup.pl и если все хорошо, можно запускать /usr/share/lightsquid/lightparser.pl

В папке /var/lib/lightsquid/report должны появиться отчеты, которые можно поглядеть по адресу: http://192.168.1.1/lightsquid/

Что такое Kerberos?

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

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

Протокол Kerberos получил широкое признание с момента его создания в Массачусетском технологическом институте в 1980-х годах. Теперь он встроен в бесчисленное количество зависимых от безопасности реализаций в Интернете, и почти все компании ежедневно взаимодействуют по крайней мере с одной системой Kerberos.

Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.

Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.

Преимущества Kerberos

Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:

• Безопасность: Kerberos никогда не передает пароли по сети. Вместо этого Kerberos подтверждает личность пользователя, отправляя ограниченные по времени криптографические сообщения, которые становятся недействительными по истечении установленного периода. Даже сообщения были перехвачены и расшифрованы, они были бы бесполезны в считанные минуты!
• Единый вход: Kerberos требует, чтобы пользователь вводил пароль только один раз при первой аутентификации клиента. С этого момента пользователь имеет доступ ко всем керберизованным службам в области Kerberos без необходимости повторно вводить свой пароль. Единый вход упрощает работу с несколькими службами, устраняя необходимость в нескольких требованиях входа в систему.

Надежная третья сторона: Kerberos использует централизованный сервер аутентификации, известный как Центр распространения ключей (KDC), которому по умолчанию доверяют все другие устройства в сети. Все запросы аутентификации, такие как криптографические сообщения, маршрутизируются через этот сервер. Такой аутсорсинг гарантирует, что конфиденциальная информация не будет храниться на локальном компьютере.

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

Пример взаимной аутентификации:

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

Вступление#

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

• Знание устройства протокола Kerberos необходимо для понимания ряда классических атак.
• Периодически появляются новые атаки, но прежде чем приступать к их эксплуатации, необходимо разобраться к каким последствиям они могут привести. Без знания Kerberos это порой затруднительно, либо вовсе невозможно.
• Личная чуйка, что если человек называет себя специалистом, то он должен обладать несколько более глубокими знаниями, чем название инструмента или кнопки, на которую надо нажать.

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

В этом цикле статей буду пытаться разобрать, как в теории устроен протокол Kerberos и какие атаки с его использованием можно осуществить на практике в Active Directory. Также будут приведены некоторые рекомендации по противодействию рассматриваемым атакам.

В первой части будет рассмотрено устройство Kerberos в общем случае, а также реализация Kerberos в Active Directory.

Подготовка Windows Hello для бизнеса

Процесс подготовки Windows Hello для бизнеса начинается сразу после входа пользователя в систему при прохождении определенных проверок предварительных требований. Windows Hello для бизнеса облачное доверие Kerberos добавляет проверку предварительных требований для гибридных устройств, присоединенных к Azure AD, если доверие к облачную службу Kerberos включено политикой.

Состояние проверки готовности можно определить, просмотрев журнал администратора регистрации устройств пользователей в разделе Журналы> приложений и служб Майкрософт>Windows.
Эти сведения также доступны с помощью команды из консоли. Дополнительные сведения см. в разделе dsregcmd.

Проверка готовности к доверию в облаке Kerberos определяет, есть ли у пользователя частичный TGT перед запуском подготовки. Цель этой проверки — проверить, настроен ли Azure AD Kerberos для домена и клиента пользователя. Если настроен Azure AD Kerberos, пользователь получит частичное TGT во время входа с помощью одного из других методов разблокировки. Эта проверка имеет три состояния: «Да», «Нет» и «Не протестировано». Состояние «Не протестировано» отображается, если политика не применяет доверие к облачную службу Kerberos или устройство Azure AD присоединено.

Примечание.

Проверка готовности к доверию к Cloud Kerberos не выполняется на устройствах, присоединенных к Azure AD. Если Azure AD Kerberos не подготовлен, пользователь на подключенном к Azure AD устройстве по-прежнему сможет войти в систему, но не будет иметь единого входа в локальные ресурсы, защищенные Active Directory.

Настройка ПИН-кода

Это процесс, который происходит после входа пользователя в систему, чтобы зарегистрироваться в Windows Hello для бизнеса:

1. Пользователю будет предложено открыть полноэкранную страницу для использования Windows Hello с учетной записью организации. Пользователь нажимает кнопку ОК.
2. Поток подготовки переходит к части регистрации с многофакторной проверкой подлинности. Подготовка информирует пользователя о том, что он активно пытается связаться с пользователем через настроенную форму MFA. Процесс подготовки не продолжается до успешной проверки подлинности, сбоя или истечения времени ожидания. Сбой или истечение времени ожидания MFA приводит к ошибке и просит пользователя повторить попытку.
3. После успешной многофакторной идентификации в рамках процесса подготовки пользователь получает запрос на создание и проверку PIN-кода. Этот ПИН-код должен соблюдать все политики сложности ПИН-кода, настроенные на устройстве.

Вход

После настройки ПИН-кода с облачным доверием Kerberos его можно использовать сразу же для входа. На устройстве, присоединенном к гибридному Azure AD, первое использование ПИН-кода требует прямой видимости контроллера домена. После входа пользователя или разблокировки с контроллером домена кэшированный вход можно использовать для последующих разблокировок без прямой видимости или сетевого подключения.

Enterprise Desktop Client¶

This section applies to the Enterprise Desktop Client (EDC) running on a
Windows workstation.

Workstation Configuration

The user workstation (Windows) must be configured to allow SSO
authentication into OVD. For this, a local or domain admin access to the
workstation is required. Please note that domain GPO (Group Policy) may
be used to automate the changes below in an enterprise environment.

AllowTGTSessionKey

There is a key called AllowTgtSessionkey in the Windows registry
that controls whether a client application is allowed to decrypt the
session key of a Kerberos Ticket Granting Ticket (TGT). This capability
must be enabled.

1. Login as an admin user on the user workstation
2. Run the registry editor:
3. Create a registry entry as follows for Windows Vista, 7, 8 or 10.

Enable DES

Depending on your version of Windows, further settings may need to be
applied as described in the Microsoft information page at
https://technet.microsoft.com/en-us/library/dd560670(v=ws.10).aspx

These settings apply to Windows 7, Windows 8 and Windows 10.

1. Open an admin session on the workstation
2. Run from a command prompt

3. Navigate

4. Open the Network Security: Configure encryption types allowed for
   Kerberos setting and enable the following options:

5. Reboot the workstation

Start the EDC and check Use Local credentials as shown in the figure
below:

Note

Clicking on Start should start the session without the
need to enter any further credentials.

Основанное на ресурсах ограниченное делегирование в доменах

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

Какой эффект дает это изменение?

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

Это также смещает решение о том, должен ли сервер доверять источнику делегированного удостоверения от администратора домена с делегированием к владельцу ресурса.

Что работает иначе?

Изменение базового протокола позволяет осуществлять делегирование между доменами. реализация Windows Server 2012 R2 и Windows Server 2012 протокола Kerberos включает в себя расширения протоколов служб для пользователей и прокси (S4U2Proxy). Данный набор расширений для протокола Kerberos позволяет службе использовать билет службы Kerberos, благодаря которому пользователь получает билет службы из центра распространения ключей (KDC) для внутренней службы.

Подробности о реализации данных расширений см. в разделе . Расширения протокола Kerberos: S4U и спецификация протокола ограниченного делегирования в библиотеке MSDN.

Дополнительные сведения об основной последовательности сообщений для делегирования Kerberos с помощью пересланного билета предоставления билета (TGT) в сравнении с расширениями Service for User (S4U) см. в разделе Обзор протокола 1.3.3 документа «. Расширения протокола Kerberos: S4U и спецификация протокола ограниченного делегирования».

Влияние ограниченного делегирования на основе ресурсов на безопасность

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

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

SID	Описание
AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITYS – 1-18-1	Идентификатор безопасности, означающий, что удостоверение клиента подтверждается центром проверки подлинности на основе подтверждения принадлежности учетных данных клиента.
SERVICE_ASSERTED_IDENTITYS – 1-18-2	Идентификатор безопасности, означающий, что удостоверение клиента подтверждается службой.

Серверная служба может использовать стандартные выражения ACL для определения способа проверки подлинности пользователя.

Как настроить ограниченное делегирование на основе ресурсов?

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

• Чтобы получить список участников, используйте командлеты Get-ADComputer, Get-адсервицеаккаунти Get-ADUser с параметром PrincipalsAllowedToDelegateToAccount Properties .

• Чтобы настроить службу ресурсов, используйте командлеты New-ADComputer, New-адсервицеаккаунт, New-ADUser, Set-ADComputer, Set-адсервицеаккаунти Set-ADUser с параметром PrincipalsAllowedToDelegateToAccount .