Mod auth kerb windows

Почти в каждой организации используется домен Microsoft Windows, в котором пользователи проходят проверку подлинности. Так же часто в IT инфраструктуре используются сервисы, предоставляемые различными дистрибутивами linux. При выдаче прав доступа администраторам windows и linux приходится вести различные базы пользователей, что конечно не удобно. Реализовав единую базу данных пользователей и прозрачную аутентификации для пользователей (single sign on) можно избавится от массы рутинной работы и устранить риски безопасности. В данном случае реализуем прозрачный доступ пользователей к некому web ресурсу. Для аутентификации будет использоваться протокол Kerberos и «Key Distribution Center» (KDC) реализованный в контроллере домена Windows. В качестве linux системы рассматривается rhel5, для других дистрибутивов возможны не принципиальные отличия в процессе настройки. Если у вас дистрибутив отличный от указанного, то стоит проверить версию библиотеки Kerberos, она должна быть не младше чем 1.5 (MIT Kerberos), т.к. начиная с этой версии поддерживается механизм согласования метода аутентификации SPNEGO (Simple and Protected Negotiate). Веб сервер должен иметь A запись на вашем днс сервере т.к. имя ресурса является частью Kerberos билета. Процесс аутентификации описан в RFC1510, обязательно прочтите как проходит процесс аутентификации.

Термины и команды:
realm — область использующая единую базу Kerberos. По соглашению реалм записывается строчными буквами, для отличия от днс домена.
principal — имя которому поставлено в соответствие набор учетных данных. Делится на три части: 1)primary — первая чать принципала Kerberos. Если это пользователь, то соответствует его имени. Если сервис — имя сервиса. 2)instance — вторая часть, служит для уточнения первой части. Может не содержатся в имени принципала, если есть — то это описание. В случае хоста — его fqdn. 3)realm — реалм идет последней частью.
ticket — набор временных данных которые подтверждают идентичность клиента или сервиса.
TGT — Ticket-Granting Ticket. Билет дающий право на получение других билетов в реалме, где был он выпущен.
keytab — файл содержащий ключи, хост или сервис использует его точно таким же образом как пользователь использует пароль.
KDC — Key Distribution Center, сервер выдающий билеты.
kinit — программа, используется для начала процесса аутентификации принципала и получения билета TGT.
klist — программа, выводит список принципалов и Kerberos билетов содержащихся в кеше, или список список ключей в keytab файле.
kvno — получает билет для указанного принципала и выдает на терминал версию ключей.
ktutil — позволяет управлять записями в keytab файле.

Начальные условия:
локальная сеть — 192.168.1.0/24
сервер Active Directory — dc01.domain.ru(192.168.1.1)
веб сервер — web.domain.ru (192.168.1.130)

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

[root@server ~]# yum install ntpd

Выполните начальную синхронизацию времени с контроллером домена:

[root@server ~]# ntpdate dc01.domain.ru

Конфигурационный файл даемона ntpd:

[user@server ~]$ egrep -v «^#» /etc/ntp.conf
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server dc01.domain.ru
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys

Проверить состояние службы синхронизации времени можно командой:

[user@server ~]$ ntpstat
synchronised to NTP server (192.168.1.1) at stratum 5
   time correct to within 300 ms
   polling server every 512 s

Настройка Kerberos на web.domain.ru.
Ниже приведена минимальная конфигурация для использования протокола аутентификации в реалме domain.ru. Реалм в данном случае будет совпадает с доменом Windows. Обратите внимание, для работоспособности Kerberos, реалм должен быть написан прописными буквами!

[user@server ~]$ cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = DOMAIN.RU
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 DOMAIN.RU = {
  kdc = dc01.domain.ru
  admin_server = dc01.domain.ru
 }

[domain_realm]
 .domain.ru = DOMAIN.RU
 domain.ru = DOMAIN.RU

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Если у вас в сети несколько контроллеров домена то вы можете их перечислить в секции [realms], что то вроде:

[realms]
 DOMAIN.RU = {
  kdc = dc01.domain.ru
  kdc = dc02.domain.ru
  admin_server = dc01.domain.ru
  admin_server = dc02.domain.ru
 }

Проверить работоспособность Kerberos можно с помощью kinit, и учетной записи в домене Windows. Данная команда позволяет для принципала (в данном случае для пользователя домена) получить TGT билет и поместить его в кеш. Содержимое кеша можно посмотреть командой klist:

[user@server ~]$ kinit domain_user@DOMAIN.RU
[user@server ~]$ klist

Ticket cache: FILE:/tmp/krb5cc_500
Default principal: domain_user@DOMAIN.RU

Valid starting     Expires            Service principal
03/22/11 17:43:35  03/23/11 03:43:38  krbtgt/DOMAIN.RU@DOMAIN.RU
renew until 03/23/11 17:43:35

Далее нам нужно создать аккунт сервера в в Active Directory и связать его с принципалом сервиса  в KDC. Можно сделать это самостоятельно на котроллере домена. Создать сначала аккаунт, а затем связать его с принципалом с помощью команды ktpass. Но мне больше нравится вариант с установкой samba и вводом сервера в домен, в этом случае аккаунт и принципал службы создаются автоматически. Как плюс, samba позволит нам в будущем организовать сетевые ресурсы и получать информацию из AD для разграничения доступа к службам сервера.

Настройка samba, добавление сервера web.domain.ru в домен Windows
Устанавливаем samba:

[root@server ~]# yum install samba

В конфигурации samba необходимо указать используемый реалм, указать что будет используется keytab файл, и указать что самба работает как член домена AD — параметр security=ads. Конфигурация samba достаточная для наших целей приведена ниже:

[root@server ~]# cat /etc/samba/smb.conf
[global]
workgroup = DOMAIN
realm = DOMAIN.RU
server string = Samba Server Version %v
security = ADS
passdb backend = tdbsam
 use kerberos keytab = Yes
local master = No
cups options = raw

Проверить правильность конфигурационного файла можно командой 

[root@server ~]# testparm

Если ошибок нет, то самое время добавить наш сервер в домен Windows, естественно что нужно это делать имея полномочия на добавление в домен:

[root@server ~]# net ads join -U win_admin

win_admin’s password:
Using short domain name — DOMAIN
Joined ‘WEB’ to realm ‘DOMAIN.RU’

Если днс зона на контроллере домена не обновилась, то можно или вручную добавить запись A типа и ассоциированную с ней запись PTR или попытатся провести регистрацию имя сервера в днс следующим образом:

[root@server ~]# net ads dns register -I 192.168.1.130 -U win_admin

Проверить корректность добавления сервера в домен можно следующим образом:

[root@server ~]# net ads testjoin
Join is OK

Создание файла keytab, добавление ключа принципала сервиса «HTTP» в keytab.
Создадим keytab файл. Так как в конфигурации samba не оговорено где должен содержатся keytab файл, то будет создан файл по умолчанию /etc/krb5.keytab:

[root@server ~]# net ads keytab create -U win_admin

Теперь создадим и добавим принципал для сервиса — «HTTP», Если вы сейчас посмотрите, на контроллере домена, через консоль MMC и остнастку ADCI Edit параметр «servicePrincipalName», какие принципалы сервисов созданы для нашего сервера — это будут: «HOST/web.domain.ru» и «HOST/web».

[root@server ~]# net ads keytab add HTTP -U win_admin

Если вы теперь посмотрите в список принципалов, то заметите, что там добавились еще два — «HTTP/web.domain.ru» и «HTTP/web». В принципе это уже значит что добавление прошло успешно. Тем не менее, давайте посмотрим что сейчас находится в keytab:

[root@server ~]# klist -ek /etc/krb5.keytab 
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
—- —————————————————————————
   2 host/web.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 host/web.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 host/web.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 host/web@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 host/web@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 host/web@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 WEB$@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 WEB$@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 WEB$@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 HTTP/web.domain.ru@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 HTTP/web.domain.ru@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 HTTP/web.domain.ru@DOMAIN.RU (ArcFour with HMAC/md5) 
   2 HTTP/web@DOMAIN.RU (DES cbc mode with CRC-32) 
   2 HTTP/web@DOMAIN.RU (DES cbc mode with RSA-MD5) 
   2 HTTP/web@DOMAIN.RU (ArcFour with HMAC/md5) 

Для полной уверенности можно получить Kerberos билет от KDC для только что заведенных принципалов:

[root@server ~]# kvno HTTP/web.domain.ru@DOMAIN.RU HTTP/web@DOMAIN.RU

HTTP/web.domain.ru@DOMAIN.RU: kvno = 2
HTTP/web@DOMAIN.RU: kvno = 2

Обратите внимание, что версия ключа идентична. Посмотрим эти билеты подробнее (в выводе только интересующие нас билеты):

[root@server ~]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: domain_user@DOMAIN.RU

Valid starting     Expires            Service principal
03/25/11 15:37:04  03/26/11 01:35:17  HTTP/web.domain.ru@DOMAIN.RU
renew until 03/26/11 15:35:14, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 
03/25/11 15:42:26  03/26/11 01:35:17  HTTP/web@DOMAIN.RU
renew until 03/26/11 15:35:14, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

Обратите внимание что номера ключей билетов (колонка KVNO), имя принципала в билете и алгоритмы шифрования должны совпадать! Рекомендуется создать свой keytab для службы HTTP, где будет содержатся только нобходимые нам ключи. Сделать это можно с помощью ktutil. Расширеных функций редактирования он не поддерживает, поэтому его можно запустить через rlwrap:

[root@server ~]# rlwrap ktutil

Загрузим содержимое keytab

ktutil:  read_kt /etc/krb5.keytab

Посмотрите текущие записи:

ktutil:  list

Нас интересуют записи в которых фигурирует метка «HTTP». Удалите все лишние записи, указав в команде удаления ненужный слот записи:

ktutil:  delent 1

Должно получится так:

ktutil:  list
slot KVNO Principal
—- —- ———————————————————————
   1    2                  HTTP/web.domain.ru@DOMAIN.RU
   2    2                  HTTP/web.domain.ru@DOMAIN.RU
   3    2                  HTTP/web.domain.ru@DOMAIN.RU

Сохраним оставшиеся в другой keytab файл:

ktutil:  write_kt /etc/httpd/httpd.keytab

Сменим права доступа:

[root@server ~]# chown apache:apache /etc/httpd/httpd.keytab
[root@server ~]# chmod 0440 /etc/httpd/httpd.keytab

Переходим к заключительной части.

Установка и настройка mod_auth_kerb.
Установим модуль mod_auth_kerb:

[root@server ~]# yum install mod_auth_kerb

Вы обнаружите файл /etc/httpd/conf.d/auth_kerb.conf содержащий пример настройки mod_auth_kerb. Воспользуемся этим примером как отправной точкой. В примере ниже примере аутентификация требуется только к части сайта web.domain.ru/private. Параметр KrbServiceName должен содержать имя принципала сервиса (и соответственно ключ), которое будет использовать apache для аутентификации. На место расположения файла keytab указывает параметр Krb5KeyTab. Используйте SSL если вы включите параметр KrbMethodK5Passwd. Данный параметр  включает аутентификацию с поддержкой ввода логин/пароль, причем они будут посланы по сети практически чистым текстом ( кодировка Base64 очень слабая )

[root@snort conf.d]# cat /etc/httpd/conf.d/auth_kerb.conf

