Как модифицировать систему на живом USB во время работы?

Судя по статье , найденной здесь, кажется, проблема устранена, файл sssd.conf теперь выглядит так...

[sssd]
domains = ucera.local
config_file_version = 2
services = nss, pam

[domain/ucera.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local

Изменения:

1. ldap_id_mapping = False— это, я думаю, основное исправление, которое позволяет использовать идентификаторы AD posix ID, а не вычислять их на основе атрибута пользователей AD objectSID
2. Я также добавил настройки ldap_..._...id_number =...и установил их в соответствующие поля атрибутов в AD для пользователей. После выполнения части (1 )UID на машине не изменились. По сравнению с другими sssd -, использующими серверы, у которых не было этой проблемы, единственным отличием в sssd.conf было изменение (1 ). Я думаю, что на других машинах уже было ldap_id_mapping = False, поэтому, когда пользователи AD впервые вошли в систему на этих машинах, они автоматически получили свои идентификаторы AD posix UID. На этом запутанном сервере идентификаторы UID уже были установлены неправильно, поэтому необходимо явно принудительно использовать атрибуты AD uidNumberи gidNumber.

Затем перезапустите службу sssd.

Не очень хорошо разбираюсь в AD и SSSD, поэтому, если я что-то неправильно истолковал, оставьте комментарий, чтобы сообщить мне об этом.