Назад | Перейти на главную страницу

Автоматическое обновление Keytab хоста Kerberos с помощью SSSD

Кто-нибудь здесь видел, как их серверы Linux были удалены из домена AD из-за истекших учетных данных компьютера? Мы используем аутентификацию AD с sssd-1.13.3-56.el6 (Centos 6)

За "https://bugzilla.redhat.com/show_bug.cgi?id=1290761", sssd должен иметь возможность автоматически обновлять учетные данные хоста. Нет никаких упоминаний о каких-либо дополнительных действиях по настройке, которые следует предпринять при присоединении к AD согласно соответствующей документации Red Hat (" Интеграция Red Hat Enterprise Linux 6 с Active Directory ").

Согласно моему поиску, некоторые действительно запускают задания cron для обновления учетных данных хоста "https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/CRA43XHHDBPAENAYJ3INUWSCE2Q2NB5W/"

Устранение неполадок SSSD Kerberos AD Centos

Требуется ли для запуска задание cron: «msktutil --auto-update» и «kinit -k $»?

Или sssd должен справиться с этим?

Вы устанавливаете "ad_maximum_machine_account_password_age" в sssd.conf или оставляете его по умолчанию на 30 дней.

Привет,

ОБНОВЛЕНИЕ: @jhrozek, Спасибо за комментарий.
Я все еще вижу ту же проблему с моей конфигурацией.
Похоже, билет не был продлен 28 мая и сервер выпал из домена:

    # net ads testjoin   
kerberos_kinit_password I-12345CV3EABF$@STAGE.example.com failed: Preauthentication failed     
kerberos_kinit_password I-12345CV3EABF$@STAGE.example.com failed: Preauthentication failed     
Join to domain is not valid: Logon failure    

Статус Keytab:

# klist -kt
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   2 04/28/17 02:57:54 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   2 04/28/17 02:57:54 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   2 04/28/17 02:57:54 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   2 04/28/17 02:57:54 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   2 04/28/17 02:57:54 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   2 04/28/17 02:57:54 host/I-12345CV3EABF@STAGE.example.com
   2 04/28/17 02:57:54 host/I-12345CV3EABF@STAGE.example.com
   2 04/28/17 02:57:54 host/I-12345CV3EABF@STAGE.example.com
   2 04/28/17 02:57:55 host/I-12345CV3EABF@STAGE.example.com
   2 04/28/17 02:57:55 host/I-12345CV3EABF@STAGE.example.com
   2 04/28/17 02:57:55 I-12345CV3EABF$@STAGE.example.com
   2 04/28/17 02:57:55 I-12345CV3EABF$@STAGE.example.com
   2 04/28/17 02:57:55 I-12345CV3EABF$@STAGE.example.com
   2 04/28/17 02:57:55 I-12345CV3EABF$@STAGE.example.com
   2 04/28/17 02:57:55 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 I-12345CV3EABF$@STAGE.example.com
   3 05/28/17 14:01:39 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   3 05/28/17 14:01:39 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   3 05/28/17 14:01:39 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   3 05/28/17 14:01:39 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   3 05/28/17 14:01:39 host/i-12345cv3eabf.stage.example.com@STAGE.example.com
   3 05/28/17 14:01:39 host/I-12345CV3EABF@STAGE.example.com
   3 05/28/17 14:01:39 host/I-12345CV3EABF@STAGE.example.com
   3 05/28/17 14:01:39 host/I-12345CV3EABF@STAGE.example.com
   3 05/28/17 14:01:39 host/I-12345CV3EABF@STAGE.example.com
   3 05/28/17 14:01:39 host/I-12345CV3EABF@STAGE.example.com

Похоже ли, что он обновил билет 28 мая, но каким-то образом удалил учетную запись сервера?

Установленные пакеты SSSD и ADCLI:

# rpm -qa | grep sssd
sssd-client-1.13.3-56.el6.x86_64
sssd-ipa-1.13.3-56.el6.x86_64
sssd-proxy-1.13.3-56.el6.x86_64
python-sssdconfig-1.13.3-56.el6.noarch
sssd-common-pac-1.13.3-56.el6.x86_64
sssd-krb5-1.13.3-56.el6.x86_64
sssd-krb5-common-1.13.3-56.el6.x86_64
sssd-ldap-1.13.3-56.el6.x86_64
sssd-common-1.13.3-56.el6.x86_64
sssd-ad-1.13.3-56.el6.x86_64
sssd-1.13.3-56.el6.x86_64


# rpm -qa | grep adcli
adcli-0.8.1-1.el6.x86_64

И sssd.conf:

[sssd]
domains = stage.example.com
services = nss, pam, ssh
config_file_version = 2
default_domain_suffix = main.example.com
full_name_format = %1$s@%2$s

re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))

[domain/stage.example.com
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
cache_credentials = false
ad_domain = stage.example.com
ldap_id_mapping = true
krb5_realm = STAGE.example.com
default_shell = /bin/bash
ad_gpo_access_control = permissive
override_homedir = /home/admin/%u

И krb5.conf:

[logging]


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

[libdefaults]
 default_realm = STAGE.EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = true


clockskew = true
proxiable = true

[realms]

 STAGE.EXAMPLE.COM = {
  kdc = 172.31.1.252
  kdc = 172.31.0.252

  admin_server = 172.31.1.252
  admin_server = 172.31.0.252
 }

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

Есть предложения по устранению этой проблемы?

Это должно произойти автоматически, но вам необходимо установить adcli. sssd просто разветвляется и запускает adcli для выполнения обновления.

Я только что понял, в чем моя проблема, после нескольких месяцев существования этой проблемы.

Я не назвал свой сервер server.my.domain.com а вместо этого было просто server. После изменения имени, выхода из королевства и возвращения в него, adcli update работает без проблем.

Вы также можете настроить свой сервер (-ы) AD в качестве источника времени NTP, потому что, если часы ваших клиентских машин слишком сильно рассинхронизируются, они не смогут аутентифицироваться / обновляться, и это может происходить намного чаще, когда все виртуализируется без собственного оборудования RTC.

У меня такая же проблема, я добавил PTR запись в DNS. Я определил это по:

msktutil --auto-update -verbose 

Моя среда содержит SSSD с Samba.