Меню

Kdc reply did not match expectations while getting initial credentials ошибка

The following error is prompted when trying to initialize krb5 with AD as shown below. The issue was I had my realm in lower case and not all parameters were fully entered.

$ kinit user@test.com
Password for user@test.com:
kinit: KDC reply did not match expectations while getting initial credentials

Solution: Ensure your krb5 file is structured this way.
– The realm is in capital letters
– Access the krb5.config file via C:cygwin64etccrypto-policiesback-ends.

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

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

[realms]
 WEBSITE.COM = {
  kdc = myserver.test.com
  admin_server = myserver.test.com
 }

[domain_realm]
 .test.com = TEST.COM
 Test.com = TEST.COM 

Next, run the kinit command again with the domain name in upper case as shown below, the error will not be prompted and the user will be authenticated via Kerberos with AD.

For more information, see the following link.
https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html#kerberos

Содержание

Введение

Зачастую возникает необходимость ввести Linux-машину в существующий домен Windows. Например, чтобы сделать файловый сервер с помощью Samba. Сделать это очень просто, для этого вам понадобятся клиент Kerberos, Samba и Winbind.

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

sudo aptitude update
sudo aptitude upgrade

Установить всё это добро можно командой:

sudo aptitude install krb5-user samba winbind 

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

sudo aptitude install libpam-krb5 libpam-winbind libnss-winbind

Либо, если вы используете Ubuntu Desktop, те же пакеты можно поставить через менеджер пакетов Synaptic.

Далее вам потребуется настроить все вышеперечисленные инструменты для работы с вашим доменом. Допустим, вы хотите войти в домен DOMAIN.COM, доменконтроллером которого является сервер dc.domain.com с IP адресом 192.168.0.1. Этот же сервер является и первичным DNS сервером домена. Кроме того допустим у вас есть второй доменконтроллер1), он же DNSdc2.domain.com с IP 192.168.0.2. Ваш же компьютер будет называться smbsrv01.

Настройка DNS

Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS сервера доменконтроллер2) и в качестве домена поиска — нужный домен.

Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf на примерно такое:

domain domain.com
search domain.com
nameserver 192.168.0.1
nameserver 192.168.0.2

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно.
Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head
Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf

Если IP-адрес динамический и присваивается DHCP сервером то после перезагрузки resolv.conf может формироваться «неправильный» resolv.conf’ , например присутствует только один nameserver 192.168.0.1 и не указаны domain и search. Нужно отредактировать /etc/dhcp/dhclient.conf. Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name, и вписать свой домен:

supersede domain-name "domain.com";

Чтобы добавить еще один nameserver нужно убрать комментарий перед prepend domain-name-servers и указать ip сервера:

prepend domain-name-servers 192.168.0.2;

Для применения изменений остается перезапустить службу:

/etc/init.d/networking restart

Теперь убедитесь, что вы задали нужное имя компьютера в файле /etc/hostname:

smbsrv01

Кроме того необходимо отредактировать файл /etc/hosts так, чтобы в нём была запись с полным доменным именем компьютера и обязательно коротким именем хоста, ссылающаяся на один из внутренних IP:

# Имена этого компьютера
127.0.0.1	localhost
127.0.1.1	smbsrv01.domain.com	smbsrv01

Сразу нужно проверить что нормально пингуется наш контроллер домена, по короткому и полному имени, чтобы в будушем не получать ошибки что контроллер домена не найден:

ping dc
ping dc.domain.com

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

Настройка синхронизации времени

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

sudo net time set dc

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

ntpdate ntp.mobatime.ru

Автоматическая же синхронизация настраивается с помощью ntpd, это демон будет периодически выполнять синхронизацию. Для начала его необходимо установить:

sudo aptitude install ntp

Теперь исправьте файл /etc/ntp.conf, добавив в него информацию о вашем сервере времени:

# You do need to talk to an NTP server or two (or three).
server dc.domain.com

После чего перезапустите демон ntpd:

sudo /etc/init.d/ntp restart

Теперь пора настраивать непосредственно взаимодействие с доменом.

Настройка авторизации через Kerberos

Начнём с настройки авторизации в домене через протокол Kerberos. Вам потребуется изменить файл /etc/krb5.conf. В общем случае он выглядит так:

[libdefaults]
	default_realm = DOMAIN.COM
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true

[realms]
	DOMAIN.COM = {
		kdc = dc
		kdc = dc2
		admin_server = dc
		default_domain = DOMAIN.COM
	}

[domain_realm]
	.domain.com = DOMAIN.COM
	domain.com = DOMAIN.COM
[login]
	krb4_convert = false
	krb4_get_tickets = false

