У меня есть Raspberry Pi 3B+, который я использую в качестве домашнего сервера.
Я установил и настроил Samba AD DC из Raspbian pacakges (4.5.12+dfsg-2+deb9u4).
Я настроил SSSD на сервере AD DC для аутентификации локальных пользователей.
Моя настройка работала нормально, но с начала декабря у меня начались всевозможные проблемы с аутентификацией. Почти все мои проблемы теперь решены, за исключением того, что я не могу аутентифицироваться на локальном сервере с использованием учетных записей AD.
Я могу аутентифицироваться на другом Raspberry Pi в моей сети, который присоединен как член домена и настроен с SSSD.
Я искал в Интернете решения, но не могу понять.
Вот содержимое соответствующих файлов конфигурации:
/ И т.д. / имя хоста
pitaya
/etc/resolv.conf
search gggm.int
nameserver 192.168.2.26
/etc/krb5.conf
[libdefaults]
default_realm = GGGM.INT
dns_lookup_realm = false
dns_lookup_kdc = true
[domain_realm]
.gggm.int = GGGM.INT
/etc/samba/smb.conf
[global]
netbios name = PITAYA
realm = GGGM.INT
workgroup = GGGM
server role = active directory domain controller
dns forwarder = 192.168.2.1
idmap_ldb:use rfc2307 = yes
log level = 2
server string = Pitaya
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/%U
template shell = /bin/bash
username map = /etc/samba/user.map
kerberos method = secrets and keytab
tls enabled = yes
tls keyfile = /var/lib/samba/private/tls/sambaKey.pem
tls certfile = /var/lib/samba/private/tls/sambaCert.pem
tls cafile = /var/lib/samba/private/tls/crt.ca-chain.pem
<Share configuration skipped...>
/etc/sssd/sssd.conf
[sssd]
services = nss, pam, sudo, ssh
config_file_version = 2
domains = GGGM.INT
full_name_format = %1$s
[domain/GGGM.INT]
ad_domain = gggm.int
id_provider = ad
auth_provider = ad
access_provider = ad
sudo_provider = ad
use_fully_qualified_names = false
ldap_id_mapping = false
ldap_referrals = false
override_homedir = /home/%u
enumerate = true
ldap_sudo_search_base = OU=sudoers,OU=gggm.int,DC=gggm,DC=int
ad_gpo_access_control = permissive
dyndns_update = false
Вывод uname -a
Linux pitaya 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
Разрешение DNS работает нормально
root@pitaya ~ # host pitaya
pitaya.gggm.int has address 192.168.2.26
root@pitaya ~ # host 192.168.2.26
26.2.168.192.in-addr.arpa domain name pointer pitaya.gggm.int.
root@pitaya ~ # host -t SRV _ldap._tcp.gggm.int
_ldap._tcp.gggm.int has SRV record 0 100 389 pitaya.gggm.int.
root@pitaya ~ # host -t SRV _kerberos._tcp.gggm.int
_kerberos._tcp.gggm.int has SRV record 0 100 88 pitaya.gggm.int.
root@pitaya ~ #
Я могу аутентифицироваться, используя Kerberos в качестве пользователя домена:
root@pitaya ~ # kinit ghigad
Password for ghigad@GGGM.INT:
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ghigad@GGGM.INT
Valid starting Expires Service principal
03/01/19 12:38:35 03/01/19 22:38:35 krbtgt/GGGM.INT@GGGM.INT
renew until 04/01/19 12:38:32
root@pitaya ~ #
Я могу перечислить акции на локальном сервере:
root@pitaya ~ # smbclient -k -L pitaya
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]
Sharename Type Comment
--------- ---- -------
netlogon Disk
sysvol Disk
IPC$ IPC IPC Service (Pitaya)
Domain=[GGGM] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]
Server Comment
--------- -------
Workgroup Master
--------- -------
root@pitaya ~ #
Я могу войти, используя принципал машины.
root@pitaya ~ # kdestroy
root@pitaya ~ # kinit -k PITAYA$
root@pitaya ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: PITAYA$@GGGM.INT
Valid starting Expires Service principal
03/01/19 12:43:17 03/01/19 22:43:17 krbtgt/GGGM.INT@GGGM.INT
renew until 04/01/19 12:43:17
root@pitaya ~ #
Я также могу перечислить общие ресурсы сервера, используя smbclient -k -L pitaya используя этот тикет (тот же вывод, что и выше).
Кроме того, wbinfo -u и getent passwd перечисляют пользователей домена. Аналогично, wbinfo -g и getent group перечисляют группы домена.
Вывод wbinfo -P
checking the NETLOGON for domain[GGGM] dc connection to "pitaya.gggm.int" succeeded
Я попытался проверить базу данных моего домена, и я не получил никакой ошибки ...
root@pitaya ~ # samba-tool dbcheck
Processing section "[netlogon]"
Processing section "[sysvol]"
pm_process() returned Yes
schema_fsmo_init: we are master[yes] updates allowed[no]
schema_fsmo_init: we are master[yes] updates allowed[no]
Checking 400 objects
Checked 400 objects (0 errors)
Вот содержимое krb5.keytab.
root@pitaya ~ # klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 31/12/18 12:16:18 host/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 host/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 host/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 host/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 host/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 host/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 host/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 host/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 host/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 host/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 gc/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 gc/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 gc/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 gc/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 gc/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 gc/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 gc/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 gc/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 gc/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 gc/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 ldap/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 ldap/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 ldap/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 ldap/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 ldap/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 ldap/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 ldap/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 ldap/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 ldap/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 ldap/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 restrictedkrbhost/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 restrictedkrbhost/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 restrictedkrbhost/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:18 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 restrictedkrbhost/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:18 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 restrictedkrbhost/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:18 krbtgt/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 krbtgt/PITAYA@GGGM.INT (des-cbc-crc)
3 31/12/18 12:16:18 krbtgt/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 krbtgt/PITAYA@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:18 krbtgt/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:19 krbtgt/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:19 krbtgt/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:19 krbtgt/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:19 krbtgt/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:19 krbtgt/PITAYA@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:19 PITAYA$@GGGM.INT (arcfour-hmac)
3 31/12/18 12:16:19 PITAYA$@GGGM.INT (aes256-cts-hmac-sha1-96)
3 31/12/18 12:16:19 PITAYA$@GGGM.INT (aes128-cts-hmac-sha1-96)
3 31/12/18 12:16:19 PITAYA$@GGGM.INT (des-cbc-md5)
3 31/12/18 12:16:19 PITAYA$@GGGM.INT (des-cbc-crc)
Однако, если я пытаюсь пройти проверку подлинности в домене, проверка подлинности в виде открытого текста завершается успешно, но запрос / ответ не выполняется.
root@pitaya ~ # wbinfo -a ghigad
Enter ghigad's password:
plaintext password authentication succeeded
Enter ghigad's password:
challenge/response password authentication failed
wbcAuthenticateUserEx(GGGM\ghigad): error code was NT_STATUS_WRONG_PASSWORD (0xc000006a)
error message was: Wrong Password
Could not authenticate user ghigad with challenge/response
root@pitaya ~ #
Я попытался сбросить пароль моего пользователя (samba-tool user setpassword ghigad), но ничего не изменилось.
Я не могу войти на свой сервер, используя SSH и доменную учетную запись (на моем другом сервере я могу ...).
Еще одно странное поведение, kinit -k не удается:
root@pitaya ~ # kinit -k
kinit: Preauthentication failed while getting initial credentials
root@pitaya ~ #
Копаясь в лог-файлах, я нашел это ...
[2019/01/03 12:51:23.391820, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Failed to decrypt PA-DATA -- host/pitaya.gggm.int@GGGM.INT (enctype aes256-cts-hmac-sha1-96) error Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96
[2019/01/03 12:51:23.392318, 5] ../source4/dsdb/common/util.c:5252(dsdb_update_bad_pwd_count)
Not updating badPwdCount on CN=PITAYA,OU=Domain Controllers,DC=gggm,DC=int after wrong password
[2019/01/03 12:51:23.392435, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Failed to decrypt PA-DATA -- host/pitaya.gggm.int@GGGM.INT
Также обратите внимание, что все мои компьютеры с Windows работают нормально. Пользователи могут войти и использовать общие диски. Я также могу использовать инструменты RSAT (GPO, DNS, Users, Printers и т.д.).
Я чувствую, что мои проблемы связаны с проверкой подлинности Kerberos на уровне обслуживания, но я застрял ... Я не могу понять, как решить эту проблему ...
Кто-нибудь может помочь?
Если вам, ребята, нужно больше войти, я тоже могу добавить выдержки ...
редактировать
Я продолжал искать решение, сделал эксперимент.
Я установил другую машину Linux в качестве PDC (samba-tool domain join gggm.int DC --dns-backend=SAMBA_INTERNAL --option='idmap_ldb:use rfc2307 = yes'). Все прошло хорошо, за исключением того, что после того, как я присоединился к домену, машина начала вести себя немного как первая ...
getent passwd вернул список пользователей, getent group вернул список групп, но login ghigad всегда не удался.
Наконец я обнаружил, что включение службы pac в SSSD решило проблему ...
sssd.conf
[sssd]
services = nss, pam, sudo, ssh, pac, ifp
Поэтому я перешел на другой проблемный сервер и включил службу pac в SSSD и скрестил пальцы, надеясь, что проблема будет решена.
К сожалению, это не так просто ... У меня все еще есть странные проблемы с аутентификацией ...
Я очистил кэш SSSD (sssctl cache-remove), и getent passwd больше не может перечислять пользователей моего домена, и мой домен отключен в SSSD.
root@pitaya /usr/sbin # sssctl domain-status gggm.int
Online status: Offline
Active servers:
AD Global Catalog: not connected
AD Domain Controller: pitaya.gggm.int
Discovered AD Global Catalog servers:
None so far.
Discovered AD Domain Controller servers:
- pitaya.gggm.int
Я попытался восстановить Keytab моей машины, на случай, если это помогло.
root@pitaya ~ # rm /etc/krb5.keytab
root@pitaya ~ # net ads keytab create -P
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
root@pitaya ~ # net ads keytab create -U ghigad
Enter ghigad's password:
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
kerberos_kinit_password GGGM@GGGM.INT failed: Client not found in Kerberos database
Единственный способ воссоздать Keytab - это сначала пройти аутентификацию с помощью Kerberos.
root@pitaya ~ # kinit ghigad
Password for ghigad@GGGM.INT:
root@pitaya ~ # net ads keytab create -k
root@pitaya ~ # klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 host/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 host/PITAYA@GGGM.INT (des-cbc-crc)
3 host/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 host/PITAYA@GGGM.INT (des-cbc-md5)
3 host/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 host/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 host/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 host/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 host/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 host/PITAYA@GGGM.INT (arcfour-hmac)
3 gc/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 gc/PITAYA@GGGM.INT (des-cbc-crc)
3 gc/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 gc/PITAYA@GGGM.INT (des-cbc-md5)
3 gc/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 gc/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 gc/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 gc/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 gc/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 gc/PITAYA@GGGM.INT (arcfour-hmac)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (des-cbc-crc)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (des-cbc-md5)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 e3514235-4b06-11d1-ab04-00c04fc2dcd2/PITAYA@GGGM.INT (arcfour-hmac)
3 ldap/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 ldap/PITAYA@GGGM.INT (des-cbc-crc)
3 ldap/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 ldap/PITAYA@GGGM.INT (des-cbc-md5)
3 ldap/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 ldap/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 ldap/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 ldap/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 ldap/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 ldap/PITAYA@GGGM.INT (arcfour-hmac)
3 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 restrictedkrbhost/PITAYA@GGGM.INT (des-cbc-crc)
3 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 restrictedkrbhost/PITAYA@GGGM.INT (des-cbc-md5)
3 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 restrictedkrbhost/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 restrictedkrbhost/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 restrictedkrbhost/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 restrictedkrbhost/PITAYA@GGGM.INT (arcfour-hmac)
3 krbtgt/pitaya.gggm.int@GGGM.INT (des-cbc-crc)
3 krbtgt/PITAYA@GGGM.INT (des-cbc-crc)
3 krbtgt/pitaya.gggm.int@GGGM.INT (des-cbc-md5)
3 krbtgt/PITAYA@GGGM.INT (des-cbc-md5)
3 krbtgt/pitaya.gggm.int@GGGM.INT (aes128-cts-hmac-sha1-96)
3 krbtgt/PITAYA@GGGM.INT (aes128-cts-hmac-sha1-96)
3 krbtgt/pitaya.gggm.int@GGGM.INT (aes256-cts-hmac-sha1-96)
3 krbtgt/PITAYA@GGGM.INT (aes256-cts-hmac-sha1-96)
3 krbtgt/pitaya.gggm.int@GGGM.INT (arcfour-hmac)
3 krbtgt/PITAYA@GGGM.INT (arcfour-hmac)
3 PITAYA$@GGGM.INT (des-cbc-crc)
3 PITAYA$@GGGM.INT (des-cbc-md5)
3 PITAYA$@GGGM.INT (aes128-cts-hmac-sha1-96)
3 PITAYA$@GGGM.INT (aes256-cts-hmac-sha1-96)
3 PITAYA$@GGGM.INT (arcfour-hmac)
Затем я перезапустил SSSD и проверил статус. Все еще в автономном режиме.
Я попытался экспортировать Keytab с помощью samba-tool.
root@pitaya ~ # rm /etc/krb5.keytab
root@pitaya ~ # samba-tool domain exportkeytab /etc/krb5.keytab --principal=PITAYA$
Export one principal to /etc/krb5.keytab
root@pitaya ~ # klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 PITAYA$@GGGM.INT (arcfour-hmac)
3 PITAYA$@GGGM.INT (aes256-cts-hmac-sha1-96)
3 PITAYA$@GGGM.INT (aes128-cts-hmac-sha1-96)
3 PITAYA$@GGGM.INT (des-cbc-md5)
3 PITAYA$@GGGM.INT (des-cbc-crc)
root@pitaya ~ # service sssd restart
root@pitaya ~ # sssctl domain-status gggm.int
Online status: Online
Active servers:
AD Global Catalog: pitaya.gggm.int
AD Domain Controller: pitaya.gggm.int
Discovered AD Global Catalog servers:
- pitaya.gggm.int
Discovered AD Domain Controller servers:
- pitaya.gggm.int
После этого getent passwd перечислил пользователей моего домена, но остальная часть моего Keytab облажалась.
kinit -k прежнему не работает, потому что host/pitaya.gggm.int@GGGM.INT не находится в Keytab, но kinit -k PITAYA$ работает правильно.
После этого работает smbclient -kL pitaya .
Мне действительно нужно, чтобы все имена участников-служб были в моей таблице ключей, но net ads keytab create таблицы ключей в сети не дает действительного.
Как я могу сгенерировать действительный Keytab?
Я буду продолжать пытаться заставить это работать и опубликовать мой прогресс здесь ... Любая помощь будет оценена.