Настройка kerberos на windows 2008 server

Разработчики Microsoft впервые реализовали протокол Kerberos в системе Windows 2000. Протокол NTLM вошел в употребление гораздо раньше, во времена Windows NT. Kerberos представляет собой протокол аутентификации, базирующийся на концепции доверенной третьей стороны trusted third party (TTP), тогда как в основу протокола NTLM положен механизм «запрос-ответ» (challenge/response). Более подробно различия между двумя протоколами описаны в таблице.

При обмене данными в ходе аутентификации с использованием протокола NTLM серверный ресурс (например, файл-сервер) генерирует запрос, который направляется клиенту. Клиент формирует NTLM-ответ, включающий хеш пароля пользователя, а сервер проверяет правильность этого ответа. Если клиент использует локальную учетную запись, сервер проверяет ответ пользователя с помощью хеша пароля пользователя, который хранится в локальной базе данных диспетчера учетных записей безопасности Security Account Manager (SAM). Если же клиент применяет доменную учетную запись, сервер передает ответ для проверки контроллеру домена, ибо только контроллеры доменов хранят в своих базах данных Active Directory (AD) копии хешей пользовательских паролей.

В системе Windows Kerberos доверенной третьей стороной является контроллер домена Windows 2000 или более поздней версии, на котором размещается служба центра распространения ключей Kerberos Key Distribution Center (KDC). Центр KDC облегчает процедуру аутентификации между оснащенным средствами Kerberos клиентом и сервером. Служба KDC автоматически устанавливается как компонент системы AD и состоит из двух подсистем: службы аутентификации Authentication Service (AS) и службы предоставления билетов Ticket-Granting Service (TGS).

Когда пользователь регистрируется в домене Windows с использованием протокола Kerberos, клиент Windows первым делом проверяет подлинность пользователя на контроллере домена с помощью пользовательского пароля. В то же время клиент запрашивает билет на выдачу билета Ticket Grant Ticket (TGT) в службу аутентификации. TGT можно рассматривать как временный пароль (по умолчанию время его жизни составляет 8 часов), который будет заменять пароль пользователя в последующих запросах на аутентификацию. Когда пользователю нужно будет обратиться к серверному ресурсу, клиент представит TGT на выдачу TGT для проверки подлинности на серверном ресурсе. Имейте в виду, что, в отличие от NTLM, протокол Kerberos не используется для локальной аутентификации в диспетчере учетных записей безопасности Windows; его сфера применения ограничивается доменной аутентификацией на контроллере домена.

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

Почему Kerberos?

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

Еще одно достоинство Kerberos состоит в том, что этот протокол предусматривает использование отметок времени для защиты от атак с повторной передачей пакетов. Вот почему так важно наличие службы синхронизации времени, безупречно функционирующей в Kerberos-центрической среде Windows. В Windows 2000 и более новых версиях системы службы времени работают без предварительной настройки. Если компьютерные часы на разных компьютерах не синхронизированы, это может обернуться дополнительным трафиком в процессе аутентификации по стандарту Kerberos или же — в худшем случае — такая ситуация может вызвать ошибку в процессе аутентификации.

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

Служба может обращаться к удаленным ресурсам от имени пользователя с помощью механизма делегирования аутентификации. Иными словами, пользователь может предоставлять системе-посреднику право подтвердить от своего имени свою (пользователя) подлинность на сервере приложений. В результате сервер приложений получает возможность принимать решения по авторизации не на базе идентичности системы-посредника, а основываясь на идентичности пользователя. Функция делегирования проверки подлинности весьма полезна в многоуровневых приложениях, таких как доступ к базам данных с помощью внешнего интерфейса на базе Web.

Наконец, надо сказать, что, хотя специалисты Microsoft проделали большую работу по модернизации протокола NTLM, а именно создали версию NTLMv2, которая поддерживается в среде NT4 SP4 и более новых версиях, в продукте Microsoft Kerberos реализовано большее число современных алгоритмов шифрования. Я расскажу об этом подробнее в разделе, посвященном средствам шифрования протокола Kerberos

Ограничения протокола NTLM

Преимущества аутентификации средствами протокола Kerberos сомнения не вызывают. Но даже в среде AD Server 2008 Windows часто использует протокол NTLM, например, когда вы подключаетесь к системе Windows, выпущенной до появления Windows 2000, или при подключении к общедоступному ресурсу с помощью команды net use и IP-адреса (а не имени NetBIOS). Кроме того, приложения, у которых имена участников службы service principal names (SPN) не настроены должным образом, будут по-прежнему использовать протокол NTLM.

Чтобы узнать, каким протоколом — NTLM или Kerberos — вы пользуетесь в данный момент, можете визуализировать трафик NTLM с помощью утилиты netmon или другого трассировщика сети; альтернативный вариант — проверить содержимое кэша билетов Kerberos с помощью инструмента klist (который входит в комплекты поставки Windows 7 и Server 2008). В системах Windows 7 и Server 2008 специалисты Microsoft реализовали новые групповые политики, с помощью которых можно отслеживать, а также блокировать использование протокола NTLM вашими пользователями и приложениями. Всего таких политик три: одна для входящего трафика NTLM (для отслеживания и блокировки на уровне сервера), другая для исходящего трафика NTLM (для отслеживания и блокировки на уровне клиента) и третья для доменного трафика (для отслеживания и блокировки на уровне контроллера домена). Они размещаются в контейнере Security Options Group Policy Object (CPO), попасть в который можно, последовательно выбирая пункты Computer Configuration, Windows Settings, Security Settings, Local Policies (см. экран 1). Все они начинаются с элемента Network security: Restrict NTLM:.

Каждая настройка политики имеет параметры audit и block. Когда вы включаете функцию аудита NTLM, программа создает записи журнала событий с исходными данными NTLM и числами 8001, 8002, 8003 и 8004. Журнальные записи хранятся в контейнере Operational с путем доступа Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. Я рекомендую для начала провести аудит NTLM в тестовой среде и позаботиться о том, чтобы там были должным образом представлены все ваши приложения. Если начать произвольно блокировать использование протокола, скорее всего, некоторые приложения функционировать не будут. Чтобы не допустить потери событий, следует перед началом тестирования средств аудита NTLM установить решение для сбора событий аудита; можете воспользоваться встроенной службой Windows Event Collector, средствами Event Subscriptions или решением от независимого поставщика. Кроме того, я рекомендую первым делом начать мониторинг NTLM на серверах. Вы можете подключить клиенты для проведения детального анализа, после того как станет очевидно, что сервер использует протокол NTLM. Уяснив, какие приложения используют NTLM, вы можете разработать стратегию блокировки NTLM. Эта стратегия может включать в себя стратегию исключений для устаревших приложений, которые не могут быть переписаны или перенастроены и которые всегда будут требовать применения NTLM.

К сожалению, упомянутые настройки NTLM нельзя применять на старых системах Windows. Однако эти системы допускают возможность управления версиями протокола NTLM. Вы можете, например, отключить фрагмент LM протокола аутентификации NTLM (поскольку этот фрагмент слаб по самой своей природе) или задать принудительное применение протокола NTLMv2. Для этого следует воспользоваться настройкой Network Security: LAN Manager Authentication Level GPO, которая размещается в контейнере Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options GPO (см. экран 2).

Средства шифрования Kerberos

Криптографические протоколы, используемые протоколами аутентификации, играют важную роль в обеспечении безопасности последних. Как я уже отмечал, в этой области показатели Kerberos выше, чем у протокола NTLM. Алгоритм шифрования RC4 был впервые реализован в протоколе Windows Kerberos в версии Windows 2000 и по сей день поддерживается в системах Server 2008, а также Windows 7 (точнее говоря, поддерживается его версия RC4_HMAC_MD5). В системах Server 2008, Windows Vista и более новых версиях разработчики Microsoft добавили средства поддержки шифрования по стандарту Advanced Encryption Standard, AES, а системы Windows 7 и Server 2008 R2 поддерживают типы шифрования Kerberos AES (AES128_HMAC_SHA1 и AES256_HMAC_SHA1) без предварительной настройки. AES — более новый и мощный алгоритм шифрования, нежели DES. Логика Kerberos на контроллерах доменов перейдет на стандарт шифрования AES, когда вы модернизируете домен AD до уровня Windows 2008 Domain Functional Level (DFL).

В системах Windows 7 и Server 2008 R2 типы шифрования DES для протокола аутентификации Kerberos по умолчанию отключены. Из-за этого могут возникнуть проблемы совместимости, если одно из устаревших приложений жестко закодировано на шифрование только по стандарту DES или если учетная запись Windows, выполняющая ту или иную службу (учетная запись этой службы), настроена на использование только DES-шифрования. Эти службы или приложения выйдут из строя, если вы не сможете перенастроить соответствующую службу либо приложение на поддержку другого типа шифрования (RC4 или AES) либо не восстановите поддержку стандарта DES.

Чтобы выяснить, имеются ли у вас приложения либо службы, закодированные на шифрование исключительно по стандарту DES, можно запустить сетевой трассировщик при старте соответствующего приложения или службы и проверить содержимое полей Etype в заголовках аутентификации Kerberos. Чтобы определить, настроена ли учетная запись пользователя либо компьютера AD или учетная запись компьютера для применения исключительно типов шифрования DES, нужно проверить, выбран ли на вкладке Account свойств объекта параметр Use Kerberos DES encryption types for this account. К этим свойствам можно обратиться из оснастки AD Users and Computers консоли MMC.

Если вы выполните упомянутые выше проверки и окажется, что у вас возникла эта проблема, можете активировать DES-шифрование для аутентификации с помощью Kerberos на компьютерах, функционирующих под Windows 7 или Server 2008 R2, с помощью GPO настройки Network security: настройте типы шифрования, совместимые со стандартом Kerberos; эти настройки расположены в контейнере Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO.