Вам, конечно, нужно изменить domain.com на ваш домен и dc и dc2 на ваши доменконтроллеры. Кстати, возможно вам понадобится написать полные имена доменконтроллеров dc.domain.com и dc2.domain.com. Поскольку у меня прописан домен поиска в DNS, то мне это делать не нужно.

Обратите особое внимание на регистр написания имени домена — везде, где домен написан в верхнем регистре, его обязательно нужно писать именно в верхнем регистре. Иначе волшебным образом ничего может не заработать.

Это не все возможные опции настройки Kerberos, только основные. Однако их обычно достаточно.

Теперь настало время проверить, что мы можем авторизоваться в домене. Для этого выполните команду

kinit username@DOMAIN.COM

Вместо username естественно стоит вписать имя существующего пользователя домена.

Имя домена необходимо писать заглавными буквами!

Если вы не получили никаких ошибок — значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Кстати, некоторые распространённые ошибки перечислены чуть ниже.

Убедиться в том, что билет получен, можно выполнив команду

klist

Удалить все билеты (они вам вообще говоря не нужны) можно командой

kdestroy

Итак, будем считать, что авторизацию вы настроили, пора настроить непосредственно вход в домен, об этом после списка распространённых ошибок kinit.

Распространённые ошибки kinit

kinit(v5): Clock skew too great while getting initial credentials

Это значит, что у вашего компьютера не синхронизировано время с доменконтроллером (см. выше).

kinit(v5): Preauthentication failed while getting initial credentials

Вы ввели неверный пароль.

kinit(v5): KDC reply did not match expectations while getting initial credentials

Самая странная ошибка. Убедитесь, что имя realm в krb5.conf, а так же домен в команде kinit введены большими буквами:

DOMAIN.COM = {
# ...
kinit username@DOMAIN.COM
kinit(v5): Client not found in Kerberos database while getting initial credentials

Указанного пользователя не существует в домене.

Настройка Samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf. На данном этапе вас должны интересовать только некоторые опции из секции [global]. Ниже — пример части файла конфигурации Samba с комментариями по поводу значения важных параметров:

[global]
   # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без
   # последней секции после точки, а realm - полное имя домена 
   workgroup = DOMAIN
   realm = DOMAIN.COM

   # Эти две опции отвечают как раз за авторизацию через AD
   security = ADS
   encrypt passwords = true
   # Просто важные 
   dns proxy = no 
   socket options = TCP_NODELAY

   # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе,
   # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде
   domain master = no
   local master = no
   preferred master = no
   os level = 0
   domain logons = no

   # Отключить поддержку принтеров
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

После того, как вы отредактируете smb.conf выполните команду

testparm

Она проверит вашу конфигурацию на ошибки и выдаст суммарную сводку о нём:

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

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

net ads join -U username -D DOMAIN

И в случае успеха вы увидите что-то похожее на:

# net ads join -U username -D DOMAIN
Enter username's password:
Using short domain name -- DOMAIN
Joined 'SMBSRV01' to realm 'domain.com'

Используемые параметры команды net

-U username%password: Обязательный параметр, вместо username необходимо подставить имя пользователя с правами администратора домена, и указать пароль.

-D DOMAIN: DOMAIN — собственно сам домен, домен можно и не указывать, но лучше всё же это всегда делать — хуже не будет.

-S win_domain_controller: win_domain_controller, можно не указывать, но бывают случаи когда автоматически сервер не находит контроллер домена.

createcomputer=«OU/OU/…» : В AD часто используется OU (Organizational Unit), есть в корне домена OU = Office, в нем OU = Cabinet, чтобы сразу добавить в нужный можно указать так: sudo net ads join -U username createcomputer=«Office/Cabinet».

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

Так же можно набрать команду:

net ads testjoin

Если все хорошо, можно увидеть:

#net ads testjoin
Join is OK

Но иногда после сообщения о присоединении к домену выдаётся ошибка наподобие3):

DNS update failed!

Это не очень хорошо, и в этом случае рекомендуется ещё раз прочитать раздел про настройку DNS чуть выше и понять, что же вы сделали не так. После этого нужно удалить компьютер из домена и попытаться ввести его заново. Если вы твердо уверены, что всё настроили верно, а DNS всё равно не обновляется, то можно внести вручную запись для вашего компьютера на ваш DNS сервер и всё будет работать. Конечно, если нет никаких других ошибок, и вы успешно вошли в домен. Однако лучше всё же разберитесь, почему DNS не обновляется автоматически. Это может быть связано не только с вашим компьютером, но и с некорректной настройкой AD.

Прежде чем выяснять, почему же не обновляется DNS, не забудьте перезагрузить компьютер после введения в домен! Вполне возможно, что это решит проблему.

Если всё прошло без ошибок, то поздравляем, вы успешно вошли в домен! Можете заглянуть в AD и убедиться в этом. Кроме того хорошо бы проверить, что вы можете видеть ресурсы в домене. Для этого установите smbclient:

sudo aptitude install smbclient

Теперь можно просматривать ресурсы компьютеров домена. Но для этого нужно иметь билет kerberos, т.е. если мы их удалили, то получаем опять через kinit (см. выше). Посмотрим какие ресурсы предоставлены в сеть компьютером workstation:

smbclient -k -L workstation

Вы должны увидеть список общих ресурсов на этом компьютере.

Настройка Winbind

Если вам необходимо как-либо работать с пользователями домена, например, настраивать SMB-шары с разграничением доступа, то вам понадобится кроме самой Samba ещё и Winbind — специальный демон, служащий для связи локальной системы управления пользователями и группами Linux с сервером Active Directory. Проще говоря Winbind нужен, если вы хотите видеть пользователей домена на своём компьютере с Ubuntu.

Winbind позволяет спроецировать всех пользователей и все группы AD в вашу Linux систему, присвоив им ID из заданного диапазона. Таким образом вы сможете назначать пользователей домена владельцами папок и файлов на вашем компьютере и выполнять любые другие операции, завязанные на пользователей и группы.

Для настройки Winbind используется всё тот же файл /etc/samba/smb.conf. Добавьте в секцию [global] следующие строки:

   # Опции сопоставления доменных пользователей и виртуальных пользователей в системе через Winbind.
   # Диапазоны идентификаторов для виртуальных пользователей и групп.
   idmap uid = 10000 - 40000
   idmap gid = 10000 - 40000
   # Эти опции не стоит выключать.
   winbind enum groups = yes
   winbind enum users = yes
   # Использовать домен по умолчанию для имён пользователей. Без этой опции имена пользователей и групп
   # будут использоваться с доменом, т.е. вместо username - DOMAINusername.
   # Возможно именно это вам и нужно, однако обычно проще этот параметр включить. 
   winbind use default domain = yes
   # Если вы хотите разрещить использовать командную строку для пользователей домена, то
   # добавьте следующую строку, иначе в качестве shell'а будет вызываться /bin/false
   template shell = /bin/bash
   # Для автоматического обновления билета Kerberos модулем pam_winbind.so нужно добавить строчку
   winbind refresh tickets = yes

Параметры :

idmap uid = 10000 — 40000

idmap gid = 10000 — 40000

в новых версиях Samba уже устарели и при проверке конфига самбы с помощью testparm
будет выдваться предупреждение:

WARNING: The «idmap uid» option is deprecated

WARNING: The «idmap gid» option is deprecated

Чтобы убрать предупреждения нужно заменить эти строки на новые:

idmap config * : range = 10000-20000

idmap config * : backend = tdb

Теперь перезапустите демон Winbind и Samba в следующем порядке:

sudo /etc/init.d/winbind stop
sudo smbd restart
sudo /etc/init.d/winbind start 

Запускаем

sudo testparm

Смотрим есть ли ошибки или предупреждения, если появится:

«rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)»

Без перезагрузки можно устранить так:

ulimit -n 16384

Для сохранения после перезагрузки отредактировать файл /etc/security/limits.conf

# Добавить в конец файла строки:
*               -    nofile            16384
root            -    nofile            16384

После перезапуска проверьте, что Winbind установил доверительные отношения с AD командой:

# wbinfo -t
checking the trust secret for domain DCN via RPC calls succeeded

А так же, что Winbind увидел пользователей и группы из AD командами4):

wbinfo -u
wbinfo -g

Эти две команды должны выдать список пользователей и групп из домена соответственно. Либо с префиксом DOMAIN, либо без него — в зависимости от того, какое значение вы указали параметру «winbind use default domain» в smb.conf.

Итак, Winbind работает, однако в систему он ещё не интегрирован.

Добавление Winbind в качестве источника пользователей и групп

Для того, чтобы ваша Ubuntu прозрачно работала с пользователями домена, в частности, чтобы вы могли назначать пользователей домена владельцами папок и файлов, необходимо указать Ubuntu использовать Winbind как дополнительный источник информации о пользователях и группах.

Для этого измените две строчки в файле /etc/nsswitch.conf:

passwd:         compat
group:          compat

добавив к ним в конец winbind:

passwd:         compat winbind
group:          compat winbind

также рекомендую привести строку files в файле /etc/nsswitch.conf к виду:

files:          dns mdns4_minimal[NotFoud=return] mdns4

ubuntu server 14.04, файл /etc/nsswitch.conf не содержал строку
«files: dns mdns4_minimal[NotFoud=return] mdns4»
вместо неё было:
«hosts: files mdns4_minimal [NOTFOUND=return] dns wins»
Которую я преобразовал в:
«hosts: dns mdns4_minimal[NotFoud=return] mdns4 files»
после чего всё заработало

Теперь проверьте, что Ubuntu запрашивает у Winbind информацию о пользователях и группах, выполнив

getent passwd
getent group 

Первая команда должна вам вернуть всё содержимое вашего файла /etc/passwd, то есть ваших локальных пользователей, плюс пользователей домена с ID из заданного вами в smb.conf диапазона. Вторая должна сделать тоже самое для групп.

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

Авторизация в Ubuntu через пользователей домена

Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind.

Он-лайн авторизация

Для Ubuntu 10.04 и выше добавьте всего одну строку в файле /etc/pam.d/common-session, т.к. PAM и так неплохо справляется с авторизацией:

session  optional  pam_mkhomedir.so skel=/etc/skel/ umask=0077

Для Ubuntu 13.10 чтобы появилось поле ручного ввода логина необходимо в любой файл из папки /etc/lightdm/lightdm.conf/ снизу добавить строку:

greeter-show-manual-login=true

Для Ubuntu 9.10 и ниже придется редактировать несколько файлов (но никто не запрещает использовать этот способ и в 10.04 — он тоже работает):

Последовательность строк в файлах имеет значение!

/etc/pam.d/common-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok try_first_pass
auth        sufficient    pam_winbind.so use_first_pass krb5_auth krb5_ccache_type=FILE
auth        required      pam_deny.so

/etc/pam.d/common-account

account     sufficient    pam_winbind.so
account     required      pam_unix.so

/etc/pam.d/common-session

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_ck_connector.so nox11
session     required      pam_limits.so
session     required      pam_env.so
session     required      pam_unix.so

/etc/pam.d/common-password

password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_winbind.so
password    required      pam_deny.so

И, наконец, необходимо перенести запуск Winbind при загрузке системы после всех остальных служб (по умолчанию он запускается с индексом 20). Для этого в терминале выполните следующую команду:

sudo bash -c "for i in 2 3 4 5; do mv /etc/rc$i.d/S20winbind /etc/rc$i.d/S99winbind; done"

Что эквивалентно запуску для каждого уровня (в примере — 4) команды:

mv /etc/rc4.d/S20winbind /etc/rc4.d/S99winbind

В некоторых случаях winbind может иметь иной уровень запуска (например, S02winbind). Поэтому сначала проверьте имена файлов, вполнив команду «ls /etc/rc{2,3,4,5}.d/ | grep winbind» (без кавычек).

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

Офф-лайн авторизация

Часто возникает ситуация, когда домен-контроллер недоступен по различным причинам — профилактика, отключение света или вы принесли ноутбук домой и хотите поработать. В этом случае для Winbind можно настроить кэширование учетных записей пользователей домена. Для этого необходимо сделать следующее.
Добавьте в секцию [global] файла /etc/samba/smb.conf следующие строки:

[global]
   # Возможность оффлайн-авторизации при недоступности доменконтроллера
   winbind offline logon = yes
   # Период кэширования учетных записей, по умолчанию равен 300 секунд
   winbind cache time = 300
   # Необязательная настройка, но избавляет от нудных пауз, указываем контроллер домена dc, 
   # можно указать и ip, но это является плохим тоном
   password server = dc

Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf со следующим содержанием5):

Внимание! При использовании советов ниже может возникать совершенно случайная ошибка «Сбой аутентификации»! Поэтому все что Вы делаете, Вы делаете на свой страх и риск!

#
# pam_winbind configuration file
#
# /etc/security/pam_winbind.conf
#
[global]
  # turn on debugging
  debug = no
  # request a cached login if possible
  # (needs "winbind offline logon = yes" in smb.conf)
  cached_login = yes
  # authenticate using kerberos
  krb5_auth = yes
  # when using kerberos, request a "FILE" krb5 credential cache type
  # (leave empty to just do krb5 authentication but not have a ticket
  # afterwards)
  krb5_ccache_type = FILE
  # make successful authentication dependend on membership of one SID
  # (can also take a name)
  ;require_membership_of =
  silent = yes

Файл /etc/pam.d/gnome-screensaver в таком случае принимает вид:

auth    sufficient      pam_unix.so nullok_secure
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

А также изменяется файл /etc/pam.d/common-auth:

auth    optional        pam_group.so
auth    sufficient      pam_unix.so nullok_secure  use_first_pass
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

Ссылки

Hi,

here are some steps to use kerberos authentification against a active directory with OS Version Windows Server 2008 R2 or later on your linux machine.

The default krb5 configuration implementation of the most linux distributions did not work out of the box. I assume that the REALM in /etc/krb5.conf is already configured.

Typical error messages are:

kinit: KDC has no support for encryption type while getting initial credentials
kinit: KDC reply did not match expectations while getting initial credentials
michael@debdev:~# kinit  michael@subdomain.domain.local
Password for michael@subdomain.domain.local:
kinit: KDC has no support for encryption type while getting initial credentials

To eliminate the “KDC has no support for encryption type while getting initial credentials” issue change the default encryption type in the libdefaults section of the /etc/krb5.conf file.

Add the default_tgs_enctypes and default_tkt_enctypes to your config.

[libdefaults]
      default_realm = SUBDOMAIN.DOMAIN.LOCAL
      default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
      default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

check again

michael@debdev:~# kinit  michael@subdomain.domain.local
Password for michael@subdomain.domain.local:
kinit: KDC reply did not match expectations while getting initial credentials

If the “KDC reply did not match expectations while getting initial credentials” error occurs, check your /etc/krb5.conf. Ensure that all Realm names are in upper case letters.

[libdefaults]
      default_realm = SUBDOMAIN.DOMAIN.LOCAL
......
[realms]
        SUBDOMAIN.DOMAIN.LOCAL = {
                kdc = DC.SUBDOMAIN.DOMAIN.LOCAL:88
                admin_server = DC.SUBDOMAIN.DOMAIN.LOCAL
                default_domain = SUBDOMAIN.DOMAIN.LOCAL
        }

kinit also needs the realm respective the domain in upper case.

michael@debdev:~# kinit michael@SUBDOMAIN.DOMAIN.LOCAL
Password for michael@SUBDOMAIN.DOMAIN.LOCAL:
michael@debdev:~#
michael@debdev:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: michael@SUBDOMAIN.DOMAIN.LOCAL

Valid starting       Expires              Service principal
23.01.2014 21:35:39  24.01.2014 11:35:44  krbtgt/SUBDOMAIN.DOMAIN.LOCAL@SUBDOMAIN.DOMAIN.LOCAL
        renew until 24.01.2014 21:35:39

For example I used the ticket to get some information about CIFS of a Windows Box

michael@debdev:~# rpcclient win7.subdomain.domain.local -k
rpcclient $> srvinfo
        WIN7.SUBDOMIN.Wk Sv NT
        platform_id     :       500
        os version      :       6.1
        server type     :       0x1003
rpcclient $> getusername
Account Name: michael, Authority Name: SUBDOMAIN

Michael

Advertisment to support michlstechblog.info

My Knowledgebase for things about Linux, Windows, VMware, Electronic and so on…

This website uses cookies to improve your experience and to serv personalized advertising by google adsense. By using this website, you consent to the use of cookies for personalized content and advertising. For more information about cookies, please see our Privacy Policy, but you can opt-out if you wish. Accept Reject Read More

I am setting up a testbed environment where Linux (Ubuntu 10.04) clients will authenticate to a Windows Server 2008 R2 Domain Server.

I am following the official Ubuntu guide to set up a Kerberos client here: https://help.ubuntu.com/community/Samba/Kerberos, but I have encountered a problem when running the kinit command to connect to the domain server.

The command I am running is: kinit Administrator@DS.DOMAIN.COM. This command returns the following error:

Realm not local to KDC while getting initial credentials. Unfortunately, I cannot find any one else via Google searches that have experienced this exact error, so I have no idea what it means.

The client is able to ping the server’s hostname, so the DNS server is pointing to the domain server.

Below is my krb5.conf file:

[libdefaults]
default = DS.DOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc true

[realms]
    DS.DOMAIN.COM = {
        kdc = ds.domain.com:88
        admin_server = ds.domain.com
        default_domain = domain.com
    }

[domain_realm]
    .domain.com = DS.DOMAIN.COM
    domain.com = DS.DOMAIN.COM

How can I correct these errors? I would greatly appreciate all help I can get!

asked Aug 3, 2010 at 19:04

Phanto's user avatar

PhantoPhanto

8615 gold badges16 silver badges24 bronze badges

Is your domain name DS.DOMAIN.COM or just DOMAIN.COM ?

In your realms you need to have them match, so assuming that DS.DOMAIN.COM is your domain you need to change:

[domain_realm]
    .domain.com = DS.DOMAIN.COM
    domain.com = DS.DOMAIN.COM

to

[domain_realm]
    .ds.domain.com = DS.DOMAIN.COM
    ds.domain.com = DS.DOMAIN.COM

However, if you domain is really DOMAIN.COM you would need to change your krb5.conf to look like:

[libdefaults]
default = DOMAIN.COM
dns_lookup_realm = true
dns_lookup_kdc = true

[realms]
    DOMAIN.COM = {
        kdc = ds.domain.com:88
        #You can have more than one kds, just keep adding more kdc =
        #entries
        #kdc = dsN.domain.com:88
        #Uncomment if you have a krb admin server
        #admin_server = ds.domain.com:749
        default_domain = domain.com
    }

[domain_realm]
    .domain.com = DOMAIN.COM
    domain.com = DOMAIN.COM

And then you would kinit like so: kinit Administrator@DOMAIN.COM

lilalinux's user avatar

answered Aug 3, 2010 at 19:55

Zypher's user avatar

ZypherZypher

37.1k5 gold badges52 silver badges95 bronze badges

4

Peaking into the source code, it looks like that error is thrown when the negotiation process receives a referral to another domain and that domain is not ‘local’, or in your krb5.conf config.

00219     /*
00220      * If the backend returned a principal that is not in the local
00221      * realm, then we need to refer the client to that realm.
00222      */
00223     if (!is_local_principal(client.princ)) {
00224       /* Entry is a referral to another realm */
00225       status = "REFERRAL";
00226       errcode = KRB5KDC_ERR_WRONG_REALM;
00227       goto errout;
00228     }

What that could be, I couldn’t tell you. That probably depends on your Active Directory environment, and whether or not there are multiple domains in the tree. You probably need more domain_realm aliases, but exactly what that is we can’t tell from here.

answered Aug 3, 2010 at 19:42

sysadmin1138's user avatar

sysadmin1138sysadmin1138

132k18 gold badges174 silver badges299 bronze badges

I had the same message using the same krb5.conf as provided by Zypher:

[libdefaults]
   default = MYDOMAIN.COM
   dns_lookup_realm = true
   dns_lookup_kdc = true
   ticket_lifetime = 24h
   renew_lifetime = 7d
   forwardable = true

[realms]
MYDOMAIN.COM = {
   kdc = mydc.mydomain.com:88
   admin_server = mydc.mydomain.com:749
   default_domain = mydomain.com
}

[domain_realm]
   .mydomain.com = MYDOMAIN.COM
   mydomain.com = MYDOMAIN.COM

(sorry it seems I can’t get proper formatting :/ )

In my case, I needed to kinit to MYDOMAIN.LOCAL rather than MYDOMAIN.COM.
Not sure if this is due to an authentication setting in AD in general or just for my AD domain. My domain has 2 DCs, one is W2k3 R2 and the other (the one specified as mydc.mydomain.com in krb5.conf) is W2k8 R2.
But this is another possible cause for the «Realm not local to KDC while getting initial credentials» message

answered Jan 27, 2012 at 16:00

zsispeo's user avatar

I had this very same and found the answer was so simple after fixing my config I still had this. Thanks to logicalfuzz at linuxqustions.org.

kinit -V myname@domain.net
kinit: KDC reply did not match expectations while getting initial credentials

kinit -V myname@DOMAIN.NET
Authenticated to Kerberos v5

The capitals make all the difference here. I know this is shown in examples but I wanted to stress it.

techraf's user avatar

techraf

4,1738 gold badges29 silver badges44 bronze badges

answered Sep 11, 2016 at 14:35

user375207's user avatar

1

I got this error while trying with connecting that machine from one domain to different domain. Editing /etc/krb5.conf also didn’t work.
Then I tried the following command to reconfigure stuffs for different domain

# sudo dpkg-reconfigure -plow krb5-config

with desired options and settings which stopped giving the above error in kinit command. Resolved.

answered Jul 26, 2016 at 13:35

vallabh's user avatar

ill add this just because i just ended here for the same error but found another fix for yet another problem … make sure that the domain is in ALL CAPS : my.user@DOMAIN.LOCAL and not my.user@domain.local… i just lost 2 hours of my life because of this one…

answered Apr 11, 2017 at 15:22

boiss007's user avatar

I know this is an old question, but I do want to add for future troubleshooters that my resolution to this issue was a combination of all of the suggested answers, as well as adding my primary domain controller to my /etc/hosts

answered Nov 5, 2017 at 8:56

Norr's user avatar

NorrNorr

1151 silver badge4 bronze badges

The configurations from this article worked for me.

Contents of rightly configured krb5.conf file with realm name, as an example:

[root@HOST]# cat $INFA_HOME/services/shared/security/krb5.conf
[libdefaults]
#specifies the default realm that needs to be picked up for authentication
default_realm = INFA.COM
dns_lookup_realm = true
dns_lookup_kdc = true

#this is a mandatory flag as we need to obtain forwardable tickets from the KDC
forward = true
forwardable = true

[realms]
#Realm configuration with different possible way to be resolved
INFA.COM = {
admin_server = WINDOWSHOST.INFA.COM
kdc = ​WINDOWSHOST.INFA.COM
}

[domain_realm]
infa.com = INFA.COM
.infa.com = INFA.COM​