Такой вариант настройки не очень удобен в плане гибкости. Гораздо удобнее настроить аутентификацию в .htaccess файле. Прежде чем будете пробовать второй пример — приведите к первоначальному виду файл /etc/httpd/conf.d/auth_kerb.conf, т.е. все закоментированно кроме строчки с загрузкой модуля.

[root@snort ~]# cat /var/www/html/.htaccess
#SSLRequireSSL
AuthType Kerberos
AuthName «Kerberos Login»
KrbMethodNegotiate On
KrbMethodK5Passwd Off
KrbAuthRealms DOMAIN.RU
Krb5KeyTab /etc/httpd/httpd.keytab
KrbServiceName HTTP
#require user win_user@DOMAIN.RU win2_user@DOMAIN.RU
require valid-user

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

Настройка интернет браузеров.
Начнем с internet explorer 8. Во вкладке «Безопасность» окна «Свойства обозревателя» выделите «Местная интрасеть» и нажмите на «Узлы».

Картинка с сайта: val-khmyrov.blogspot.com

В появившемся окне нажмите «Дополнительно»

Картинка с сайта: val-khmyrov.blogspot.com

Впишите свой домен как на примере:

Закройте окно, и нажмите на кнопку «Другой» в области «Уровень безопасности для этой зоны». Отметьте параметр автоматического входа в систему как показано на рисунке.

Картинка с сайта: val-khmyrov.blogspot.com

Теперь в окне «Свойства обозревателя» перейдите во вкладку «Дополнительно», и включите параметр «Разрешить встроенную проверку подлинности Windows». Для того что бы настройки вступили в силу, браузер необходимо перезапустить.

Картинка с сайта: val-khmyrov.blogspot.com

Перейдем к настройке Mozilla Firefox, здесь все проще и без перезапусков. Наберите в адресной строке «about:config», в строке фильтра — «network.neg». Впишите свой домен в две строки, как показано на рисунке.

Картинка с сайта: val-khmyrov.blogspot.com

In this post I am going to explain a rather unusual setup which we have implemented for a customer lately: Apache Single Sign On using Active Directory Server. This is not so unusual. The exceptional requirement is Apache running on a Windows Server not on a Linux Server.

For Apache on Windows there is no precompiled Kerberos module available. So we compiled it. Read on to find out how we configured the whole setup.

Please leave a comment on this page and tell us what you think. If we can be of any help let us know!

The Environment

• Windows Server, Active Directory Server (ADS)
  in this document I will refer to this server as ADS.your.domain@your.domain
• Windows Server, Apache 2.2
  in this document I will refer to this server as APACHE.your.domain@your.domain
• Windows Client, e.g Windows 7

When I write your.domain, then replace it with the domain name your ADS is configured for.
When I write YOUR.DOMAIN, replace it with your domain name all in caps.

Create technical Users in ADS

• User „apachekerb“ is used by Apache when authenticating users against ADS using the Kerberos protocol.
• User „apacheldap“ is used by Apache for LDAP queries.

When creating these users in ADS make sure „User must change password at next logon“ is unchecked and „Password never expires“ is checked.
Pick a password for both users. In this example I use „zx890as$%^“ for both.

Create Group in ADS

Create ADS group „ApacheSSOAccess“. Add users which may access the Web Server.

Create test Users in ADS

To test the configuration I create two user accounts. One that will be granted access and one that will be denied access:

• „ssotestgranted@your.domain“ in group „ApacheSSOAccess“
• „ssotestdenied@your.domain“ not in the group

Create a Kerberos token

Apache needs an access code for accessing the ADS. Execute the following command on the ADS host in a cmd shell. Please be sure to replace APACHE.your.domain@your.domain with the name of the server Apache is installed on!

ktpass -princ HTTP/APACHE.your.domain@your.domain
       -mapuser apachekerb -crypto rc4-hmac-nt
       -ptype KRB5_NT_PRINCIPAL -pass zx890as$%^
       -out c:\apache.keytab

Later I will copy c:\apache.keytab to the Apache Server.

1. Install apache 2.2

