Сценарий

Question 1

Похоже, это было вызвано тем, что информация о группе кэшировалась во время входа в систему в /var/cache/samba/netsamlogon_cache.tdb. Я предполагаю, что хотя '-n' предписывал winbind не кэшировать свои запросы к LDAP, наличие информации о членстве в этом файле TDB было достаточным, чтобы все испортить.

Answer

Похоже, это было вызвано тем, что информация о группе кэшировалась во время входа в систему в /var/cache/samba/netsamlogon_cache.tdb. Я предполагаю, что хотя '-n' предписывал winbind не кэшировать свои запросы к LDAP, наличие информации о членстве в этом файле TDB было достаточным, чтобы все испортить.

Question 2

Мне удалось раздобыть потерянную статью Марчина (https://marcinm.co.uk/group-membership-not-updating-in-winbind/) спросив его по электронной почте. Поскольку я уверен, что это поможет хотя бы некоторым людям, вот его полный пост в блоге:

Сценарий

Файловый сервер, на котором работает smbd security=ads(т.е. он действует как член домена), пользователь подключается к общему ресурсу Samba и получает правильное подтверждение членства в группе при первом подключении, и после этого оно никогда не обновляется.

Первопричина

Samba обновляет членство в группе, когда оно вычисляется контроллером домена AD, и оно вычисляется только тогда, когда пользователь входит в систему на сервере, на котором запущены smbd и winbind. Что запускается wbinfo -aтолько при входе в систему SMB с использованием Kerberos. Поскольку это серьезное ограничение, означающее, что членство в группе не будет известно вообще на машинах, на которых пользователь никогда не входит в систему, был разработан резервный код членства в группе, который извлекает членство в группе пользователя из AD без входа пользователя в систему, но поскольку учетная запись машины, используемая winbind, не имеет прав запрашивать членство в группе пользователя, она считается нестабильной, а ее результаты ненадежными. Поэтому winbind никогда не полагается на него — он вызовет его, когда членство в группе вообще неизвестно, но он никогда не будет использоваться для обновления кэшированного членства в группе. В результате этого — в некоторых сценариях winbind фиксирует членство пользователя в группе один раз и никогда не обновляет его после этого.

Невозможно отключить кэширование членства в группах, т. е. нет способа отключить такое поведение, поместив строку в smb.conf. Обратите внимание, что это не проблема Samba, а проблема дизайна AD, такое поведение соответствует поведению Windows, которое фактически заключается в том, что членство в группах AD обновляется, когда пользователь проходит аутентификацию во время входа в систему.

Как принудительно обновить членство в группе для пользователя

Членство в группе кэшируется в файле с именем netsamlogon_cache.tdb, который может быть исследован с помощью tdbtool (все версии Samba) или net cache samlogon(Samba 4.7 или новее). Удаление кэшированных записей из этого файла запускает однократное обновление членства в группе путем вызова кода резервного обновления и помещения его результата обратно netsamlogon_cache.tdb- и после этого они снова кэшируются навсегда.

способ tdbtool:

$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)

добавьте \0к SID и заключите его в кавычки:

$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"

Членство в группах будет обновлено в первый раз, когда это потребуется ОС, подождите несколько минут, пока файл tdb не будет заполнен,

способ чистого кэширования samlogon:

$ net cache samlogon list|head
SID                                                Name                                     When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725     DOM\user.name                            Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432     DOM\user.name2                           Tue Apr 27 02:13:33 PM 2018 BST

$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725

То же, что и раньше — членство в группах будет обновлено в первый раз, когда это потребуется ОС, подождите несколько минут, пока файл tdb не будет заполнен.

Answer

Мне удалось раздобыть потерянную статью Марчина (https://marcinm.co.uk/group-membership-not-updating-in-winbind/) спросив его по электронной почте. Поскольку я уверен, что это поможет хотя бы некоторым людям, вот его полный пост в блоге:

Сценарий

Файловый сервер, на котором работает smbd security=ads(т.е. он действует как член домена), пользователь подключается к общему ресурсу Samba и получает правильное подтверждение членства в группе при первом подключении, и после этого оно никогда не обновляется.

Первопричина

Samba обновляет членство в группе, когда оно вычисляется контроллером домена AD, и оно вычисляется только тогда, когда пользователь входит в систему на сервере, на котором запущены smbd и winbind. Что запускается wbinfo -aтолько при входе в систему SMB с использованием Kerberos. Поскольку это серьезное ограничение, означающее, что членство в группе не будет известно вообще на машинах, на которых пользователь никогда не входит в систему, был разработан резервный код членства в группе, который извлекает членство в группе пользователя из AD без входа пользователя в систему, но поскольку учетная запись машины, используемая winbind, не имеет прав запрашивать членство в группе пользователя, она считается нестабильной, а ее результаты ненадежными. Поэтому winbind никогда не полагается на него — он вызовет его, когда членство в группе вообще неизвестно, но он никогда не будет использоваться для обновления кэшированного членства в группе. В результате этого — в некоторых сценариях winbind фиксирует членство пользователя в группе один раз и никогда не обновляет его после этого.

Невозможно отключить кэширование членства в группах, т. е. нет способа отключить такое поведение, поместив строку в smb.conf. Обратите внимание, что это не проблема Samba, а проблема дизайна AD, такое поведение соответствует поведению Windows, которое фактически заключается в том, что членство в группах AD обновляется, когда пользователь проходит аутентификацию во время входа в систему.

Как принудительно обновить членство в группе для пользователя

Членство в группе кэшируется в файле с именем netsamlogon_cache.tdb, который может быть исследован с помощью tdbtool (все версии Samba) или net cache samlogon(Samba 4.7 или новее). Удаление кэшированных записей из этого файла запускает однократное обновление членства в группе путем вызова кода резервного обновления и помещения его результата обратно netsamlogon_cache.tdb- и после этого они снова кэшируются навсегда.

способ tdbtool:

$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)

добавьте \0к SID и заключите его в кавычки:

$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"

Членство в группах будет обновлено в первый раз, когда это потребуется ОС, подождите несколько минут, пока файл tdb не будет заполнен,

способ чистого кэширования samlogon:

$ net cache samlogon list|head
SID                                                Name                                     When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725     DOM\user.name                            Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432     DOM\user.name2                           Tue Apr 27 02:13:33 PM 2018 BST

$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725

То же, что и раньше — членство в группах будет обновлено в первый раз, когда это потребуется ОС, подождите несколько минут, пока файл tdb не будет заполнен.

Question 3

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

Answer

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

Question 4

У меня было что-то похожее. Чтобы исправить проблему, я запустил "authconfig --disablecache --update". Конечно, это замедлило вход в систему.

Answer

У меня было что-то похожее. Чтобы исправить проблему, я запустил "authconfig --disablecache --update". Конечно, это замедлило вход в систему.

Сценарий

решение1

решение2

Сценарий

Первопричина

Как принудительно обновить членство в группе для пользователя

способ tdbtool:

способ чистого кэширования samlogon:

решение3

решение4

Связанный контент