Настройка kerberos windows server 2003
Статья будет разбита на несколько этапов.
1) Установка времени и временной зоны.
Этот этап один из самых лёгких и самых важных. Если время будет отличаться больше, чем на 5 минут (значение по дефолту), то вы не сможете ни получить билет от kerberos, ни ввести комп в домен. Поэтому, ставим и настраиваем ntp.
Потом настроил синхронизацию времени с локального ntp-сервера (в файле /etc/ntp.conf)
прописал зону (в /etc/conf.d/clock)
CLOCK="UTC"
TIMEZONE="Europe/Kiev"
CLOCK_SYSTOHC="yes"
потом выполнил команду
и запустил сервис:
После этого сихронизировалось время. Добавил в автозагрузку скрипт ntp-client (делается это командой rc-update add ntp-client default)
2) Установка hostname и прочих hosts
Обязательно пропишите в /etc/hosts имя компа с доменным суффиксом
127.0.0.1 gentoo.domain.local localhost gentoo
3) Установка и настройка Kerberos
Ставим пакет app-crypt/mit-krb5. На этом этапе могут возникнуть проблемы:
These are the packages that would be merged, in order:
Calculating dependencies. done!
dev-util/pkgconfig-0.23 USE="-hardened" 1,009 kB
sys-devel/bc-1.06.95 USE="readline -libedit -static" 284 kB
sys-libs/e2fsprogs-libs-1.41.3-r1 USE="nls" 479 kB
app-crypt/mit-krb5-1.6.3-r6 USE="-doc -krb4" 11,636 kB
sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1)
sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.3-r1)
Total: 4 packages (4 new), Size of downloads: 13,406 kB
Conflict: 3 blocks (3 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
('ebuild', '/', 'sys-libs/e2fsprogs-libs-1.41.3-r1', 'merge') pulled in by
>=sys-libs/e2fsprogs-libs-1.41.0 required by ('ebuild', '/', 'app-crypt/mit-krb5-1.6.3-r6', 'merge')
('installed', '/', 'sys-fs/e2fsprogs-1.40.8', 'nomerge') pulled in by
sys-fs/e2fsprogs required by system
sys-fs/e2fsprogs required by world
>=sys-fs/e2fsprogs-1.34 required by ('installed', '/', 'sys-apps/util-linux-2.13.1.1', 'nomerge')
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
Ну что ж, подчиняемся и выполняем всё, что требует (перед этим пересобрал wget без поддержкиssl):
После этого можно ставить mit-krb5:
Перехожу к настройке ( ОЧЕНЬ ВАЖНО, ЧТО БЫ ИМЕНА ШЛИ В ВЕРХНЕМ РЕГИСТРЕ ):
Файл /etc/krb5.conf
[libdefaults]
default_realm = DOMAIN.LOCAL
ticket_lifetime = 24000
dns_lookup_realm = false
dns_lookup_kdc = false
clockskew = 600
[realms]
DOMAIN.LOCAL = admin_server = 10.0.3.188
default_domain = DOMAIN.LOCAL
kdc = 10.0.3.188
kdc = 10.0.3.186
>
[domain_realm]
.domain.local = DOMAIN.LOCAL
domain.local = DOMAIN.LOCAL
[logging]
default = FILE:/var/log/kerberos/krb5libs.log
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmind.log
[appdefaults]
pam = debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
>
[kdc]
profile = /etc/kdc.conf
[login]
krb4_convert = false
krb4_get_tickets = false
Файл /etc/kdc.conf
[kdcdefaults]
kdc_ports = 750,88
Теперь начиается самое важное и интересное! Создание ключей и базы kerberos.
Создаем принципиалы и ключи.
Для начала следует создать новую базу данных и наполнить ее принципиалами. Здесь возможно несколько вариантов, один из них вызов kadmin с ключом –l. Можно использовать специальные утилиты.
$ sudo kdb5_util create -s
Loading random data
Initializing database ‘/var/lib/krb5kdc/principal’ for realm ‘DOMAIN.LOCAL’,
master key name ‘K/[email protected]’
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Новая база создана (у меня создалась в каталоге /var/lib/krb5kdc). Утилита попросит ввести пароль, не забудьте его. Создадим принципиал, который потребуется для административных целей:
$ sudo kadmin.local -q “addprinc admin/admin”
Authenticating as principal root/[email protected] with password.
Enter password for principal “admin/[email protected]”:
Re-enter password for principal “admin/[email protected]”:
Principal “admin/[email protected]” created.
Authenticating as principal root/[email protected] with password.
Enter password for principal “admin/[email protected]”:
Re-enter password for principal “admin/[email protected]”:
Principal “admin/[email protected]” created.
Для добавления принципиалов для KDC, admin сервера, своего компьютера , пользователей воспользуемся интерактивным режимом работы:
$ sudo kadmin.local -p admin/admin
Authenticating as principal admin/admin with password.
зарегистрировались использовав принципиал администратора, создаем принципиал компьютера, так как компьютер не будет вводить пароль, используем случайный пароль:
kadmin.local: addprinc -randkey host/domain.local
Principal “host/[email protected]” created.
kadmin.local: addprinc gentoo
Enter password for principal “[email protected]”:
Re-enter password for principal “[email protected]”:
Principal “[email protected]” created.
добавим принципиал компьютера в файл keytab в котором хранятся собственные принципиалы
kadmin.local: ktadd host/domain.local
Entry for principal host/domain.local with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/domain.local with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
Теперь запускаем сервисы kerberos и kerberos-admin:
/etc/init.d/mit-krb5kdc start
/etc/init.d/mit-krb5kadmind start
Теперь пробуем получить бителик kerberos (используя доменную учётку, обладающую правами администратора):
После установки приводим конфиг в такой вид:
workgroup = DOMLOC
netbios name = gentoo
server string = Samba Server %v
printcap name = /dev/null
load printers = no
printing = no
log file = /var/log/samba/log.%m
max log size = 50
log level = 3
map to guest = bad user
security = ads
password server = 10.0.3.188 10.0.3.186
encrypt passwords = yes
unix password sync = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*UNIX*password* %n
*Re*ype*new*UNIX*password* %n
*passwd:*all*authentication*tokens*updated*successfully*
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = no
os level = 33
domain master = no
preferred master = no
dns proxy = no
username map = /etc/samba/smbusers
default case = lower
case sensitive = no
dos charset = cp866
unix charset = utf-8
allow trusted domains = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind separator = /
winbind use default domain = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum groups = yes
winbind enum users = yes
realm = DOMAIN.LOCAL
client ntlmv2 auth = yes
auth methods = winbind
inherit acls = Yes
map acl inherit = Yes
nt acl support = yes
inherit permissions = yes
inherit owner = yes
admin users = @DOMLOC//admins
passdb backend = tdbsam
template shell = /bin/bash
valid users = @DOMLOC//admins @DOMLOC//managers
writable = yes
path = /share/test1
valid users = @DOMLOC//admins
writable = yes
path = /share/qw
5) Вводим машину в домен.
Посмотрел, а у меня не запущен winbind-демон. Ну что, погуглив, почитав, открыл файл/etc/conf.d/samba, увидел такую строчку:
Ну что ж, делаем так, как написано:
daemon_list="smbd nmbd winbind"
Теперь перезапускаем самбу и проверяем, запущен ли winbind:
Вот теперь проверим всё ли у нас впорядке:
Что бы юзеры могли авторизироваться через домен, нужно указать, что используется авторизацияwinbind. Редактируем файл /etc/nsswitch.conf (добавляем слово winbind):
passwd: compat winbind
shadow: compat winbind
group: compat winbind
Тестируем:
getent group
root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root,adm
lp::7:lp
mem::8:
kmem::9:
wheel::10:root
floppy::11:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:man
console::17:
audio::18:
cdrom::19:
dialout::20:root
tape::26:root
video::27:root
cdrw::80:
usb::85:
users::100:games
nofiles:x:200:
smmsp:x:209:smmsp
portage::250:portage
utmp:x:406:
nogroup::65533:
nobody::65534:
sshd:x:22:
skeletor:x:1000:
ssmtp:x:1001:
ldap:x:439:
lpadmin:x:106:
ntp:x:123:
helpservicesgroup:x:10002:support_388945a0
telnetclients:x:10003:
managers:x:10016:manager1,manager2,manager3,manager4,manager6
Меняем дефолтную систему PAM-авторизации:
/dev/sdb1 /share ext3 noatime,acl,bsdgroups 0 1
Перегружаем тачку, что бы изменения вступили в силу (в частности PAM-авторизации).
После перезагрузки нужно заново получить билет от kerberos:
Перечитываем конфиг ssh и пробуем зайти:
Если юзер первый раз заходит на сервак, то для него создасться домешняя папка :
login as: jonny
Using keyboard-interactive authentication.
Password:
Creating directory '/home/059DOM/jonny'.
Creating directory '/home/059DOM/jonny/.ssh'.
jonny@gentoo
Далее можно добавить группу admins в /etc/sudoers, что бы можно было выполнять рутовые команды. Вообщем, можно где разбежаться.
PS
Отдельное внимание хочу уделить возможности использования ACL. У меня так и не получилось нормально их юзать. Пробую из консоли назначить права, вылетает с ошибкой:
Существует довольно распространенный миф, что платформа Windows является незащищенной по своей природе. Это принципиально неверно. Windows Server 2003 - одна из наиболее защищенных операционных систем. Она основывается на системе безопасности Windows 2000 и расширяет ее. Windows Server 2003 можно сделать защищенной на любом требуемом уровне (если администратор знает, как это сделать). В этой лекции описываются некоторые средства и процессы, используемые для защиты вашего сервера.
Аутентификация Windows Server 2003
Аутентификация - это проверка того, что данное лицо соответствует опознавательным данным, которые он предъявляет; тем самым, аутентификация является основным компонентом системы безопасности Windows Server 2003. Она подтверждает опознавательные данные (" личность ") пользователя, который хочет выполнить вход на компьютер , в сеть или в домен . Используя Active Directory , Windows Server 2003 поддерживает единый вход для доступа ко всем сетевым ресурсам. Это позволяет пользователю выполнять вход в домен с помощью единственного пароля или смарт-карты и аутентифицироваться для любого ресурса в домене.
Windows Server 2003 поддерживает два основных протокола для аутентификации.
- Kerberos V5.Используемый по умолчанию протокол аутентификации для серверов Windows 2000, Windows XP и Windows Server 2003, если они являются членами домена Active Directory. Его можно использовать для интерактивного входа по паролю или смарт-карте.
- NTLM.Поддерживается для совместимости с Windows 95, Windows 98, Windows Me и Windows NT 4, которые используют NTLM для подсоединения к сети. Компьютеры, работающие с Windows Server 2003, используют NTLM при подсоединении или доступе к ресурсам в домене Windows NT 4.
Аутентификация NTLM
Операционные системы Microsoft Windows 9x и Windows NT не могут использовать Kerberos, поэтому они используют NTLM для аутентификации в домене Windows Server 2003. В защите NTLM имеются "слабые места", которые позволяют специалистам по взлому паролей дешифровать NTLM -аутентификацию. Чтобы воспрепятствовать этому, Microsoft разработала NTLM версии 2. Клиенты и серверы Windows 2000, а также Windows XP будут продолжать аутентифицироваться на контроллерах доменов Windows Server 2003 с помощью Kerberos независимо от того, что используется, - NTLM или NTLMv2.
Аутентификация NTLM для telnet
Для клиента telnet (сетевого теледоступа) в Windows 2000 добавлена поддержка аутентификации NTLM . Это позволяет клиенту telnet в Windows 2000 или Windows Server 2003 выполнять вход на сервер telnet Windows Server 2003 с помощью аутентификации NTLM . Для доступа к серверу telnet пользователи могут использовать свое локальное пользовательское имя и пароль Windows 2000 или информацию доменной учетной записи. Если аутентификация NTLM не используется, то пользовательское имя и пароль передаются на сервер telnet в виде нешифрованного текста. В результате эти данные могут быть перехвачены злоумышленником в сети. При аутентификации NTLM клиент использует для аутентификации средства безопасности Windows Server 2003, и у пользователя не запрашиваются пользовательское имя и пароль. Пользовательское имя и пароль передаются на сервер в шифрованном виде. После аутентификации все команды передаются в виде нешифрованного текста.
Примечание. Microsoft Terminal Server является более защищенной по сравнению с telnet. Terminal Server можно блокировать, используя в основном те же процессы, что используются для усиления защиты серверов Windows.Обзор Kerberos
Протокол аутентификации Kerberos обеспечивает взаимную защиту между клиентами и серверами, а также между серверами. Когда пользователь выполняет вход, используя пользовательское имя/пароль или смарт-карту, компьютер находит сервер Active Directory и службу аутентификации Kerberos. Затем Kerberos выдает так называемые билеты ( ticket ), чтобы разрешить доступ к сетевым службам. Эти билеты содержат шифрованные данные, включая шифрованный пароль, подтверждающий опознавательные данные пользователя для этой службы.
Главным компонентом Kerberos является Центр распространения ключей ( KDC - Key Distribution Center). KDC запускается на каждом контроллере домена как часть Active Directory и используется для хранения паролей и информации учетных записей клиентов. Windows Server 2003 реализует KDC как доменную службу и использует Active Directory домена как ее базу данных с информацией учетных записей. В процесс аутентификации Kerberos входят следующие шаги.
- Пользователь на клиентском компьютере аутентифицируется для KDC с помощью пароля или смарт-карты.
- KDC выдает клиенту специальный билет, позволяющий получить билет (TGT - Ticket-granting ticket ), чтобы разрешить ему доступ к предоставляющей билеты службе ( TGS - Ticket -granting service) на контроллере домена.
- TGS выдает клиенту билет на обслуживание.
- Этот билет подтверждает опознавательные данные пользователя для службы и опознавательные данные службы для пользователя.
Реализация Kerberos в Windows Server 2003
По умолчанию Kerberos обладает свойствами прозрачности и защищенности в Windows Server 2003. Это освобождает вас от необходимости знать, каким образом реализован Kerberos.
Примечание. Администраторам домена или предприятия не следует вносить изменения в реализацию Kerberos по умолчанию без ясного понимания цели этих изменений, а также их влияния на домен. После внесения изменений на одном контроллере домена настройки реплицируются на все остальные контроллеры домена. Любые изменения политики Kerberos окажут влияние на все компьютеры домена.Если вам необходимо внести изменения в политику Kerberos, выполните следующие шаги.
- Откройте оснастку Active Directory Users and Computers.
- В дереве консоли щелкните правой кнопкой на данном домене.
- Выберите пункт Properties (Свойства) и затем щелкните на вкладке Group Policy (Групповая политика).
- Щелкните на кнопке Edit.
- В дереве консоли щелкните на Kerberos Policy (в последовательности Computer Configuration/ Windows Settings/Security Settings/ Account Policies /Kerberos Policy).
- Дважды щелкните на политике Kerberos, которую хотите модифицировать.
- Внесите изменения в эту политику и затем щелкните на кнопке OK.
Имеется несколько относящихся к Kerberos политик, которые можно модифицировать, если это крайне необходимо.
- Enforce User Login Restrictions. Указывает, что KDC должен проверять наличие у пользователя права "Log on locally" (Локальный вход) или "Access this computer from the Network" (Доступ к данному компьютеру из сети). Если пользователь не имеет одного из этих прав, то билет на обслуживание не выдается. Эта политика включена по умолчанию.
- Maximum Lifetime That a User Ticket Can Be Renewed.Задает максимальный срок действия билета TGT или сеансового библиотека. По умолчанию 7 дней.
- Maximum Service Ticket Lifetime.Задает количество минут, в течение которых действителен билет на обслуживание. Это должно быть значение от 10 минут до времени, заданного в политике "Maximum User Ticket Lifetime". По умолчанию 600 минут.
- Maximum Tolerance for Synchronization of Computer Clocks. Задает максимально допустимое отличие в минутах между таймерами компьютера-сервера KDC и клиентского компьютера. Таймеры этих машин должны быть синхронизированы с максимально возможной точностью. По умолчанию 5 минут.
- Maximum User Ticket Lifetime. Задает количество часов, в течение которых действителен билет Kerberos TGT. По истечении этого времени должен быть получен новый билет или обновлен старый. По умолчанию 10 минут.
Имеется также небольшое число других опций Kerberos. Для доступа к этим опциям нужно выбрать пользователя в окне Active Directory Users and Computers и щелкнуть на Properties.
Хотя Kerberos существенно повышает защищенность по сравнению с прежними протоколами аутентификации, его безопасность в целом все еще основывается на пароле пользователя. В результате слабая политика паролей может обесценить все преимущества Kerberos. Один из способов разрешения данной проблемы - это использование смарт-карт.
Реализация смарт-карт
Windows Server 2003, как и Windows 2000, поддерживает использование смарт-карт для входа. На смарт-карте могут храниться сертификат пользователя и личный ключ , поэтому он может выполнять вход, установив эту карту в устройство чтения смарт-карт. После этого компьютер запрашивает у пользователя его личный идентификационный номер (PIN-код), чтобы разрешить этому пользователю вход в систему. Смарт-карты дают следующие преимущества по сравнению с паролями.
- Отпадает вопрос слабости использования пароля в Kerberos. Смарт-карты обеспечивают более сильную аутентификацию , чем пароли, поскольку для них используются шифрованные идентификационные данные.
- Требуется, чтобы пользователь лично установил смарт-карту для аутентификации в домене.
- Смарт-карта может быть блокирована после определенного числа неудачных попыток ввода PIN-кода. Это может воспрепятствовать словарным и "лобовым" атакам на смарт-карту.
Windows Server 2003 использует несколько политик, чтобы определить вход в систему с помощью смарт-карт. Политика Smart Card Is Required for Interactive Logon требует использования смарт-карты для интерактивного входа в систему. Если задана эта политика, то пользователь не может использовать пароль для входа по учетной записи. Эта политика касается только интерактивных и сетевых входов, но не входов удаленного доступа, для которых используется другая политика. Смарт-карты особенно рекомендуются для наиболее важных учетных записей, например, учетных записей Administrator. Политику Smart Card Is Required for Interactive Logon не следует использовать, если пользователь должен указать пользовательское имя, пароль и имя домена для доступа к сетевым ресурсам.
Инфраструктура открытых ключей и аутентификация Windows Server 2003
Windows Server 2003 использует сертификаты для разнообразных функций, таких как аутентификация по смарт-карте, аутентификация на веб-сервере, защищенная электронная почта, безопасность IP (Internet Protocol) и подписание кода ( code signing ). Сертификат - это цифровой документ, выданный каким-либо ответственным органом для подтверждения идентификационных данных обладателя сертификата. Он связывает открытый ключ (public key) с пользователем, компьютером или службой, которые владеют соответствующим личным ключом (private key). В сертификат обычно включается информация о пользователе или компьютере, которому выдан этот сертификат, информация о самом сертификате и (обычно) о так называемом Центре сертификации (ЦС) (Certificate authority [CA]), который выдал сертификат. Сертификаты обычно содержат следующую информацию.
- Открытый ключ пользователя.
- Часть идентифицирующей информации о пользователе, например, его имя и адрес электронной почты.
- Срок действия этого сертификата.
- Информация о поставщике этого сертификата.
- Цифровая подпись поставщика, которая связывает открытый ключ пользователя и его уникальную идентифицирующую информацию.
Обычно сертификаты действуют только в течение указанного периода времени, который тоже включается в сертификат. По истечении периода действия сертификата пользователи должны запрашивать новый сертификат. При использовании сертификатов Windows Server 2003 доверяет тому, что поставщик сертификата удостоверил идентификационные данные пользователя сертификата . Сервер обозначает поставщика сертификатов как доверяемый корневой ЦС, помещая сертификат этого поставщика, подписанный его собственной подписью, в хранилище сертификатов доверяемых корневых ЦС на хост-компьютере. Для управления этими ЦС в Windows Server 2003 используется служба Certificate Services. Таким образом, ЦС несет ответственность за создание и удостоверение идентификационных данных обладателей сертификатов. Вы можете управлять службой Certificate Services с помощью консоли MMC Certification Authority (Центр сертификации).
Шаблоны сертификатов
Шаблон сертификата - это набор правил и настроек, которые применяются к запросам сертификатов. Для каждого типа сертификатов должен быть сконфигурирован шаблон сертификата. Шаблоны сертификатов можно настраивать в центрах сертификации (ЦС) предприятий Windows Server 2003, и они хранятся в Active Directory для использования всеми ЦС в домене. Это позволяет вам выбрать шаблон по умолчанию или модифицировать существующие шаблоны, чтобы создавать настраиваемые шаблоны. В Windows Server 2003 имеется несколько типов шаблонов сертификатов.
Содержание
Выбранный тип шифрования зависит от участников взаимодействия - версии ПО домена (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 для пользователя, после установки чекбокса требуется смена пароля
Файл не является обязательным, но может влиять на поведение процесса аутентификации.
На сервере и клиентских машинах Windows он может быть расположен в $/krb5.ini.
Пример файла krb5.ini
Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).
В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.
На контроллере домена нужно создать пользователя с настройками по умолчанию.
Проверка: kinit должен успешно получить тикет.
На контроллере домена нужно выполнить команды:
Проверка: через ADSIEdit можно увидеть что свойство пользователя servicePrincipalName установлено либо посмотреть св-во servicePrincipalName с помощью команды Get-ADUser -Properties *.
На контроллере домена нужно выполнить команду:
ktpass /princ /mapuser +setupn /pass *
Можно игнорировать предупреждение «WARNING: pType and account type do not match. This might cause problems».
Проверка: в свойствах пользователя User logon name стал равен SPN либо посмотреть св-во UserPrincipalName с помощью команды Get-ADUser -Properties *.
Проверка: kinit должен успешно получить тикет.
Выполнить команду из /bin:
Проверка: kinit -k -t должен успешно получить тикет без запроса пароля.
Этот файл также можно получить в результате вызова команды ktpass на контроллере домена.
Создайте файл kerberos.properties в директории /standalone/wfe.custom. Замените в нем имена на настоящие.
На контроллере домена:
Для того чтобы браузер пытался использовать Kerberos для аутентификации:
- в нём должна быть включена настройка Enable Integrated Windows Authentication (в некоторых версиях IE её нет)
- настройки зоны безопасности должны позволять её использование, по умолчанию это настроено для LocalIntranet
- настройка должна быть корректно произведена
Во время запроса на сервере формируется в логе Request Authorization:
- Negotiate YIIV. - правильно
- Negotiate TlRMT. - неправильно (попытка использовать NTLM)
Если по нажатию на ссылке Сквозная аутентификация (kerberos) будет выведено окно с вводом логина/пароля - то это значит что браузер не получил сервисный тикет в контроллере домена или даже не пытался это сделать. При возникновении такой ситуации самым действенным оказывается использование WireShark для прослушивания траффика по порту 88 с контроллером домена.
На сервере должна быть корректно настроена аутентификация.
Настроить kerberos.properties если authentication.type установлено в kerberos (для sspiKerberos это не требуется):
Настройку login.relative.url установить в /krblogin.do.
Обратите внимание на атрибут salt в пакете KRB Error: KRB5KDC_ERR_PREAUTH_FAILED, он должен совпадать с principal, для которого вы получаете тикет; если не совпадает - то в БД kerberos что-то не так, попробуйте вновь воспользоваться командой ktpass
Включение аудита на контроллере домена иногда помогает понять проблему (логирование происходит в журнале событий, категория Безопасность.
Содержание
- Установить samba-winbind, samba, krb5-workstation, authconfig-gtk, sssd, sssd-client
- запустить system-config-authentication
- ввести настройки и выполнить вход:
Samba собранная с опциями: --with-ldap --with-ads --with-krb5 --with-pam --with-winbind
или просто установите из rpm.
Надеюсь что на вашем контроллере домена поднят DNS (Domain Names Server) с зонами прямого и обратного просмотра. Если поднят, то в файле /etc/resolv.conf прописываем следующее:
Если же в сети нет DNS (что вряд ли) сервера - можно воспользоваться файлами hosts на обеих машинах.
На машине в файл /etc/hosts добавляем:
На контроллере домена в файле %Systemroot%\
System32\drivers\etc\hosts пишем следующее:
%Systemroot% - папка WINNT или WINDOWS(на системном диске)
Приводим файл krb5.conf в соответствие с настройками вашей сети(не забывайте про регистр!).
После этого выполняем команду(необходимо знать пароль администратора КД):
Возможные проблемы на этом этапе:
Надо проверить правильность ввода логина\пароль админа.
Проверьте правильность настроек DNS и конфига krb5.conf
Рассинхронизация времени на КД и клиенте – выполните команду net time set(в linux) Желательно выполнять данную команду раз в неделю(можно через cron).
Пожалуй, самая легкая часть настройки.
Выкладываю уже готовый к эксплуатации конфиг (с комментариями к тому, на что надо обратить внимание):
Убедившись, что на контроллере домена нет машин с именем, которое мы использовали в конфиге. Выполняем команду:
1. Откроем файл /etc/nsswitch.conf для редактирования и найдем следующие строчки:
2. Заменим их на:
3. Перезапустим сервис winbind:
4. Проверим работу:
значит доверительная учетная запись компьютера в домене создана.
5. Проверка пользователей и групп:
должно вывести пользователей домена и группы домена.
6. Проверяем аутентификацию в домене:
где user - пользователь домена, 123 - пароль. Если ответ:
значит аутентификация в домене работает.
7. Проверяем, чтобы наш Linux видел пользователей домена:
должно вывести id пользователя домена и к каким группам он относится.
Перед выполнением нижеперечисленных действий рекомендуется сделать бэкап всех редактируемых файлов.
Файл /etc/pam.d/samba не требует редактирования, т.к. он уже содержит необходимое. Редактируем /etc/pam.d/login
Теперь на машину с linux можно заходить используя доменные аккаунты(DOMAIN\User).
Читайте также: