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

• 1 # Термины и определения
• 2 # Инструменты
• 3 # Описание
  • 3.1 # Типы шифрования
  • 3.2 # krb5.ini
• 4 # Настройка сервера
  • 4.1 # Создание пользователя для сервера
  • 4.2 # Создание SPN
  • 4.3 # Привязка SPN к пользователю сервера
  • 4.4 # Создание keytab для SPN
  • 4.5 # Настройка kerberos.properties
  • 4.6 # Команды для выполнения по вышеперечисленным пунктам
• 5 # Настройка браузера
• 6 # Настройка оповещателя
  • 6.1 # Настройка для получения заданий
  • 6.2 # Настройка для браузера
• 7 # Типичные проблемы

# Термины и определения

# Инструменты

# Описание

Более строгое описание можно найти в интернете, например https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/.

# Типы шифрования

Выбранный тип шифрования зависит от участников взаимодействия — версии ПО домена (Windows Server), настроек домена, настроек пользователя, настроек ПО клиента.

В ранних версиях (Windows 2000, 2003) настраивали DES, в поздних (Windows 2008, 2012) рекомендуют использованием AES.

Настройки пользователя, оказывающие влияние на поведение Kerberos:

• This account supports Kerberos AES 128/256 bit encryption — разрешение использования соответствущего типа шифрования для пользователя

(TODO — при невключённых чекбоксах всё равно использовался AES128)

• Use Kerberos DES encryption for this acount — включает шифрование DES для пользователя, после установки чекбокса требуется смена пароля

# krb5.ini

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

Детальное описание файла конфигурации Kerberos

На сервере и клиентских машинах Windows он может быть расположен в ${windir}/krb5.ini.

Пример файла krb5.ini

[domain_realm]
 .test.com = TEST.COM
 test.com = TEST.COM
[libdefaults]
 default_realm = TEST.COM
 kdc_timesync = 1
 ccache_type = 4
 ticket_lifetime = 600
 default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
[logging]
 kdc = CONSOLE
[realms]
 TEST.COM = {
  kdc = 192.168.0.1
  kdc = 192.168.1.1
  default_domain = test.com
 }
[appdefaults]
 autologin = true
 forward = true
 forwardable = true
 encrypt = true

# Настройка сервера

Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).

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

# Создание пользователя для сервера

На контроллере домена нужно создать пользователя {SERVER_USER} с настройками по умолчанию.

Проверка: kinit {SERVER_USER} должен успешно получить тикет.

# Создание SPN

На контроллере домена нужно выполнить команды:

setspn -A {SERVER_SPN} {SERVER_USER}

Проверка: через ADSIEdit можно увидеть что свойство пользователя servicePrincipalName установлено либо посмотреть св-во servicePrincipalName с помощью команды Get-ADUser {SERVER_USER} -Properties *.