Итак, из двух протоколов аутентификации Windows предпочтительным является протокол Kerberos. Администраторам следует всегда настаивать на том, чтобы пользователи и приложения применяли именно Kerberos, а не NTLM. Новые ограничения по использованию NTLM, реализованные в системах Windows 7 и Server 2008 R2, открывают перед нами отличную возможность для достижения этой цели.

Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft

Доброго времени, уважаемые читатели и гости блога! В продолжении прошлой темы о NFS, хочу опубликовать небольшой мануал как настроить экспортированные каталоги NFSv4 на проверку подлинности через Active Directory на Windows 2008 R2. Данный пост я реализовывал на дистрибутиве Debian. Удачно заставить работать NFSv4 и AD на Windows 2008 мне удалось только на тестовой версии — wheezy с ядром 3.0.0. На версии squeeze до сих пор идут дебаты по поводу ошибки

Nov 17 11:20:49 archiv rpc.svcgssd[13849]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): 
GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - 
No supported encryption types (config file error?)

Если появится какое-либо решение этой проблемы, то я обновлю пост…

План интеграции Active Directory на Windows 2008 R2 и NFSv4 на Linux (Debian wheezy)

В целом, организацию проверки подлинности ресурсов NFS посредством Kerberos можно представить в виде следующей последовательности шагов:

1. Настроить NFS и проверить работоспособность без Kerberos по протоколу NFSv4

1. Настройка NFSv4 на сервере
2. Настройка NFSv4 на клиенте.

2. Настроить Kerberos

1. Предварительная настройка DNS и контроллера домена.
2. Настройка синхронизации времени (на основе демона ntpd)
3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab

3. Настроить NFSv4 на проверку подлинности через Kerberos.

1. Настроить и проверить работу сервера NFSv4 на Debian
2. Настроить и проверить работу клиента NFSv4 на Debian

4. Траблешуттинг Troubleshooting

Давайте подробней разберем каждый шаг.

Исходные данные для организации NFS

• домен — DOMAIN.LOCAL
• DNS-имя контроллера домена — DC.DOMAIN.LOCAL
• IP-адрес контроллера домена — 10.0.0.4
• NFS-server
  • DNS-имя NFS сервера — NFSD.DOMAIN.LOCAL
  • IP-адрес NFS сервера — 10.0.0.50
• NFS-client
  • DNS-имя NFS сервера — NFSC.DOMAIN.LOCAL
  • IP-адрес NFS сервера — 10.0.0.51

1. Настройка NFSv4 без Kerberos

1.1., 1.2. Настройка NFSv4 сервера и клиента

Я решил объединить эти 2 пункта, т.к. они содержат очень похожие шаги. Поэтому начнем настройку с общих этапов для клиента и сервера. Итак, и на клиенте и на сервере необходимо настроить сеть в Debian. (Так же можно почитать статью основные понятия сетей). На сервере и клиенте необходим установленный пакет nfs-common с необходимыми зависимостями (portmap). Для того чтобы протокол Kerberos работал корректно, необходимо обязательно правильно настроить файлы /etc/hosts, /etc/hostname, /etc/resolv.conf, ну и конечно /etc/network/interfaces. Для того чтобы избавиться от возможных ошибок при работе к Kerberos, необходимо учесть некоторые нюансы (хотя и без этих нюансов скорей всего заработает), которые я отмечу комментариями:

root@nfsc:~# cat /etc/hosts
10.0.0.51       nfsc.DOMAIN.local  nfsc
127.0.0.1       localhost
# для Kerberos советуют указывать именно такой порядок
# то есть первой строкой именно 10.0.0.51 (внешний IP, не loopback)
root@nfsc:~# cat /etc/hostname
nfsc
root@nfsc:~# cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
root@nfsc:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.0.0.51
        netmask 255.255.0.0
        gateway 10.0.0.254
==================================
root@nfsd:~# cat /etc/hosts
10.0.0.50       nfsd.DOMAIN.local  nfsd
127.0.0.1       localhost

root@nfsd:~# cat /etc/hostname
nfsd
root@nfsd:~# cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
root@nfsd:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.0.0.50
        netmask 255.255.0.0
        gateway 10.0.0.254

Думаю видно, где тут сервер, где тут клиент? Если все же — нет, то как я уже говорил выше nfsd — это сервер и имеет строку root@nfsd:~#, а nfsс — это клиент и имеет строку root@nfsc:~#. На клиенте и на сервере необходимо иметь установленный пакет nfs-common, как он устанавливается и из чего он состоит я писал в прошлой статье. В конфигурационном файле NFS клиента (/etc/default/nfs-common) необходимо добавить «yes» в параметр NEED_IDMAPD=yes и NEED_GSSD=yes. Это разрешить запуск демонов rpc.idmapd и rpc.gssd, которые необходимы для работы интерфейса GSS-API для взаимодействия с Kerberos. После этого, необходимо перезапустить nfs-common на обеих машинах.

root@nfsс:~# service nfs-common restart
Stopping NFS common utilities: gssd idmapd statd.
Starting NFS common utilities: statd idmapd gssd.

Далее, настройка производится на cервере. На сервере NFS необходимо установить пакет nfs-kernel-server. И задать экспортируемые каталоги в файле /etc/exports, перезапустить сервер и проверить сделанное командой showmount:

root@nfsd:~# mkdir /nfs
root@nfsd:~# vim /etc/exports
root@nfsd:~# cat /etc/exports
/nfs    10.0.0.51(rw,sync,no_subtree_check) 10.0.0.50(rw,sync,no_subtree_check)
root@nfsd:~# service nfs-kernel-server restart
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd mountd.
root@nfsd:~# showmount -e
Export list for nfsd:
/nfs 10.0.0.50,10.0.0.51

На этом настройка сервера и клиента завершена. Давайте проверим наши настройки. Сначал необходимо попробовать смонтировать экспортированный каталог локально на сервере по протоколу NFSv4:

root@nfsd:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt
mount.nfs4: timeout set for Fri Nov 18 12:20:52 2011
mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.50'
10.0.0.50:/nfs on /mnt type nfs4 (rw)
root@nfsd:~# mount | grep nfs4
10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.50)

Как видно, монтирование произошло удачно. Более подробно о команде mount тут, а еще подробней — в man mount. Теперь проверим возможность удаленного монтирования с клиентской машины:

root@nfsc:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt
mount.nfs4: timeout set for Fri Nov 18 11:01:16 2011
mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.51'
10.0.0.50:/nfs on /mnt type nfs4 (rw)
root@nfsc:~# mount | grep nfs4
10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.51)

Как видно, опять все удачно. На этом можно считать, что NFS корректно работает по протоколу NFSv4. Теперь можно приступить к настройке протокола Kerberos на Debian.

2. Настройка протокола Kerberos на Debian

2.1. Предварительная настройка DNS и Active Directory

Для корректной работы Kerberos в Linux необходима правильная настройка DNS. «Настройка DNS» тут громко сказано, просто нужно иметь корректные записи в прямой и обратной зоне для клиента NFS и сервера NFS. Создаем эти записи в оснастке DNS (изображение) и проверим работу на Debian:

root@nfsc:~# nslookup -type=A nfsc
Server:         10.0.0.4
Address:        10.0.0.4#53

Name:   nfsc.DOMAIN.local
Address: 10.0.0.51

root@nfsc:~# nslookup -type=A nfsd
Server:         10.0.0.4
Address:        10.0.0.4#53

Name:   nfsd.DOMAIN.local
Address: 10.0.0.50

root@nfsc:~# nslookup 10.0.0.50
Server:         10.0.0.4
Address:        10.0.0.4#53

50.0.0.10.in-addr.arpa  name = nfsd.domain.local.

root@nfsc:~# nslookup 10.0.0.51
Server:         10.0.0.4
Address:        10.0.0.4#53

51.0.0.10.in-addr.arpa  name = nfsc.domain.local.

DNS корректно отдает наши IP по именам и имена DNS по IP. Это меговажный момент, ибо Kerberos активно взаимодействует с DNS и без данных записей просто не будет работать!

2.2. Настройка синхронизации времени для протокола Kerberos

Для работы среды Kerberos v5 необходимо, чтобы расхождение времени KDC и хостов, запрашивающих доступ к каким-либо ресурсам и времени на хостах, предоставляющих сами ресурсы не составляло более 5 минут. Для синхронизации будем использовать возможности пакета ntp. О том, как настроить сервер и клиента NTP я уже рассказывал в прошлых статьях, поэтому отправлю вас читать NTP server на Linux. Здесь же ограничусь основными параметрами. Итак, на клиенте и сервере NFS необходимо установить пакет ntp, отредактировать файл конфигурации /etc/ntp.conf до следующего вида (после этого перезапустить службу ntp):

root@nfsd:~# cat /etc/ntp.conf
server dc.domain.local
restrict default ignore
restrict dc.domain.local
restrict 127.0.0.1 nomodify notrap
root@nfsd:~# service ntp restart
Stopping NTP server: ntpd.
Starting NTP server: ntpd.

2.3. Настройка клиента Kerberos на Debian Wheezy для доменной аутентификации

Данный этап необходимо сделать как на клиенте, так и на сервере — он одинаков как для сервера, так и для клиента NFS. Поэтому покажу, как настроить на примере сервера. Для Kerberos необходимо установить пакет krb5-user с зависимостями (он должен подтянуть krb5-config), далее его необходимо настроить. Настройка заключается в редактировании файла /etc/krb5.conf. Данный файл содержит настройки, необходимые библиотекам, взаимодействующим со средой Kerberos V, такие как область (ее еще называют realm) по умолчанию, расположение серверов KDC (key distribution centers) для известных областей и др. По синтаксису файл очень похож на файл конфигурации SAMBA (smb.conf) и так же состоит из разделов, выделенных квадратными скобками и параметров в формате параметр=значение (более подробно о настройках этого файла в man krb5.conf). Для работы в сети с одной областью вполне достаточно следующего конфигурационного файла:

root@nfsd:~# cat /etc/krb5.conf
[libdefaults]
        default_realm = DOMAIN.LOCAL
[realms]
        DOMAIN.LOCAL = {
                kdc = dc.domain.local
        }

