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

Процедура SSSD для сохранения присоединения при переименовании компьютерного объекта AD

Стрельба на Луну с этим вопросом здесь. В Windows, если вы присоединяете клиента к домену AD, а затем, если вы хотите переименовать компьютерный объект, вы можете сделать это «плавно», не нарушая членство клиента в AD. Я хочу реализовать ту же функциональность с SSSD в Linux (RHEL в моем случае) для хостов, соединенных с царство (или, возможно, вручную через чистая реклама присоединиться).

Но я хочу, чтобы соединение было постоянным и универсальным. Было бы хорошо, если бы это было автоматически, но это нормально, если мне нужно выполнить некоторые локальные команды. Меня беспокоит, что если я присоединюсь, а затем изменю имя компьютерного объекта, информация, хранящаяся локально из соединения, не будет соответствовать и нарушит ее.

СЦЕНАРИЙ

Итак, для примера, допустим, я хочу переименовать HOST7_CLONE в HOST7. Есть две версии этого сценария:

  1. Только компьютерный объект в AD с именем «HOST7_CLONE» переименовывается в «HOST7».
  2. И компьютерный объект в AD, и локальное имя хоста Linux переименовываются с «HOST7_CLONE» на «HOST7».

Первый вопрос: нужно ли менять локальное имя хоста Linux, если объект компьютера переименовывается, или это отдельные соображения? Во-вторых, даже если нет необходимо скорее желанный # 2 создает дополнительные проблемы?

Предполагая, что не нужно переименовывать локальный хост Linux, для упрощения предположим, что имя локального хоста Linux остается прежним (# 1).

ТЕХНИЧЕСКИЕ ПОДРОБНОСТИ

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

name: host7_clone
objectGUID: x
userAccountControl: 69632
codePage: 0
countryCode: 0
lastLogon: 132307605314743751
localPolicyFlags: 0
pwdLastSet: 132307506720641880
primaryGroupID: 515
objectSid: z
accountExpires: 9223372036854775807
logonCount: 14
sAMAccountName: HOST7_CLONE$
sAMAccountType: 805306369
dNSHostName: host7_clone.core.org
servicePrincipalName: HOST/host7_clone.core.org
servicePrincipalName: HOST/HOST7_clone

В частности objectGUID и servicePrincipalName выглядеть актуально. Для objectGUID Я ожидал, что это останется таким же после переименования объекта, надеюсь, независимый и уникальный значение независимо от имени объекта компьютера AD. Я искал путь внутрь krb5.conf и sssd.conf указать objectGUID однако вы хотели выполнить привязку явно и ничего не нашли.

Итак, это привело меня к тому, что, как я ожидал, будет главной проблемой, связанной с servicePrincipalName соответственно обновите имя объекта компьютера на новое. Лучшее, что я смог найти для решения этой проблемы, - это команда, которую я нашел для ручного управления этим с помощью команда kerberos: kadmin rename_principal. Однако это кажется немного эзотерическим, и я боюсь начинать возиться с билетом Kerberos.

Для objectSid, это SID самого объекта компьютера AD? Если да, будет ли objectSid лучшим уникальным идентификатором, чем GUID объекта?

Вероятно, я слишком усложняю это, но просто хотел немного провести мозговой штурм. Ключевым моментом здесь является то, что я хочу оставаться с нами. Отключение и повторное присоединение потребует ручного вмешательства при аутентификации; тогда как даже если мне нужно выполнить некоторые другие ручные команды (например, kadmin), я могу написать сценарий и автоматизировать это без вмешательства человека (надеюсь, по крайней мере, это цель).

В конце концов, у меня до сих пор нет концептуального пути вперед относительно того, какую процедуру необходимо выполнить, чтобы хост оставался присоединенным к домену, даже если он переименован.

Предложения будут очень признательны.