Если планируется использовать SPN на основании NetBIOS имени — то нужно зарегистрировать и его (https://msdn.microsoft.com/en-us/library/ms677949.aspx)

setspn -A HTTP/{SERVER_NAME} {SERVER_USER}

# Привязка SPN к пользователю сервера

На контроллере домена нужно выполнить команду:

ktpass /princ {SERVER_SPN} /mapuser {SERVER_USER} +setupn /pass *

Можно игнорировать предупреждение «WARNING: pType and account type do not match. This might cause problems».

Для обхода бага со сбросом пароля https://support.microsoft.com/en-us/kb/939980 рекомендуют вписать пароль вместо звёздочки. А если выполнить данную команду без пароля — то почему-мо возникает ошибка 24 с некорректным salt.

Проверка: в свойствах пользователя User logon name стал равен SPN либо посмотреть св-во UserPrincipalName с помощью команды Get-ADUser {SERVER_USER} -Properties *.

Проверка: kinit {SERVER_SPN} должен успешно получить тикет.

# Создание keytab для SPN

Выполнить команду из {JAVA_HOME}/bin:

ktab -a {SERVER_SPN} -n 0 -k {KEYTAB_PATH}

Проверка: kinit -k -t {KEYTAB_PATH} {SERVER_SPN} должен успешно получить тикет без запроса пароля.

Этот файл также можно получить в результате вызова команды ktpass на контроллере домена.

# Настройка kerberos.properties

Создайте файл kerberos.properties в директории {RUNAWFE_JBOSS}/standalone/wfe.custom. Замените в нем имена на настоящие.

# задействовать аутентификацию используя RunaWFE API
api.auth.enabled=true
appName=com.sun.security.jgss.krb5.accept
moduleClassName=com.sun.security.auth.module.Krb5LoginModule
principal={SERVER_SPN}
storeKey=true
useKeyTab=true
keyTab={KEYTAB_PATH}
doNotPrompt=true
# режим отладки аутентификации
debug=true
# задействовать аутентификацию по протоколу HTTP (из веб-интерфейса)
http.auth.enabled=true
jcifs.http.enableNegotiate=true
# режим отладки аутентификации
sun.security.krb5.debug=true
jcifs.spnego.servicePrincipal={SERVER_SPN}
http.auth.preference=Kerberos

# Команды для выполнения по вышеперечисленным пунктам

На контроллере домена:

setspn -A HTTP/runaserver.test.com runauser

ktpass -princ HTTP/runaserver.test.com -pass * -mapuser runauser

На сервере:

ktab -a HTTP/runaserver.test.com -n 0 -k C:/runawfe/krb5.keytab

# Настройка браузера

Для того чтобы браузер пытался использовать Kerberos для аутентификации:

• в нём должна быть включена настройка Enable Integrated Windows Authentication (в некоторых версиях IE её нет)
• настройки зоны безопасности должны позволять её использование, по умолчанию это настроено для LocalIntranet
• настройка {SERVER_SPN} должна быть корректно произведена

Во время запроса на сервере формируется в логе Request Authorization:

• Negotiate YIIV… — правильно
• Negotiate TlRMT… — неправильно (попытка использовать NTLM)

Если по нажатию на ссылке Сквозная аутентификация (kerberos) будет выведено окно с вводом логина/пароля — то это значит что браузер не получил сервисный тикет в контроллере домена или даже не пытался это сделать. При возникновении такой ситуации самым действенным оказывается использование WireShark для прослушивания траффика по порту 88 с контроллером домена.

# Настройка оповещателя

На сервере должна быть корректно настроена аутентификация.

# Настройка для получения заданий

Настроить kerberos.properties если authentication.type установлено в kerberos (для sspiKerberos это не требуется):

appName=com.sun.security.jgss.initiate
moduleClassName=com.sun.security.auth.module.Krb5LoginModule
useTicketCache=true
doNotPrompt=true
debug=true
serverPrincipal=HTTP/runaserver.test.com

# Настройка для браузера

Настройку login.relative.url установить в /krblogin.do.

# Типичные проблемы

https://technet.microsoft.com/en-us/library/bb463167.aspx

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

Разработчики 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 Configuration\Windows Settings\Security Settings\Local Policies\Security 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

November 17, 2014

AD, Oracle Database

This post describes how to configure an Oracle database for Kerberos authentication with Microsoft Windows 2008 R2 Active Directory, and how to configure the Oracle clients.

ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto all -pass Welcome9 -out c:\keytab

ldapsearch -h ad.ziontech.demo -p 389 -D "testuser1@ziontech.demo" -w "Welcome1" -b "DC=ziontech,DC=demo" -s sub servicePrincipalName=oracle/db1.ziontech.demo msDS-KeyVersionNumber

CN=db1,CN=Users,DC=ziontech,DC=demo
msDS-KeyVersionNumber=6

ktpass.exe -princ oracle/db1.ziontech.demo@ZIONTECH.DEMO -mapuser ZIONTECHDEMO\db1.ziontech.demo -crypto AES256-CTS-HMAC-SHA1-96 -pass Welcome9 -ptype KRB5_NT_PRINCIPAL -kvno 7 -out c:\keytab

SQL> select value from v$parameter where name = 'os_authent_prefix';
SQL> select value from v$parameter where name = 'remote_os_authent';

SQL> create pfile='/tmp/pfile.txt' from spfile;
SQL> shutdown immediate;

os_authent_prefix=''

SQL> sqlplus / as sysdba
SQL> create spfile from pfile='/tmp/pfile.txt';
SQL> startup

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /app/db1

SQLNET.KERBEROS5_KEYTAB=/app/kerberos/keytab
SQLNET.KERBEROS5_CONF=/app/kerberos/krb5.conf
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

[libdefaults]
default_realm = ZIONTECH.DEMO

[realms]
ZIONTECH.DEMO = {
kdc = addemo1.ziontech.demo:88
}

[domain_realm]
.ziontech.demo = ZIONTECH.DEMO
ziontech.demo = ZIONTECH.DEMO

create user "TESTUSER1@ZIONTECH.DEMO" identified externally;
grant create session to "TESTUSER1@ZIONTECH.DEMO";

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

SQLNET.KERBEROS5_CC_NAME=OSMSFT://
SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5)
SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf
SQLNET.KERBEROS5_CONF_MIT = true

SQLNET.KERBEROS5_CC_NAME=c:\kerberos\cc
SQLNET.AUTHENTICATION_SERVICES= (beq,kerberos5)
SQLNET.KERBEROS5_CONF =c:\kerberos\krb5.conf
SQLNET.KERBEROS5_CONF_MIT = true

DB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db1.ziontech.demo)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db1.ziontech.demo)
)
)