Раздел [libdefaults] содержит значения по-умолчанию для Kerberos V библиотек, а параметр default_realm задает область по умолчанию, которая будет задействована при взаимодействии с Kerberos. Раздел  [realms] содержит подразделы с параметрами, отписывающими область Kerberos, например расположение KDC контроллера. Остальные параметры, которые часто советуют указывать в этом файле вполне работоспособны и по-умолчанию.  После данной настройки давайте проверим работоспособность Kerberos, для этого используется утилита kinit. Kinit запрашивает, получает и кэширует TGT (ticket-granting ticket)-билеты от KDC.

root@nfsc:~# # получаем билет для любого доменного пользователя
root@nfsc:~# kinit domainuser
Password for domainuser@DOMAIN.LOCAL:
root@nfsc:~# # после ввода пароля ошибок не было
root@nfsc:~# # значит билет получен корректно
root@nfsc:~# # просмотрим содержимое кэша:
root@nfsc:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: domainuser@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/18/11 16:12:00  11/19/11 02:12:08  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/19/11 16:12:00
root@nfsc:~# ls -la /tmp/krb5*
-rw------- 1 root root 1101 Ноя 18 16:12 /tmp/krb5cc_0
root@nfsc:~# # очистим содержимое кэша:
root@nfsc:~# kdestroy
root@nfsc:~# ls -la /tmp/krb5*
ls: невозможно получить доступ к /tmp/krb5*: Нет такого файла или каталог

Как видно, билет корректно получен. Не забудьте те же действия проделать на сервере.

Тут я сделаю небольшое отступление в виде абзаца, взятого не помню откуда и не с первого прочтения подающегося пониманию, но тем не менее, хорошо описывающего работу Kerberos ):

Сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровки TGT, который уже получен kinit. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее удостоверение. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT.

Идем дальше…

2.4. Создание keytab-файла на контроллере домена Windows 2008 R2

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

Наступает самый интересный этап. Не углубляясь в Kerberos, keytab-файл это «связка ключей», файл содержащий в себе одну или несколько запсей — ключей, которые используются вместо логина/пароля при запросе доступа у сервера KDC к какому-либо ресурсу. Другими словами, машина предоставляет данный файл серверу KDC как подтверждение своей достоверности, когда запрашивает у контроллера домена (KDC) доступ к какому-либо ресурсу (например доступ к службе или сетевому каталогу). В большинстве случаев, при настройке какой-либо службы в связке с Kerberos проблемы возникают именно на данном этапе, т.к. именно этот файл является связующим звеном между Windows 2008 и Linux (в нашем случае — Debian). Проблемы обычно связаны с различными типами шифрования, которые поддерживает Windows, но не поддерживает Linux и наоборот…

Итак, согласно документации жадных, Windows 7 и Windows Server 2008 R2 более не поддерживают типы шифрования, основанные на DES (DES-CBC-MD5 & DES-CBC-CRC), но в них включены следующие типы шифрования (по убиванию стойкости):

• AES256-CTS-HMAC-SHA1-96
• AES128-CTS-HMAC-SHA1-96
• RC4-HMAC

При этом, необходимо учитывать, что если при использовании Kerberos будут использоваться клиенты на основе WinXP и младше, то они из всего приведенного поддерживают только RC4-HMAC.

keytab создается с помощью утилиты ktpass (документация по ней), которая с Windows 2003 SP1 входит в состав дистрибутива, а в дистрибутивах младше — необходимо установить отдельно Microsoft Server SupportTools, имеющегося на диске с дистрибутива Windows Server . Формат создания keytab утилитой ktpass следующий:

ktpass.exe /princ имя_службы/fqdn.имя.хоста@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ
/mapuser учетная_запись_хоста$@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ
/crypto тип_шифрования
/ptype ТИП_ПРИНЦИПАЛА
/pass пароль_или_+rndpass
/out C:каталогсоздаваемый_файл

В примере параметры команды для удобства выстроены в столбик, реально же они пишутся все в одну строку. Давайте поймем,  что делает команда ktpass и ее параметры и все их рассмотрим. Вообще, говоря о функциях и назначении данной программы, то создание keytab файла — это одна из двух ее функций, другая функция — это создание принципала (/princ), «привязанного» (примапленного — /mapuser) к учетной записи компьютера или пользователя.  Принципал представляет собой SPN-запись (server principal name, дословно — имя основного сервера), думаю, что из дословного перевода SPN, понятно что назначение этой записи — указать на компьютер, предоставляющий тот или иной сервис (службу, в нашем случае — служба NFS). О том, что есть принципал (SPN) — более подробно — можно почитать тут. Давайте пойдем по прядку по параметрам…

Параметр /princ

Задает имя службы и хост, на котором она (служба) расположена и в какой области домене. В нашем случае указывается nfs/nfsd.domain.local@DOMAIN.LOCAL (для сервера NFS) и nfs/nfsс.domain.local@DOMAIN.LOCAL (для клиента NFS). Для примера, для службы Apache указывается принципал HTTP/fqdn.имя.хоста@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ, причем HTTP обязательно В ВЕРХНЕМ РЕГИСТРЕ, многие службы требуют указания имени службы в SPN именно в верхнем регистре. Узнать, в каком регистре и какое значение имя_службы указывать можно из документации к службе, например в man rpc.gssd есть такая информация. Очень часто указывается общее имя принципала host/fqdn@REALM. Стоит отметить такой нюанс…почему-то во всех источниках указывают, что должно стоять имя FQDN. Но на сколько я знаю, FQDN-имя предполагает наличие точки в конце имени, но тем не менее — точку не ставят в данном случае.

Параметр /mapuser

Задает имя доменной учетной записи, к которой «цепляется» указанный выше SPN. Для нас это будет созданные в предыдущем разделе учетные записи компьютеров nfsc$@DOMAIN.LOCAL — для клиента и nfsd$@DOMAIN.LOCAL — для сервера.

Параметр /crypto

Задает тип шифрования Kerberos, который будет использоваться при шифрации/дешифрации билетов, передаваемых между контроллером домена KDC и хостами. На Windows 2008 R2 мне удалось запустить корректную аутентификацию при указании параметра /crypto ALL (то есть keytab создавался с несколькими принципалами со всеми поддерживаемыми типами шифрования). Тем не менее, желательно придерживаться следующих правил, чтобы избежать проблем с шифрованием: для win 2k и 2k3 желательно указывать /crypto DES-CBC-MD5, для Win 2k3 SP1 — /crypto rc4-hmac-nt, для Windows 2008 R2 — /crypto AES256-SHA1 или /crypto rc4-hmac-nt.

Параметр /ptype

Задает тип принципала. В значении этого параметра рекомендуется указывать KRB5_NT_PRINCIPAL, т.к. подходит практически для всех служб.

Параметр /pass

Задает пароль, который может быть указан вручную, или устанавливает произвольный пароль, если задано значение +rndpass.

Параметр /out

Задает имя выходного файла keytab.

Итак, рассмотрев параметры, можно составить команды, которые создадут нам необходимые keytab файлы на контроллере домена:

C:Windowssystem32>ktpass.exe /princ nfs/nfsc.domain.local@DOMAIN.LOCAL /mapuser 
nfsc$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass 
/out C:tmpnfsckeytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped nfs/nfsc.domain.local to NFSC$.
WARNING: Account NFSC$ is not a user account (uacflags=0x1021).
WARNING: Resetting NFSC$'s password may cause authentication problems if NFSC$
is being used as a server.

Reset NFSC$'s password [y/n]?  y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:tmpnfsckeytab:
Keytab version: 0x502
keysize 55 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0x206e7fbaa738ec1c)
keysize 55 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0x206e7fbaa738ec1c)
keysize 63 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 79 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x12 (AES256-SHA1) keylength 32 (0x624fe15973fb5bda6c88a289260789cd16b135451f296
a83679424c27c04507a)
keysize 63 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x11 (AES128-SHA1) keylength 16 (0x5ea804c4527c2467f7c710d845c09821)

Это был клиент. Как видно, вывалилось несколько «варнингов». Первый нам говорит, о том, что это аккуант не пользователя, а компьютера, второй — что могут возникнуть проблемы, если мы сбросим пароль (но мы то знаем, что делаем, поэтому подтверждаем и жмахаем Ентер), третий говорит нам, что ptype не соответствует аккуанту. Это произошло потому что мы указали «общий» тип, а привязали принципал к учетной записи хоста. Теоретически, это не должно привести к проблемам при настройке, но если сообщение мозолит глаза, то можно указать тип KRB5_NT_SRV_HST. Давайте теперь создадим кейтаб для сервера NFSv4:

C:Windowssystem32>ktpass.exe /princ nfs/nfsd.domain.local@DOMAIN.LOCAL /mapuser 
nfsd$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass 
/out C:tmpnfsdkeytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped nfs/nfsd.domain.local to NFSD$.
WARNING: Account NFSD$ is not a user account (uacflags=0x1021).
WARNING: Resetting NFSD$'s password may cause authentication problems if NFSD$
is being used as a server.

Reset NFSD$'s password [y/n]?  y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:tmpnfsdkeytab:
Keytab version: 0x502
keysize 55 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0xb36dd6ef3b518f73)
keysize 55 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0xb36dd6ef3b518f73)
keysize 63 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 79 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x12 (AES256-SHA1) keylength 32 (0x760287626e74dea671b3c90cfae8d2b2f5b69f596ff9e
f73c8c3da476ee64925)
keysize 63 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x11 (AES128-SHA1) keylength 16 (0x8fa396ecd3d4a69c329437b08da883e9)

Итого, мы получили 2 keytab в каталоге C:tmp для клиента — nfsсkeytab и для сервера — nfsdkeytab: 

Примечание. Подразделение (Organization Unit) в котором размещены учетные записи сервера (nfsd) и клиента (nfsc) не должны иметь в своем имени кириллических символов. Иначе при создании keytab будет ошибка Password set failed! 0×00000020. Aborted. (Спасибо за замечание комментатору Михаилу)