Andrew Schulman's user avatar

answered May 4, 2021 at 19:51

user655415's user avatar

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

[libdefaults]
default_realm = DOMAIN.LOCAL
dns_lookup_kdc = true
dns_lookup_realm = true
ticket_lifetime = 24h
#default_keytab_name = /etc/squid3/PROXY.keytab

; for Windows 2003
; default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
; default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
; permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
; for Windows 2008 with AES
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
DOMAIN.LOCAL = {
kdc = dc.domain.local
admin_server = dc.domain.local
default_domain = domain.local
kpasswd_server = dc.domain.local
}

[domain_realm]
.DOMAIN.LOCAL = DOMAIN.LOCAL
DOMAIN.LOCAL = DOMAIN.LOCAL

keep a register

answered Dec 15, 2015 at 12:50

Alex Real's user avatar

1

Solution Verified
— Updated 2016-09-16T21:38:53+00:00 —

English

  • No translations currently exist.

Issue

  • Getting error while executing knit command:
[root@localhost ~]# kinit user
Password for user@EXAMPLE.COM:
kinit: KDC reply did not match expectations while getting initial credentials

Environment

  • Red Hat Enterprise Linux
  • Kerberos

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

New to Red Hat?

Learn more about Red Hat subscriptions

Using a Red Hat product through a public cloud?

How to access this content

установили libkrb5 и krb5-kinit
всё ностроили но пишет следующее:
kinit(v5): Clock ckew too great while getting initial credentials

« Последнее редактирование: 12.03.2010 10:50:49 от kakawkin »


Записан


Часики синхронизируйте между машинами, у Вас разница более 5 минут (это ограничение протокола Kerberos).

« Последнее редактирование: 12.03.2010 11:04:08 от bormant »


Записан


вот именно что всё правельно — максимальный разход машин по времени гдето секунд 30

P.S. Смотрели настройки часового пояса и как показало окошко — у нас часовой пояс «плавающий»


Записан


Это только кажется, что правильно. Время должно сходиться с учётом временной зоны.
Как оно есть на самом деле — будет зависеть от конкретных реализаций, поэтому просьба к Вам, как настроите, сообщите тут что куда вводили, какие реализации, с какими настройками в итоге заработало. Спасибо.

« Последнее редактирование: 12.03.2010 11:12:44 от bormant »


Записан


Теперь после синхронизации часиков появилась следующая ошибочка:KDC reply did match expextationswhile getting intial credentials


Записан


Оно говорит несколько другое:
kinit(v5): KDC reply did not match expectations while getting initial credentials.

Говорит, неожиданный ответ от KDC при получении начальных полномочий.

Теперь без подробностей не обойтись. Говорите, что во что вводите, что делаете, что получаете, с техническими подробностями.


Записан


абсолютно всё сделал как опясано в этом мануале _http://team.ru/soft/altlinux_domen.shtml


Записан


Это не ответ на все поставленные вопросы, как максимум — на вопрос «что делали?».
Нужна информация о домене, его первичном контроллере, файлы /etc/krb5.conf, и, предупреждая последующие вопросы, /etc/samba/smb.conf, выполняемые команды буквально.

Соответствует ли секция [realms] файла krb5.conf действительной информации о домене?

« Последнее редактирование: 14.03.2010 17:43:35 от bormant »


Записан


=)
krb5.conf вообще пустотой пахнет только.


Записан


Примерное содержимое /etc/krb5.conf для домена TEST.LOC, роль PDC выполняет dc1.test.loc, DNS и сеть настроены и функционируют, регистр имеет значение:

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

[libdefaults]
default_realm = TEST.LOC
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes

[realms]
TEST.LOC = {
   kdc = dc1.test.loc
   admin_server = dc1.test.loc
   default_domain = test.loc
}

[domain_realm]
.kerberos.server = TEST.LOC
.test.loc = TEST.LOC

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

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

Первоисточник: http://wiki.samba.org/index.php/Samba_%26_Active_Directory


Записан


ввёл я в фаил данные — один фиг непашет и выдаёт туже самую ошибку


Записан


Итак, специально поставил altlinux-4.0.3-lite-i586-install_ru-cd.iso, чтобы убедиться, что не виновата версия дистрибутива.

Настраиваем сеть, подключаем репозитории, ставим krb5-kinit, krb5-kadmin, krb5-kdc, правим /etc/krb5.conf и /var/lib/kerberos/krb5kdc/kdc.conf, выполняем kinit admin@domain, вуаля.

Можете переименовать /etc/krb5.conf и /var/lib/kerberos/krb5kdc/kdc.conf, kinit должен отрабатывать всё равно.

Если доверяете, можете выдать удалённый административный вход на эту машину (ssh), посмотрю — за этим в ЛС или jabber.