SSSD brought several authentication and authorization protocols under one roof. Despite that, it can be tricky to configure RHEL 5 and 6 systems to authenticate with SSSD using Kerberos and LDAP against an Active Directory server. This post describes the steps I took to set this up.

Repository Packages Required

Because the SSSD daemon is being used, the nss-pam-ldapd and pam_ldap packages can be removed:

yum erase nss-pam-ldapd pam_ldap

Then, install the following packages:

yum install sssd oddjob oddjob-mkhomedir

authconfig Configuration

After installing the necessary packages, authconfig needs to be configured.

First, if you’re running RHEL 5, verify the authconfig package is fully updated, otherwise the authconfig command will not have the --enablesssd command line switch:

yum update authconfig

Then, run authconfig:

authconfig --enablesssd --enablesssdauth --disableldap --disableldapauth --disablekrb5 --update

The authconfig command above will add the pam_sss.so module to the necessary lines in /etc/pam.d/system-auth on RHEL 5 and 6.

On RHEL 6, /etc/pam.d/password-auth is also updated.

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_oddjob_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

The authconfig command above will add the sss parameter to the necessary lines in /etc/nsswitch.conf on RHEL 5 and RHEL 6.

#
# /etc/nsswitch.conf
#

passwd:     files sss
shadow:     files sss
group:      files sss

hosts:      files dns

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  files
aliases:    files nisplus

SSSD Configuration File

At the time of writing, I am not aware of a process that will automatically create the /etc/sssd/sssd.conf file, so it will need to be created manually.

Create file /etc/sssd/sssd.conf and copy and paste the following contents:

[sssd]
config_file_version = 2

reconnection_retries = 3

sbus_timeout = 30
services = nss, pam

domains = EXAMPLE.COM

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/EXAMPLE.COM]
debug_level = 0
cache_credentials = False

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ad1.example.com

ldap_schema = rfc2307bis

ldap_referrals = False

ldap_search_base = dc=example,dc=com

ldap_user_search_base = cn=Users,dc=example,dc=com
ldap_user_object_class = user

ldap_group_search_base = ou=Groups,dc=example,dc=com
ldap_group_object_class = group

ldap_user_name = sAMAccountName

ldap_user_home_directory = unixHomeDirectory

ldap_user_member_of = memberOf

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = True

ldap_id_use_start_tls = False
ldap_default_bind_dn = cn=sssd,ou=Service Accounts,ou=Groups,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = $PASSWORD
ldap_tls_cacertdir = /etc/openldap/cacerts

krb5_realm = EXAMPLE.COM
krb5_canonicalize = False
krb5_server = ad1.example.com:88,ad2.example.com:88
krb5_kpasswd = ad1.example.com:88,ad2.example.com:88

Kerberos Configuration File

Open /etc/krb5.conf and copy and paste the following contents:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]

 EXAMPLE.COM = {
  kdc = ad1.example.com:88
  kdc = ad2.example.com:88
 }

[domain_realm]
 example.com = EXAMPLE.COM
 .example.com = EXAMPLE.COM

Enable and Start the SSSD Service

Finally, enable the sssd service on boot and start it:

chkconfig sssd on
service sssd restart

Test Everything

At this point, you should be able to use the id $USER command to lookup any user in Active Directory.

In addition, getent passwd $USER and getent group $GROUP can be used to lookup further user and group information in Active Directory.

Potential Problems

This is not reflected in the above configuration, but while going through the same set of steps above at a customer, I ran into login issues with SSH and GDM (i.e. logging in through the GNOME GUI) despite the SSSD configuration file being setup properly.

The issue turned out to be because of ldap_user_principal = userPrincipalName set in /etc/sssd/sssd.conf.

When I performed an ldapsearch on user1, the userPrincipalName was set to [email protected], and SSSD would authenticate that user using the Kerberos Realm EXAMPLE.COM; most Kerberos configurations I have come across have their Kerberos Realm set to the FQDN, so this wouldn’t be an issue.

However, the customer had their Kerberos Realm set to LABS.EXAMPLE.COM. Because of this, Kerberos was throwing connection issues in /var/log/messages because the Kerberos Realm EXAMPLE.COM did not exist; the actual Kerberos Realm was LABS.EXAMPLE.COM. By removing the ldap_user_principal = userPrincipalName line, SSSD used the default realm set by the krb5_realm parameter, which was LABS.EXAMPLE.COM, and the problem went away.

References

• SSSD KDC reply did not match expectations
• CentOS Authentication and Naming Services with SSSD
• Configuring sssd to authenticate with a Windows 2008 Domain Server
• Linux SSH + PAM + LDAP + SSSD+ 2008 R2 AD Deployment
• SSSD tries to resolve the users from wrong realm