Теперь эти ключи Kerberos необходимо БЕЗОПАСНО скопировать на соответствующие машины, например чрез WinSCP и приступить к следующему шагу.

2.5. Настройка клиента Kerberos для аутентификации через keytab

Допустим, мы скопировали наши keytab файлы в папку пользователя root. Теперь рассмотрим настройку keytab на сервере NFS:

root@nfsd:~# ktutil
ktutil:  rkt /root/nfsdkeytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   2    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   3    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   4    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   5    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
ktutil:  wkt /etc/krb5.keytab
ktutil:  q
root@nfsd:~# kinit -k  nfs/nfsd.domain.local
root@nfsd:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/nfsd.domain.local@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/19/11 01:17:30  11/19/11 11:17:31  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/20/11 01:17:30
root@nfsd:~# kdestroy
root@nfsd:~# chmod -v u=rw,go-rwx /etc/krb5.keytab
права доступа «/etc/krb5.keytab» изменены с 0644 (rw-r--r--) на 0600 (rw-------)

Давайте разберем сделанное: сначала, с помощью утилиты ktutil прочитали исходный скопированный файл, просмотрели его содержимое, чтобы убедится, что это нужный нам файл и записали прочитанное содержимое в файл /etc/krb5.keytab, который читается библиотеками Kerberos, затем вышли из утилиты командой q. Командой kinit с параметром -k и указанным именем службы мы попробовали проверить подлинность без пароля с помощью keytab. Данное действие корректно завершилось, т.к. ошибок выдано не было и klist нам отобразил полученный билет из кэша. Далее мы удалили полученный билет и задали права на доступ к krb5.keytab только пользователю root. Дополнительно могу отметить, что иногда приходится к kinit добавить ключ -t с путем к кейтаб-файлу. Это может понадобиться, если по какой-то причине, kinit не смог найти и обратиться к keytab файлу по умолчательному пути… (спасибо комментатору angel2s2)  АХТУНГ!!! Если на данном этапе kinit выдал ошибки, то далее настраивать смысла нет, ибо Kerberos клиент работает не корректно. Необходимо избавиться от ошибок.

Далее, давайте то же самое проделаем с клиентом:

root@nfsc:~# ktutil
ktutil:  rkt /root/nfsckeytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   2    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   3    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   4    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   5    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
ktutil:  wkt /etc/krb5.keytab
ktutil:  q
root@nfsc:~# kinit -k nfs/nfsc.domain.local
root@nfsc:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/nfsc.domain.local@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/19/11 01:31:28  11/19/11 11:31:29  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/20/11 01:31:28
root@nfsc:~# kdestroy
root@nfsc:~# chmod -v -u=rw,go- /etc/krb5.keytab
права доступа «/etc/krb5.keytab» изменены с 0600 (rw-------) на 0644 (rw-r--r--)

Все у нас хорошо. Можно пробовать настроить NFS через Kerberos.

3. Настройка NFSv4 на проверку подлинности через Kerberos V (Win 2k8 R2 как KDC)

Настройку начнем с сервера NFS. В конфигурационном файле сервера (/etc/default/nfs-kernel-server)  необходимо разрешить запуск демона, отвечающего за взаимодействие с Kerberos (демон rpc.svcgssd), для этого необходимо вставить yes в параметре NEED_SVCGSSD=yes, задать экспортируемому ресурсу соответствующую настройку для авторизации через KDC и перезапустить службу:

root@nfsd:~# cat /etc/exports
/nfs    gss/krb5(rw,sync,no_subtree_check)
root@nfsd:~# service nfs-kernel-server restart
Stopping NFS kernel daemon: mountd svcgssd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd svcgssd mountd.
root@nfsd:~# showmount -e
Export list for nfsd:
/nfs gss/krb5

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

root@nfsd:~# umount -v /mnt
NFSv4 mount point detected
10.0.0.50:/nfs umounted
root@nfsd:~# mount -v -t nfs4 -o sec=krb5 nfsd:/nfs /mnt
mount.nfs4: timeout set for Sat Nov 19 01:50:11 2011
mount.nfs4: trying text-based options 'sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50'
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5)
root@nfsd:~# mount | grep nfs4
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50)

Как видно, все получилось отлично. Давайте то же самое попробуем проделать на клиенте:

root@nfsc:~# mount -v -t nfs4 -o sec=krb5 nfsd:/nfs /mnt
mount.nfs4: timeout set for Sat Nov 19 02:24:21 2011
mount.nfs4: trying text-based options 'sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.51'
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5)
root@nfsc:~# mount | grep nfs4
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.51)

Так же — все удачно.

4. Траблешуттинг Kerberos и NFS

Диагностику стоит начать с проверки — запущены ли необходимые процессы:

root@nfsd:~# ps aux | grep rpc
root       667  0.0  0.2   2236   940 ?        Ss   Nov17   0:01 /sbin/rpcbind -w
root       690  0.0  0.0      0     0 ?        S<   Nov17   0:00 [rpciod]
statd     1666  0.0  0.3   2548  1248 ?        Ss   Nov18   0:00 /sbin/rpc.statd
root      1679  0.0  0.1   2552   736 ?        Ss   Nov18   0:00 /usr/sbin/rpc.idmapd
root      1684  0.0  0.5   3948  2240 ?        Ss   Nov18   0:28 /usr/sbin/rpc.gssd
root      3859  0.0  0.4   3880  1808 ?        Ss   01:44   0:00 /usr/sbin/rpc.svcgssd
root      3862  0.0  0.3   3076  1504 ?        Ss   01:44   0:00 /usr/sbin/rpc.mountd --manage-gids
root      4017  0.0  0.1   3424   768 pts/0    S+   02:29   0:00 grep rpc

Это вывод с сервера. На клиенте, соответственно, не будет процесса rpc.svcgssd. Далее стоит просмотреть лог /var/log/daemons.log и /var/log/syslog на наличие ошибок.

Для диагностики клиента, необходимо добавить в /etc/defaults/nfs-common строку RPCGSSDOPTS=-vvv и перезапустить nfs-common. Это запустит демон rpc.gssd в очень verbose-режиме )). Для диагностики сервера можно добавить такую же опцию в RPCSVCGSSDOPTS=-vvv и перезапустить nfs-kernel-server. После этого — наблюдать за логом /var/log/daemons.log и /var/log/syslog.

БОлше понимания о шифровании в Kerberos дает команда klist с параметром -e, что заставляет отображать типы шифрования в файле keytab и кэше.

Можно так же «поиграться» с заданием разрешенного типа шифрования Kerberos. Это делается добавлением строк в файл krb5.conf:

[libdefaults]
 …
      # явно задает тип шифрования RC4, можно
      # задать des-cbc-cbr, des-cbc-md5, aes256-cts или aes128-cts
      default_tkt_enctypes = rc4-hmac
      default_tgs_enctypes = rc4-hmac
      permitted_enctypes = rc4-hmac

Если используется Kerberos клиент старше 1.6, то скорее всего DES там как и в Windows 2008 — не поддерживается и для его включения необходимо добавить в раздел [libdefaults] строку allow_weak_crypto = true.

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

Многие ресурсы советуют добавить в krb5.conf вот такой раздел:

[logging]
FILE=/var/krb5/kdc.log

Что теоретически должно заставить библиотеки клиента kerberos писать о своей работе в лог, но заставить работать этот механизм мне не удалось, поэтому я пропустил данную настройку в статье.

Резюме.

Итак, статью можно считать завершенной. Чтобы до конца разобраться в этом вопросе мне пришлось убить более 2х недель и перечитать кучу материалов. Очень надеюсь, что  материал, который я постарался как можно понятней донести до Вас будет Вам полезен. Буду рад комментариям и замечаниям. До новых встреч!

Что почитать еще

http://blog.scottlowe.org/2007/01/15/active-directory-integration-index/ — очень много информации по интеграции UNIX и AD
http://technet.microsoft.com/en-us/library/cc734104(WS.10).aspx — Kerberos Key Distribution Center на Windows 2008
http://social.technet.microsoft.com/wiki/contents/articles/717.aspx — SPN от мелкософт
http://technet.microsoft.com/en-us/library/cc753771(WS.10).aspx — ktpass от Microsoft
http://msdn.microsoft.com/en-us/library/ms995329.aspx — очень интересная статья с теоретической точки зрения о настройке Linux, Kerberos и HTTP
http://technet.microsoft.com/ru-ru/library/dd546914.aspx — управление доступом в гетерогенных сетях
http://www.grolmsnet.de/kerbtut/ — тоже о Linux, Kerberos и HTTP
http://osdude.wordpress.com/2011/08/12/authenticating-unixlinux-to-windows-2008r2-part-3-rhel-5-6/ — неплохая теоретическая информация о шифровании в KDC на Windows 2008
http://osdude.wordpress.com/2011/08/12/authenticating-unixlinux-to-windows-2008r2-part-5-kerberos-encryption-types/ — вторая неплохая теоретическая информация о шифровании в KDC на Windows 2008
http://www.securitylab.ru/analytics/265153.php — работа Kerberos в Linux
http://nfsworld.blogspot.com/2005/06/using-active-directory-as-your-kdc-for.html — NFS и Windows 2003
http://sammoffatt.com.au/jauthtools/Kerberos — хорошая wiki по Kerberos
http://techpubs.spinlocksolutions.com/info/kerberos.html — MIT Kerberos в Debian

C Уважением, Mc.Sim!

Теги: Active Directory, HOWTO, kerberos, Linux, Microsoft Windows, NFS

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Аутентификация в системах Windows. Часть 2 — Kerberos

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

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

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

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора — определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

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

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

Источник

Kerberos: что нового?

