Cron всегда использует одни и те же методы для определения доступа, независимо от типа учетной записи. Одна проверка - файл cron.allow , другая проходит через PAM:
- Cron вызывает PAM для запуска стека учетных записей (учета / авторизации) в
/etc/pam.d/crond
.
- Этот файл, прямо или косвенно (через include / substack), будет содержать модуль, принадлежащий вашему клиенту домена - например,
pam_sss
если вы используете SSSD, pam_winbind
если вы используете Samba / Winbindd, или pam_ldap
если вы используете nslcd.
pam_sss связывается с SSSD, который принимает решение, разрешить ли пользователю test@domain
доступ к сервису crond
. Способ принятия этого решения зависит от параметров в sssd.conf
- например, когда он присоединен к домену Active Directory, он может даже прочитать ваши групповые политики и решить, основываясь на том, предоставит ли Windows пользователю разрешение "Пакетный вход".
(Я просто предполагаю, что это SSSD из-за синтаксиса имени пользователя и потому, что RHEL создал его.)
Как примечание, нет никакой разницы между локальными пользователями и пользователями домена с технической стороны. Даже синтаксис ...@domain
- это просто причудливое имя пользователя, которое генерирует SSSD; в этом нет ничего особенного для остальной системы. Поэтому, если вы используете cron.allow, вы, как правило, должны включить его.
В качестве дополнительного примечания к дополнительному примечанию, с SSSD возможно иметь асимметричное имя → UID → перевод имени (например, test@domain
→ 12345 → domain\test
). Вы не знаете, хранит ли cron дословно имя пользователя или восстанавливает его по UID. Поэтому вы должны запустить getent passwd <uid>
с числовым UID и включить полученное имя пользователя в cron.allow, если оно отличается от исходного имени пользователя (т.е. вы должны перечислить обе версии).