Get Apache 2.2 installer from here.
Note you must use Apache 2.2 from the specified source as our mod_auth_kerb
is specifically built for this version. Download it here.

2. Install MIT Kerberos for Windows 4.0.1

Get the MIT Kerberos installer from here.

Choose installation type „Typical“.
Install location is C:\Program Files (x86)\MIT\Kerberos

3. Configure MIT Kerberos

Add to empty file C:\ProgramData\MIT\Kerberos5\krb.ini

[libdefaults]
                debug=true
                default_realm = YOUR.DOMAIN
                dns_lookup_kdc = false
                krb4_config = /etc/krb.conf
                krb4_realms = /etc/krb.realms
                kdc_timesync = 1
                ccache_type = 4
                forwardable = true
                proxiable = true

[realms]
                YOUR.DOMAIN = {
                        kdc = ADS.your.domain
                        admin_server = ADS.your.domain
                        default_domain = your.domain
                }

[domain_realm]
                .your.domain = YOUR.DOMAIN

[login]
                krb4_convert = true
                krb4_get_tickets = false

4. Copy apache.keytab into Apache2.2 conf directory

Now I copy the „apache.keytab“ file from the ADS to the Apache Server. The file needs to end up in „APACHE_HOME\conf\apache.keytab“.

5. Create authsso\index.php in document root

This folder is used to test SSO and authorization.

File: <APACHE DOCUMENT ROOT>\authsso\index.php
Content:

        <html>
         <head>
          <meta http-equiv="Pragma" content="no-cache" />
         </head>
         <body>
          <h1>Authenticated!</h1>
          REMOTE_USER: <?php echo $_SERVER["REMOTE_USER"]; ?></br>
          PHP_AUTH_USER: <?php echo $_SERVER["PHP_AUTH_USER"]; ?></br>
         </body>
        </html>

6. Copy Module mod_auth_kerb.so into Apache modules directory

From: C:\Users\Public\Downloads\mod_auth_kerb.so
To: \modules\mod_auth_kerb.so

Source: Schäuffelhut Berger GmbH

7. Update Apache Config

File: \conf\httpd.conf

Enable modules needed for authorization and authentication:

       LoadModule auth_kerb_module modules/mod_auth_kerb.so
       LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
       LoadModule authz_default_module modules/mod_authz_default.so

Append at the end of httpd.conf:

       # http://shib.ametsoc.org/manual/mod/mod_ldap.html
       # cache ldap results for 60 seconds
       LDAPCacheTTL   60
       LDAPOpCacheTTL 60

        <Location /authsso>
           AuthType KerberosV5
           AuthName "Kerberos Login"
           KrbAuthRealm your.domain
           KrbServiceName HTTP/APACHE.your.domain@your.domain

           # on windows Krb5Keytab only works for absolute paths!
           Krb5Keytab "<APACHE INSTALL DIR>\conf\apache.keytab"

           KrbMethodK5Passwd on
           KrbMethodNegotiate on

           AuthzLDAPAuthoritative on

           # find LDAP user by Kerberos userPrincipalName.
           AuthLDAPURL "ldap://ADS.your.domain/DC=your,DC=domain?userPrincipalName"

           # use Common Name as displayed in ADS
           AuthLDAPBindDN "cn=apacheldap,DC=your,DC=domain"
           AuthLDAPBindPassword "zx890as$%^"

           # use Common Name as displayed in ADS
           # no quotes around GROUP!
           Require ldap-group CN=ApacheSSOAccess,DC=your,DC=domain

           Satisfy All
        </Location>

8. Users that may access /authsso must be set up like ssotestgranted@your.domain

Account name must match „User Principal Name“ for LDAP lookup to succeed.
Account must be member of ldap-group ApacheSSOAccess

Conclusion

Getting this setup to work was a challenge but it was an interesting experience. I hope this blog post will help you. Please leave a comment if you have any suggestions or questions.