« Последнее редактирование: 22.03.2010 12:57:45 от bormant »


Записан


Как ввести Ubuntu/Debian/Linux в домен Windows?

Имеем Ubuntu Server 12.04 и контроллер домена Windows Server 2008 R2. Введем сервер Ubuntu в домен Windows.

Обновимся:

# apt-get update

# apt-get upgrade
Установим нужный софт:

# apt-get install krb5-user samba winbind


Настроим корректно DNS. Допустим на нашем сервере с ubuntu две сетевые карты, одна в мир, другая в локалку.
В /etc/network/interfaces у интерфейса, который смотрит в мир пропишем днс-сервер провайдера:

iface eth0 inet static
address 144.16.0.55
netmask 255.255.255.0
network 144.16.0.0
broadcast 144.16.0.255
gateway 142.16.0.1
dns-nameservers 12.145.44.1

Дальше добавим DNS-записи в /etc/resolvconf/resolv.conf.d/head :

 domain testdomen.local  #наш домен
search testdomen.local  #наш домен
nameserver 10.0.0.3     #контроллер домена (dns-server)

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

# /etc/init.d/networking restart

Теперь нужно проверить, пингуется ли наш контроллер по имени. Если да, то идем дальше.

Настройка синхронизации времени с контроллером домена

Синхронизируем время с контроллером:

# ntpdate -q 10.0.0.3

или

# ntpdate testserver

Теперь настраиваем авторизацию через Kerberos. Правим /etc/krb5.conf
Моя конфигурация:

[libdefaults]
default_realm = TESTDOMEN.LOCALkrb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true

[realms]
TESTDOMEN.LOCAL = {
kdc = 10.0.0.3                        #ip контроллера
admin_server = 10.0.0.3       #ip контроллера
}

[domain_realm]
.testdomen.local = TESTDOMEN.LOCAL
testdomen.local = TESTDOMEN.LOCAL

[login]
krb4_convert = false
krb4_get_tickets = false

В этих настройках важен регистр написания имени домена.

Пробуем авторизоваться в домене:

# kinit admin@TESTDOMEN.LOCAL

admin — логин существующего пользователя домена. Отсутствие ошибок означает правильность настройки. Проверим список полученных билетов Kerberos:

# klist

Распространенные ошибки:
Ошибка kinit(v5): Clock skew too great while getting initial credentials
Нужно синхронизировать время с контроллером домена командой, написанной вначале статьи. И не важно, что оно совпадает или почти совпадает.

Ошибка kinit(v5): Preauthentication failed while getting initial credentials
Введен неправильный пароль юзера.

Ошибка kinit(v5): KDC reply did not match expectations while getting initial credentials
Проверить правильность конфига /etc/krb5.conf

Ошибка kinit(v5): Client not found in Kerberos database while getting initial credentials
Нет такого пользователя в домене

Конфигурирование Samba
Правим конфиг самбы /etc/samba/smb.conf
Мой конфиг:

[global]
workgroup = TESTDOMEN
realm = TESTDOMEN.LOCAL
server string = %h server (Samba, Ubuntu)
dns proxy = no
socket options = TCP_NODELAY
domain master = no
local master = no
preferred master = no
os level = 0
domain logons = no#### Debugging/Accounting ####

log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d

####### Authentication #######
security = ADS
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Entersnews*spassword:* %nn *Retypesnews*spassword:* %nn *passwordsupdatedssuccessfully* .
pam password change = yes
map to guest = bad user

Настройка Winbind

Добавляем в /etc/samba/smb.conf в секцию [global] следующее:

idmap uid = 10000 — 40000
idmap gid = 10000 — 40000
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = yes
winbind refresh tickets = yes

Чтобы Ubuntu прозрачно работала с пользователями домена (к примеру, назначение пользователей домена владельцами папок и файлов), нужно указать Ubuntu использовать Winbind как дополнительный источник информации о пользователях и группах. Изменяем в /etc/nsswitch.conf пару строк:

passwd: compat winbind
group: compat winbind

Ввод сервера Ubuntu в домен Windows

Стартуем нужные сервисы:

# service smbd start
# service winbind start
# service nmbd start

Вводим машину в домен:

# net ads join -U admin -D TESTDOMEN

admin — администратор домена

Всё, ubuntu в домене.

Рестартуем нужные сервисы:

# service smbd restart
# service winbind restart
# service nmbd restart

Проверяем, может ли ubuntu server получить список юзеров или групп домена:

# wbinfo -g
# wbinfo -u

Если работает, то теперь все готово для того, чтобы настроить Squid 🙂

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Kaspersky safe kids ошибка подключения
  • Kaspersky safe kids неизвестная ошибка windows 10