Протокол Kerberos достаточно хорошо описан в документе «How the Kerberos Version 5 Authentication Protocol Works». Реализация протокола Kerberos в Windows Server 2003 компанией Microsoft достаточно близка к стандарту RFC 1510. С тех пор прошло 10 лет. Успели выйти Windows Server 2008, 2008 R2, 2012, готовится к выходу Windows Server 2012 R2. Сам стандарт обновился до версии RFC 4120, к которому уже согласовано большое количество дополнений. К сожалению, я нигде не видел (возможно плохо искал) документа, описывающего изменения произошедшие в протоколе Kerberos и в его реализации компанией Microsoft. Поэтому попробую восполнить этот пробел.

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

Windows Server 2008/Windows Vista

Улучшения следующие (отсюда и отсюда):

• Поддержка алгоритма шифрования AES как для самого протокола аутентификации (TGT, сервисные билеты, сессионные ключи) так и для механизма клиент-серверного взаимодействия (сообщений Generic Security Service).
• В связи с появлением роли контролеров домена только для чтения (RODC) появились отдельные учётные записи krbtgt для каждого такого контроллера с ограниченной областью действия .
• OCSP Stapling . Позволяет снизить нагрузку на сеть при аутентификации по сертификатам, благодаря тому, что контроллер домена кеширует ответы OCSP респондера.

Сам стандарт обновился с RFC 1510 до RFC 4120. Пункт, описывавший в RFC 1510 разрешённые алгоритмы шифрования был вынесен в 2 новых стандарта – RFC 3961 и RFC 3962. OCSP Stapling описан в RFC 4557.

Из интересного относительно алгоритмов шифрования:

The following encryption and checksum mechanisms MUST be supported:

Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Checksums: HMAC-SHA1-96-AES256 [RFC3962]

The following mechanisms from [RFC3961] and [RFC3962] SHOULD be supported:

Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

Относительно процедуры предварительной аутентификации:

The PA-ENC-TIMESTAMP method MUST be supported by clients, but whether it is enabled by default MAY be determined on a realm-by-realm basis. If the method is not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an acceptable method, the client SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-authentication method.

Эта процедура реализована в Windows Server 2008/Windows Vista.

Теперь посмотрим немного подробнее на улучшения.

В свойствах учётной записи появились 2 новых пункта, связанные с AES:

Реализовано за счёт нового аттрибута msDS-SupportedEncryptionType.

Что означают эти галки? По умолчанию они не выставлены и в учётной записи msDS-SupportedEncryptionType не задан. Это значит, что при запросе сервисного билета (сервис запускается в контексте учётной записи), по-умолчанию для его шифррования будет использоваться RC4. При включении этих опций соответствующий алгоритм шифрования будет добавлен в список поддерживаемых алгоритмов при шифровании сервисного билета.

Процедура запроса TGT увеличилась на два шага. Теперь, по умолчанию, клиент Windows Server 2008/Windows Vista в первом запросе AS-REQ НЕ отправляет в поле paData метод PA-ENC-TIMESTAMP со штампом локального времени системы клиента, зашифрованным хешем пароля пользователя.

— AsReq: Kerberos AS Request — KdcReq: KRB_AS_REQ (10) — PaData: + SequenceOfHeader: + PaData: PA-PAC-REQUEST (128)

В ответ KDC возвращает KRB_ERROR c KDC_ERR_PREAUTH_REQUIRED (так как по-умолчанию преаутентификация должна быть пройдена), который содержит метод PA-ETYPE-INFO2 с указанием алгоритмов шифрования, которые поддерживает KDC.

Клиент отправляет AS-REQ повторно. В этот раз в запросе используется PA-ENC-TIMESTAMP с зашифрованным временем. Для шифрования выбирается самый сильный алгоритм из тех, которые прислал сервер на предыдущем шаге (в нашем случае это AES256).

Кроме этого в теле запроса (ReqBody) содержится последовательность поддерживаемых клиентом алгоритмов шифрования (как описано в RFC 4537). В дальнейшем будет использоватся наиболее сильный из тех, который поддерживают и клиент и KDC (в случае с Vista/Server 2008 это будет AES 256 по умолчанию). Процедура согласования алгоритмов шифрования очень подробно описана здесь.

Windows Server 2008 R2/Windows 7

Улучшения следующие (взято здесь, здесь и здесь):

• Алгоритм шифрования DES по-умолчанию выключен . Используются AES256-CTS-HMAC-SHA1-96, AES128-CTS-HMAC-SHA1-96, RC4-HMAC.
• Поддержка ECC (elliptic curve cryptography) при аутентификации по смарт-картам, использующим сертификаты X.509. Каких либо дополнительных настроек нет. Но оборудование должно поддерживать ECC.
• Forest Search Order . Позволяет аутентифицироваться между разными лесами (областями Kerberos) по коротким именам (леса).

Отказ от использования DES (и части других слабых криптографических алгоритмов) прописан в RFC 6649. Впрочем, Windows никогда не использовала DES, если это специально не настраивалось через соответствующий аттрибут учётной записи. Более старые версии (Windows 2000/2003/XP) использовали RC4, новые (Windows 2008/Vista/2008R2/7) используют AES. Поддержка ECC описана в RFC 5349.

При поднятии уровня домена до Windows Server 2008 R2 немного меняется процедура обработки аттрибута msDS-SupportedEncryptionType. Если он пустой (по-умолчанию), то при шифровании сервисного билета будет использоваться AES (а не RC4, как в случае с Windows Server 2008).

В групповых политиках появились следующие ключи связанные с Kerberos:

• Use forest search order
• Require strict target SPN match on remote procedure calls

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

Кроме этого появилась дополнительная настройка безопасности, в которой можно выбрать используемые Керберосом алгоритмы шифрования – «Network Security: Configure Encryption types allowed for Kerberos»:

Если эта настройка не включена, то по умолчанию будут использоваться AES и RC4 (DES по-умолчанию выключен, как я писал выше). Включая эту политику, можно задействовать произвольный набор алгоритмов шифрования для протокола Керберос.

Например, можно сильно затянуть безопасность, включив только AES256_HMAC_SHA1 (не забываем, что это приведёт к тому, что клиенты, не знающие про AES, например Windows XP, не смогут работать в домене). В этом случае число алгоритмов шифрования сильно уменьшится. KRB_ERROR вернёт:

При запросе билета к host/srv клиент явно заявит в EType только про поддержку AES:

Windows Server 2012/Windows 8

Улучшения следующие (взято здесь и здесь):

• Kerberos Armoring (Flexible Authentication Secure Tunneling, FAST). Механизм защиты пользовательских данных в процессе преаутентификации. Описан в стандарте RFC 6113. Позволяет защищать KRB_AS_REQ/KRB_ERROR сессионным ключём рабочей станции, на которой происходит аутентификация пользователя. При этом, следует помнить, что механизм не применим к защите процедуры преаутентифкации самой рабочей станции.
• Ограниченное делегирование (constrained delegation) в разных доменах/лесах . Процедура ограниченного делегирования была реализована ещё в Windows Server 2003 за счёт введения дополнительного аттрибута msDS-AllowedToDelegateTo. Но было достаточно жёсткое ограничение – механизм работал только в рамках одного домена. В Windows Server 2012 это ограничение снято. Более того, механизм работает и за пределами одного леса. То есть, фронт-энд и бэк-энд могут находиться в разных лесах. Новый аттрибут msDS-AllowedToActOnBehalfOfOtherIdentity отвечает за новый сценарий работы ограниченного делегирования. Подробнее здесь и здесь.
• Поддержка утверждений (claims) – нового типа авторизационных данных, которые позволяют использовать помимо стандартных данных типа логина/пароля более широкий набор идентификационных данных и правил доступа. Подробно о claim’ах и о том, как с ними работать писал Дмитрий Буланов здесь, здесь и здесь.
• Compound authentication – расширение FAST, которое позволяет клиентам использовать TGT, выданные устройствам.
• Сжатие ресурсных групп . В предыдущих версиях Windows при выпуске TGT он содержал в поле PAC набор универсальных и глобальных групп, в которые входил пользователь. При этом, процедуре сжатия подвергались общие части SID (SID Namespace) групп, которые находились в домене пользователя. То есть по факту SID Namespace хранился только в одном экземпляре. В Windows Server 2012 сжимаются так же локальные группы в ресурсном домене и группы из SID History. Подробнее о процедуре сжатия можно посмотреть здесь, здесь и здесь. По умолчанию она включена. Но её можно выключить на контроллере домена через ключ реестра DisableResourceGroupsFields в HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemKdcParameters. При единице сжатие выключено.
• Увеличение размера токена . Токен теперь можно увеличить до 48Кб. Либо через правку реестра (ключ MaxTokenSize в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters), либо через групповые политики.

В групповых политиках появились следующие ключи, связанные с Kerberos:

• KDC support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне KDC.
• Warning for large Kerberos tickets – включает появление предупреждений в логе контроллера домена, в случае когда в процессе аутентификации будут использоваться токены больше указанного размера.
• Specify KDC proxy servers for Kerberos clients – указывает прокси-серверы KDC, которые должен использовать клиент, если он не может найти контроллер домена.
• Disable revocation checking for the SSL certificate of KDC proxy servers – позволяет отключить проверку списка отзыва сертификатов SSL для прокси-серверов KDC.
• Fail authentication requests when Kerberos armoring is not available
• Support compound authentication – включение поддержки для compound authentication.
• Set maximum Kerberos SSPI context token buffer size – позволяет задать максимальный размер токена.
• Kerberos client support for claims, compound authentication and Kerberos armoring – включение поддержки claim’ов, compound authentication и Kerberos armoring на стороне клиента.

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

• KDC support for claims, compound authentication and Kerberos armoring – должна применяться к контроллерам домена, рекомендую использовать Always provide claims
• Kerberos client support for claims, compound authentication and Kerberos armoring – должна применяться к клиентам (рабочим станциям и пользователям)
• Fail authentication requests when Kerberos armoring is not available

Для тестовых целей можно использовать Default Domain Policy, в рабочем окружении к выбору объектов политики следует отнестить более осторожно.

Аутентификация для рабочей станции пройдёт штатно, а вот с аутентификацией пользователей картина будет следующая:

Какой пользователь и к какому сервису обращается не видно. Заглянем в сами пакеты.

Видно, что в PaData помещён только метод PA-FX-Fast, который по факту содержит зашифрованный сессионным ключём рабочей станции набор данных, которые при выключенном Kerberos armoring находятся в теле запроса в незашифрованном виде (имя клиента, сервиса, область Kerberos итд).

Согласно RFC 6113 (п.5.4.2) в AS-REQ PA-FX-Fast выглядит следующим образом:

Где KrbFastArmoredReq содержит:

KrbFastArmoredReq ::= SEQUENCE <
armor [0] KrbFastArmor OPTIONAL,
— Contains the armor that identifies the armor key.
— MUST be present in AS-REQ.
req-checksum [1] Checksum,
— For AS, contains the checksum performed over the type
— KDC-REQ-BODY for the req-body field of the KDC-REQ
— structure;
— For TGS, contains the checksum performed over the type
— AP-REQ in the PA-TGS-REQ padata.
— The checksum key is the armor key, the checksum
— type is the required checksum type for the enctype of
— the armor key, and the key usage number is
— KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, — KrbFastReq —
— The encryption key is the armor key, and the key usage
— number is KEY_USAGE_FAST_ENC.
…
>

KrbFastReq ::= SEQUENCE <
fast-options [0] FastOptions,
— Additional options.
padata [1] SEQUENCE OF PA-DATA,
— padata typed holes.
req-body [2] KDC-REQ-BODY,
— Contains the KDC request body as defined in Section
— 5.4.1 of [RFC4120].
— This req-body field is preferred over the outer field
— in the KDC request.
…
>

То есть механизм защиты преаутентификационных данных, реализованный в Windows Server 2012 полностью соответствует RFC 6113. В последнем описании есть интересный пункт FastOption, в котором, например, можно указать, чтобы данные пользователя при использовании FAST не скрывались:

FastOptions ::= KerberosFlags
— reserved(0),
— hide-client-names(1)

Но по-умолчанию, этого не происходит и KDC по факту обрабатывает первичный запрос как запрос от анонимного пользователя. Процедура обработки таких запросов описана в RFC 6112:

The Kerberos response defined in [RFC4120] contains the client identity in cleartext. This makes traffic analysis straightforward. The hide-client-names option is designed to complicate traffic analysis. If the hide-client-names option is set, the KDC implementing PA-FX-FAST MUST identify the client as the anonymous principal [RFC6112] in the KDC reply and the error response.

Что интересно, высылаемый в ответ пакет KRB_ERROR так же малоинтересен злоумышленнику, так как он тоже зашифрован и все «полезные» данные прячет в этом же методе:

Вот как это описано в RFC 6113:

The KDC MUST include all the padata elements such as PA-ETYPE-INFO2 and padata elements that indicate acceptable pre-authentication mechanisms [RFC4120] in the KrbFastResponse structure.

Следующие запросы/ответы выглядят точно так же. Весь обмен ценной информацией идёт через шифрованный канал, реализованный методом PA-FX-Fast.

Источник

Platform:

Using IIS7 this is what I did on BOTH servers. The first server and the second that we want the Kerberos authentication to «hop» to.

Step 1:

For the IIS site that has the services in it that you are calling (on each server) go into IIS manager, click on the site on the left under Connections and open up the «Authentication» section under IIS. Set «ASP.NET Impersonation» to Enabled and ‘Windows Authentication» to Enabled. All other options under Authentication (Ananymous, Forms, etc.) should be be set to Disabled.

Under «Windows Authentication» right click and select «Providers». Set the only provider to be «Negotiate:Kerberos» (This forces Kerberos. If you want, after you get Kerberos working you can use both the «Negotiate» and «NTLM» providers and remove «Negotiate:Kerberos» so that clients unable to do Kerberos can connect. Note: I currently have mine set to «Negotiate» and «NTLM» and it seems to work)

Under «Windows Authentication» right click and select «Advanced Settings». Uncheck the «Enable Kernal-mode» box. (My Extended Protection option was set to off, didn’t try anything else)

Step 2:

For each server you have to set up SPNs. The SPNs would be the following (either A OR B):

A:

If your app pool is running under an IDENTITIY that is a DOMAIN ACCOUNT add the following SPNs to THAT DOMAIN ACCOUNT on the domain controller

http/COMPUTER_NETBIOS_NAME 
http/COMPUTER_NETBIOS_NAME.FULLY_QUALIFIED_DOMAIN_NAME 
http://COMPUTER_NETBIOS_NAME.FULLY_QUALIFIED_DOMAIN_NAME

(if your not running on the default port, also add an additional 3 entries with the port name attached: http/COMPUTER_NETBIOS_NAME:PORT etc.)

B:

If your app pool is running under the IDENTITY «NetworkService» then add the same SPNs as above except replace «http» with «HOST» BUT ADD THEN TO COMPUTER_NETBIOS_NAME on your domain controller.

I’m still working to implement this in production, but this is what works for me in my Test environment. I’ll keep this updated as I find out more.

Note:

This works if you are using the COMPUTER_NETBIOS_NAME directly in the url when you connect. If you are using a alias (www.mysite.mydomain.com) or the IP address directly this will not work. I believe, although I have not fully tested it, that you would have to folle the steps above but replace COMPUTER_NETBIOS_NAME with the alias or IP address when adding the SPNs. (or add it with both the netbios and the alias/ip, not really sure)

Also, if you get an error about a setting not being valid for integrated… after you turn on the «ASP.NET Impersonation» then you might need to add

<validation validateIntegratedModeConfiguration="false" />

to your web.config in the system.webServer section

Recently, I wanted to add single sign on (SSO) functionality to our intranet server, which runs a Debian Linux. Users should be automatically logged in to the website using their Windows user accounts, which are stored in an Active Directory on a Windows Server 2008 R2, without entering their credentials again. To make this work in the described Linux/Windows environment, Kerberos is the method of choice.

Now, after looking at the small bit of configuration that is actually needed to get SSO working, the complete day I spent figuring it out seems like a waste of time 🙂 But while searching the web for answers to all the problems I faced during the initial configuration, I got a feeling that many others had to struggle with Kerberos, too.

Anyway, here is how to make SSO run on Debian Linux against Windows Server 2008 R2, started from scratch:

Make sure to use only the latest packages available, especially the ones regarding Samba and Kerberos. Otherwise Kerberos may not work due to changes in Windows Server 2008. I used the following configuration in /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian/ squeeze main
deb-src http://ftp.de.debian.org/debian/ squeeze main

These are the packages’ versions on my Debian machine:

ii  samba                             2:3.5.6~dfsg-3squeeze2       SMB/CIFS file, print, and login server for Unix
ii  samba-common                      2:3.5.6~dfsg-3squeeze2       common files used by both the Samba server and client
ii  samba-common-bin                  2:3.5.6~dfsg-3squeeze2       common files used by both the Samba server and client
ii  krb5-config                       2.2                          Configuration files for Kerberos Version 5
ii  krb5-multidev                     1.8.3+dfsg-4                 Development files for MIT Kerberos without Heimdal conflict
ii  krb5-user                         1.8.3+dfsg-4                 Basic programs to authenticate using MIT Kerberos
ii  libgssapi-krb5-2                  1.8.3+dfsg-4                 MIT Kerberos runtime libraries - krb5 GSS-API Mechanism
ii  libkrb5-3                         1.8.3+dfsg-4                 MIT Kerberos runtime libraries
ii  libkrb5-dev                       1.8.3+dfsg-4                 Headers and development libraries for MIT Kerberos
ii  libkrb53                          1.8.3+dfsg-4                 transitional package for MIT Kerberos libraries
ii  libkrb5support0                   1.8.3+dfsg-4                 MIT Kerberos runtime libraries - Support library

Install the needed packages and go through the basic configuration as described here:

• Achim Grolms: Using mod_auth_kerb and Windows 2000/2003/2008R2 as KDC
• Michele Baldessari: Active Directory and Apache Kerberos authentication
• Ulf Kosack: Debian in ein Active Directory integrieren
• Pröhl, Mark, und Michael Weiser. “Im Bann der Domänen – Single Sign-On für alle mit Active Directory.” iX, Nr. 12 (November 2008): 150-154.

In my case the basic needed configuration looks like this:

• /etc/krb5.conf

  [libdefaults]
      default_realm = YOURDOMAIN.COM
  [realms]
      YOURDOMAIN.COM = {
          kdc = DOMAINCONTROLLER.YOURDOMAIN.COM
          master_kdc = DOMAINCONTROLLER.YOURDOMAIN.COM
          admin_server = DOMAINCONTROLLER.YOURDOMAIN.COM
          default_domain = YOURDOMAIN.COM
      }
  [login]
      krb4_convert = true
      krb4_get_tickets = false

• /etc/samba/smb.conf

  workgroup = YOURDOMAIN
  realm = YOURDOMAIN.COM
  netbios name = WEBSERVER
  security = ADS
  idmap uid = 10000-20000
  idmap gid = 10000-20000
  winbind enum users = yes
  winbind enum groups = yes
  winbind use default domain = yes
  machine password timeout = 0 # needed when using only the machine account as described below

• /var/www/kerberos/.htaccess

  AuthType Kerberos
  KrbAuthRealms YOURDOMAIN.COM
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbServiceName HTTP/webserver.yourdomain.com
  Krb5KeyTab /etc/krb5.keytab
  require valid-user

Now you basically have two choices for Kerberos authentication against the Active Directory: Using a seperate technical user account (which should be the preferred method) or using only the Linux server’s machine account.

Using a seperate technical user account

• (re)join the Linux server to the domain

  webserver:~# net ads join -U administrator
  Enter administrator's password:
  Using short domain name -- YOURDOMAIN
  Joined 'WEBSERVER' to realm 'yourdomain.com'

• restart the services

  webserver:~# /etc/init.d/samba restart
  Stopping Samba daemons: nmbd smbd.
  Starting Samba daemons: nmbd smbd.
  webserver:~# /etc/init.d/winbind restart
  Stopping the Winbind daemon: winbind.
  Starting the Winbind daemon: winbind.

