Кто-нибудь здесь видел, как их серверы 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.