Cron always uses the same methods for determining access, regardless of account type. One check is the cron.allow file, another goes through PAM:
- Cron calls PAM to run the 'account' (accounting/authorization) stack in
- That file, either directly or indirectly (via include/substack), will contain a module belonging to your domain client – e.g.
pam_sss if you use SSSD,
pam_winbind if you use Samba/Winbindd, or
pam_ldap if you use nslcd.
pam_sss contacts SSSD, which makes the decision whether to allow user
test@domain access the
crond service. How it makes that decision depends on parameters in
sssd.conf – for example, when joined to an Active Directory domain, it might even read your group policies and decide based on whether Windows would grant the user the "Batch Logon" permission.
(I just assume it's SSSD because of the username syntax and because RHEL created it.)
As a side note, there's no difference between local users and domain users from the technical side. Even the
...@domain syntax is merely a fancy username that SSSD generates; it is nothing special to the rest of the system. So if you use cron.allow you generally have to include it.
As a side note to the side note, with SSSD it is possible to have asymmetric name→UID→name translation (e.g.
test@domain → 12345 →
domain\test). You don't know whether cron stores the username verbatim or reconstructs it from the UID. Therefore you should run
getent passwd <uid> with the numeric UID and include the resulting username in cron.allow if it's different from the original username (i.e. you should list both versions).