• check whether everything works

  webserver:~# wbinfo -t
  checking the trust secret for domain YOURDOMAIN via RPC calls succeeded

• add a technical user to your Active Directory, e.g. tukerberos with password Kerber0s
• create and attach the needed service principals for the website to the technical user on the domain controller

  ktpass -princ HOST/webserver.yourdomain.com@YOURDOMAIN.COM -mapuser tukerberos@YOURDOMAIN.COM -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass Kerber0s -out c:krb5.keytab
  ktpass -princ HTTP/webserver.yourdomain.com@YOURDOMAIN.COM -mapuser tukerberos@YOURDOMAIN.COM -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass Kerber0s -out c:krb5.keytab -in c:krb5.keytab

• copy \domaincontrollerc$krb5.keytab to webserver:/etc/krb5.keytab
• set the needed file system permissions on the keytab file

  webserver:~# chown root.www-data /etc/krb5.keytab
  webserver:~# chmod 0640 /etc/krb5.keytab

• open http://webserver/ in Internet Explorer → the user should be logged in automatically

Using only the Linux server’s machine account

• (re)join the Linux server to the domain (the error message may be ignored for now)

  webserver:~# net ads join -U administrator
  Enter administrator's password:
  Using short domain name -- YOURDOMAIN
  Joined 'WEBSERVER' to realm 'yourdomain.com'
  [2011/04/19 10:54:35.026049,  0] libads/kerberos.c:333(ads_kinit_password)
    kerberos_kinit_password WEBSERVER$@YOURDOMAIN.COM failed: Preauthentication failed

• reset the (newly created) machine account in your Active Directory so the machine’s password is reset to the initial value (i.e. the machine’s hostname, webserver)
• change the machine’s password to a new value (e.g. Kerber0s)

  webserver:~# kpasswd webserver
  Password for webserver@YOURDOMAIN.COM: webserver
  Enter new password: Kerber0s
  Enter it again: Kerber0s
  Password changed.

• add the needed service principals (e.g. HTTP/webserver, HTTP/webserver.yourdomain.com) to the machine account using adsiedit.msc on your domain controller
• request an initial Kerberos ticket

  webserver:~# kinit webserver
  Password for webserver@YOURDOMAIN.COM: Kerber0s

• find out the current kvno of the service principal

  webserver:~# kvno HTTP/webserver
  HTTP/webserver@YOURDOMAIN.COM: kvno = 18

• create a Kerberos keytab file

  webserver:~# ktutil
  ktutil:  addent -password -p HOST/webserver.yourdomain.com@YOURDOMAIN.COM -k 18 -e rc4-hmac
  Password for HTTP/webserver.yourdomain.com@YOURDOMAIN.COM: Kerber0s
  ktutil:  addent -password -p HTTP/webserver.yourdomain.com@YOURDOMAIN.COM -k 18 -e rc4-hmac
  Password for HTTP/webserver.yourdomain.com@YOURDOMAIN.COM: Kerber0s
  ktutil:  wkt /etc/krb5.keytab
  ktutil:  q

• set the needed file system permissions on the keytab file

  webserver:~# chown root.www-data /etc/krb5.keytab
  webserver:~# chmod 0640 /etc/krb5.keytab

• open http://webserver/ in Internet Explorer → the user should be logged in automatically

Possible errors and how to fix them

This is how a successful Kerberos login looks in the Apache logfile:

[Tue Apr 19 11:09:04 2011] [debug] src/mod_auth_kerb.c(1628): [client 10.120.22.74] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Tue Apr 19 11:09:04 2011] [debug] src/mod_auth_kerb.c(1240): [client 10.120.22.74] Acquiring creds for HTTP/webserver.yourdomain.com
[Tue Apr 19 11:09:04 2011] [debug] src/mod_auth_kerb.c(1385): [client 10.120.22.74] Verifying client data using KRB5 GSS-API
[Tue Apr 19 11:09:04 2011] [debug] src/mod_auth_kerb.c(1401): [client 10.120.22.74] Client didn't delegate us their credential
[Tue Apr 19 11:09:04 2011] [debug] src/mod_auth_kerb.c(1420): [client 10.120.22.74] GSS-API token of length 163 bytes will be sent back

However, these are all the different error messages I got throughout my initial attempt:

[Mon Apr 18 16:57:30 2011] [debug] src/mod_auth_kerb.c(1101): [client 10.120.22.74] GSS-API major_status:000d0000, minor_status:0000000d
[Mon Apr 18 16:57:30 2011] [error] [client 10.120.22.74] gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (, Permission denied)

→ wrong file system permissions for /etc/krb5.keytab, i.e. not readable for the webserver’s Linux user

[Mon Apr 18 17:51:54 2011] [debug] src/mod_auth_kerb.c(1101): [client 10.120.22.74] GSS-API major_status:000d0000, minor_status:025ea101
[Mon Apr 18 17:51:54 2011] [error] [client 10.120.22.74] gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (, Key table entry not found)

→ missing service principal (possibly HTTP/webserver.yourdomain.com@YOURDOMAIN.COM) in /etc/krb5.keytab

[Tue Apr 19 08:40:38 2011] [debug] src/mod_auth_kerb.c(1429): [client 10.120.22.74] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Tue Apr 19 08:40:38 2011] [debug] src/mod_auth_kerb.c(1101): [client 10.120.22.74] GSS-API major_status:00010000, minor_status:00000000
[Tue Apr 19 08:40:38 2011] [error] [client 10.120.22.74] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

→ the website is not in zone “Local Intranet” in IE or IE is configured incorrectly, see Authentication Uses NTLM instead of Kerberos

[Tue Apr 19 09:31:43 2011] [debug] src/mod_auth_kerb.c(1101): [client 10.120.20.81] GSS-API major_status:000d0000, minor_status:000186a3
[Tue Apr 19 09:31:43 2011] [error] [client 10.120.20.81] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, )

→ wrong kvno or machine password in /etc/krb5.keytab → recreate the keytab using the correct information
→ OR problem with local Kerberos ticket cache on your workstation, use Kerbtray.exe to purge the ticket cache and open the website in IE again

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

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

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора — определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

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

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

First published on TechNet on Apr 22, 2009

Hi all,

Rob

here again. I had a case recently where the customer wanted to have the Windows Server 2008 Certificate Authority website loaded on another machine.

For those of you that do not know, you can install the Windows Server 2008 CA web site pages on an alternate server from the CA. One reason why you might deploy this configuration is if you currently have a Windows 2000 / Window Server 2003 Certification Authority and need to be able to deploy certificates to Windows Vista and Windows Server 2008 machines via the CA web site pages. Another reason might be because you want to offer certificate enrollment to Internet-based users but do not want to expose your Certification Authority to the Internet.

While I was working with the customer I found quite a few different configurations that are possible with IIS7, but each configuration requires a different setup within Active Directory and IIS7.

Getting started

The first thing to be decided is which account will be used for the web application pool account.

• Network Service.
• A domain user account (also known as custom identity).

The easier configuration is to leverage Network Service as the application pool account for the CertSrv web site. However, if you plan on bringing up more than one web server and use a network load balancer in front of the web servers your only option is to use a domain user account for the application pool identity.

The second thing that needs to be decided is what type of delegation you require in the environment.

• Open Delegation

  (Need to have Domain Functional Level at least Windows 2000)

• Constrained Delegation

  (Need Domain Functional Level at least Windows Server 2003)

• Constrained delegation with Protocol Transition

  (Need to configure the website to use Basic Authentication)

I am not going to dig deeply into the differences between open and constrained delegation; you can view the Kerberos section of the

AskDS blog

. Basically, constrained delegation is more secure because you are limiting to what back end service the application is allowed to impersonate the user account to.

Installing the Certification Authority website pages

Alright, so you have made your decision on what type of delegation you want and what account you will be using for the Web Application Pool Identity. Let’s install the IIS components:

1. Launch Server Manager (

servermanager.msc

).

2. Click on the

Add Roles

link in the right hand pane.

Installation Figure 1 — Add Roles

3. Check

Active Directory Certificate Services

and click the

Next

button.

4. Uncheck

Certification Authority

and check

Certification Authority Web Enrollment

. You will see the pictured dialog box stating that IIS roles will need to be added, so click on the

Add Required Role Services

button, and then click the

Next

button.

Installation Figure 2 — Select Role Services

5. You will then be asked to select the Enterprise Certification Authority that the web enrollment pages should use.

6. Click the

Browse

button, and the

Select Certification Authority

dialog box will be shown listing all the Certification Authorities in the forest.

7. Select the Certification Authority and click on the

OK

button, and click the

Next

button.

Installation Figure 3 — Select Certification Authority

8. Next you will be taken to the list of Role Services for the Web Server (IIS).

9. Add any other role services that you might need to support for the CA Web Enrollment web site like maybe enabling

Basic Authentication

keep in mind that Windows Integrated Authentication is selected by default.

10. Then click the

Next

button.

11. Lastly it will show you a confirmation screen before actually installing the web pages and IIS as shown below.

Installation Figure 4 — Confirm Installation Options

The next sections are broken down first by what the IIS Application Pool Identity runs as and then what type of Kerberos delegation you require. You can skip to the section that is relevant to your environment.

Setting up with Application Pool Identity set to Network Service

This section will cover how to configure IIS and the Active Directory accounts to support Kerberos open delegation as well as constrained delegation when the application pool identity is setup for Network Service.

Configuring for open delegation when using Network Service for AppPool Identity

1. Open up Active Directory Users and Computers (

DSA.MSC

) and double click on the IIS Computer account.

2. Click on the

Delegation

tab, and select

Trust this computer for delegation to any service (Kerberos only)

.

Network Service Delegation 1 — Configure Computer for open delegation

3. Then click OK.

4. Next we need to open

Internet Information Services (IIS) Manager

snapin.

5. Navigate to the

CertSrv

web application in the tree view, and double click on

Authentication

.

6. You should see all the supported authentication types listed.

7. Right click on

Windows Authentication

and select

Enable

if not already done.

8. Right click on

Windows Authentication

and selected

Advanced Settings…

Network Service Delegation 2 — Windows Authentication Advanced settings

9. Check

Enable Kernel-mode authentication

, and click the

OK

button.

Network Service Delegation 3 — Enable Kernel-mode Authentication

10. Reboot the IIS computer and you are ready to go.

Configuring for constrained delegation when using Network Service for AppPool Identity

If you need to support Basic Authentication on the website you will need to make sure that you configure constrained delegation with protocol transition. However, you will need to scroll down to section

Configuring the web site to support Basic Authentication

below for more steps required to support basic authentication.

1. Open up Active Directory Users and Computers and find the IIS computer account.

2. Double click on the IIS Computer account.

3. Click on the

Delegation

tab and select

Trust this computer for delegation to specified services only

4. Once the above option selected, you need to make another choice of one of the following:

a.

Use Kerberos only

(Kerberos constrained delegation).

b.

Use any authentication protocol

(Kerberos constrained delegation with protocol transition).

5. Click on the

Add…

button.

6. You now have the

Add Services

dialog box, click on the

Users or Computers…

button.

7. In the

Select Users or Computers

dialog, type in the Certification Authority computer account and click

OK

.

8. Select the following services

HOST

and

rpcss

. Once they have been selected click the OK button.

9. Once this is done it should look similar to the figure Network Service Delegation 4.

Network Service Delegation 4 — Configure Computer for constrained delegation

10. Next we need to open

Internet Information Services (IIS) Manager

snapin

11. Navigate to the

CertSrv

web application in the tree view, and double click on

Authentication

.

12. You should see all the supported authentication types listed.

13. Right click on

Windows Authentication

and select

Enable

if not already done.

14. Right click on

Windows Authentication

and selected

Advanced Settings…

Network Service Delegation 5 — Windows Authentication Advanced Settings

15. Uncheck

Enable Kernel-mode authentication

, and click the

OK

button.

Network Service Delegation 6 — Disable Kernel-mode authentication

16. Reboot the IIS computer and you are ready to go.

Setting up with Application Pool Identity set to custom account

This section will cover how to configure IIS and the Active Directory accounts to support Kerberos open delegation as well as constrained delegation when the application pool identity is setup for a custom account.

Configuring the Application Pool identity custom account

This section must be done whether you are using open or constrained delegation.

1. Next we need to open

Internet Information Services (IIS) Manager

snapin

2. Navigate to the

Application Pools

node in the tree view.

3. Select

DefaultAppPool

right click and select

Advanced Settings…

Custom Account Delegation 1 — Application Pool Advanced Settings

4. Change the Identity on the

Advanced Settings

dialog box, which then brings up the

Application Pool Identity

dialog box. Click on the

Set

… button.

5. In the

Set Credentials

dialog box, type in the domain user account to be used and password twice. Do not forget to type in the domain name. For example:

FABRIKAMIISKerbSvc

6. Click

OK

7. Click

OK

8. Click

OK

Custom Account Delegation 2 — Configure Custom account

9. Open

Active Directory Users and Computers snapin

(dsa.msc) and find the domain account that the application pool was set to from step 5.

10. Add this account the

Windows Authorization Access Group

.

11. Click OK

12. Exit Active Directory Users and Computers.

Custom Account Delegation 3 — Add Custom account to domain group

13. Open

Computer Management

snapin (compmgmt.msc) and go to the local groups in the tree view.

14. Add the account specified for the application pool identity to the

IIS_IUSRS

group

Custom Account Delegation 4 — Add Custom account to IIS_IUSRS

15. Next we need to open

Internet Information Services (IIS) Manager

snapin

16. Navigate to the

CertSrv

web application in the tree view, and double click on

Authentication

.

17. You should see all the supported authentication types listed.

18. Right click on

Windows Authentication

and select

Enable

if not already done.

19. Right click on

Windows Authentication

and selected

Advanced Settings…

Custom Account Delegation 5 — Windows Authentication Advanced Settings

20. Check

Enable Kernel-mode authentication

, and click the

OK

button.

Custom Account Delegation 6 — Enable Kernel-mode authentication

Configuring for open delegation when using custom account for AppPool Identity

1. Open up Active Directory Users and Computers and double click on the IIS Computer account.

2. Click on the

Delegation

tab, and select

Trust this computer for delegation to any service (Kerberos only)

.

Custom Account Delegation 7 — Configure Computer for open delegation

3. Then click OK.

4. Reboot the IIS computer and you are ready to go.

Configuring for constrained delegation when using custom account for AppPool Identity

If you need to support Basic Authentication on the website you will need to make sure that you configure constrained delegation with protocol transition. However, you will need to scroll down to the bottom of this blog for more steps required to support basic authentication.

1. Open up Active Directory Users and Computers and find the IIS computer account.

2. Double click on the IIS Computer account.

3. Click on the

Delegation

tab and select

Trust this computer for delegation to specified services only

, and then select

Use any authentication protocol

.

4.

Clic

k on the

Add…

button.

5. You now have the

Add Services

dialog box, click on the

Users or Computers…

button.

6. In the

Select Users or Computers

dialog, type in the Certification Authority computer account and click

OK

.

7. Select the following services

HOST

and

rpcss

. Once they have been selected click the OK button.

8. Once this is done it should look similar to the figure Custom Account Delegation 8.

Custom Account Delegation 8 — Configure Computer for constrained delegation

9. Next we need to add a Service Principal Name to the Application Pool account. This is done by using the SetSPN.exe utility. If my web site name is the IIS computer name (FAB-RT-MEM1) and I am using the account of FABRIKAMIISKerbSvc the following commands would be ran:

SetSPN –A http/fab-rt-mem1 FABRIKAMIISKerbSvc

SetSPN –A http/fab-rt-mem1.fabrikam.com FABRIKAMIISKerbSvc

10. Find the Application Pool Identity account within Active Directory Users and Computers.

11. Double click on the domain user account.

12. Click on the

Delegation

tab and select

Trust this computer for delegation to specified services only

and then select

Use any authentication protocol

.

13. Click on the

Add…

button.

14. You now have the

Add Services

dialog box, click on the

Users or Computers…

button.

15. In the

Select Users or Computers

dialog, type in the Certification Authority computer account and click

OK

.

16. Select the following services

HOST

and

rpcss

. Once they have been selected click the OK button.

17. Click on the

Add…

button.

18. You now have the

Add Services

dialog box, click on the

Users or Computers…

button.

19. In the

Select Users or Computers

dialog, type in the IIS Server computer account and click

OK

.

20. Select the following services

HOST

. Once they have been selected click the OK button.

21. Once this is done it should look similar to the figure Custom Account Delegation 9.

Custom Account Delegation 9 — Configure custom account for constrained delegation

22. Next we need to open

Internet Information Services (IIS) Manager

snapin

23. Navigate to the

CertSrv

web application in the tree view, and double click on

Authentication

.

24. You should see all the supported authentication types listed.

25. Right click on

Windows Authentication

and select

Enable

if not already done.

26. Right click on

Windows Authentication

and selected

Advanced Settings…

Custom Account Delegation 10 — Windows Authentication Advanced Settings

27. Uncheck

Enable Kernel-mode authentication

, and click the

OK

button.

Custom Account Delegation 11 — Disable Kernel-mode authentication

28. Reboot the IIS computer and you are ready to go.

Configuring the web site to support Basic Authentication

Alright, so you need to support basic authentication huh…. Well, before you do the below steps you will first want to make sure that you have followed one of the set of steps for configuring constrained delegation and selected the

Use any authentication protocol

when you setup delegation.

1. Next we need to open

Internet Information Services (IIS) Manager

snapin

2. Navigate to the

CertSrv

web application in the tree view, and double click on

Authentication

.

3. You should see all the supported authentication types listed.

4. Right click on

Basic Authentication

and select

Enable

if not already done.

5. The next part we will need to edit one of the following config files on the file system.

• %systemroot%system32certsrven-USWeb.config

You are looking for the part that is in bold below.

…

<authentication>

<

basicAuthentication enabled=»true» realm=»contoso.com» defaultLogonDomain=»CONTOSO» logonMethod=»Network»

/>

<windowsAuthentication enabled=»false» useKernelMode=»false» />

</authentication>

…

Change it from logonMethod=”Network” to logonMethod=”ClearText”

NOTE: You might not have the web.config file located here.

• %systemroot%system32inetsrvconfigapplicationHost.config

You are looking for the part in bold below, and then looking for basicAuthentication.

…

<

location path=»Default Web Site/CertSrv

«>

<system.webServer>

<handlers accessPolicy=»Read, Script»>

<clear />

<add name=»ISAPI-dll» path=»*.dll» verb=»*» modules=»IsapiModule» resourceType=»File» requireAccess=»Execute» allowPathInfo=»true» />

…

<add name=»StaticFile» path=»*» verb=»*» modules=»StaticFileModule,DefaultDocumentModule,DirectoryListingModule» resourceType=»Either» requireAccess=»Read» />

</handlers>

<security>

<authentication>

<windowsAuthentication enabled=»false»>

<providers>

<clear />

<add value=»Negotiate» />

<add value=»NTLM» />

</providers>

</windowsAuthentication>

<anonymousAuthentication enabled=»false» logonMethod=»Network»/>

<

basicAuthentication enabled=»true» logonMethod=»Network

» />

</authentication>

…

Change it from logonMethod=”Network” to logonMethod=”ClearText” for basicAuthentication section.

6. Reboot the IIS computer and you are ready to go.

The steps outlined in this blog are specifically for the CA website being loaded on Windows Server 2008 and will not translate properly to the configuration required for the website on Windows Server 2003.

The changes made to IIS7 have been drastic, from the GUI to the underlying code, so I hope that you have found this blog interesting and helpful.

— Rob Greene