1

I have a CentOS 6.4 machine which is set up with pam_ldap and pam_krb5. It is configured to use our Active Directory servers for authentication. I can SSH into the machine using AD accounts.

I have not set up any kind of keytab file.

I set up a crontab for an AD user on the CentOS machine, which writes some data into a file every minute. The folder the job is writing into is on an NFS share, and the folder is locked do so that only members of a specific AD group can access it. The AD user in question is a member of the group, and has no local account on the CentOS machine.

How is cron continuing to have access to run the job as the AD user when the AD user is not logged on?

Joseph Quinsey
  • 222
  • 6
  • 17
Peter Loron
  • 168
  • 2
  • 8

2 Answers2

2

If you are using kerberos enabled NFSv4 ( and I would be highly surprised if you are ) then you need to create some kind of user keytab and use something like kstart at the beginning of the cron job to obtain a kerberos tgt. Otherwise, you should not need any kerberos credentials to access the NFS filesystem.

This problem has been around forever in AFS environments and has some standard solutions. Generally you create an alternate principal to put in the keytab and map both principals to the same unix uid. (i.e. I create a keytab on the cron system for fred/cron@MAGIC.WONDER.DOG ) and use an appropriate tool to map the kerberos principal to the same unix uid at fred@MAGIC.WONDER.DOG.

0

The folder the job is writing into is on a NFS share

NFSv3? There is no auth taking place. NFSv3 takes the client's word that the user is who they say they are. It's also totally insecure - if I have root access to a box I can su and access a user's files on an NFS share even if the share is root_squash.

Cron is not actually running the job as DOMAIN\user, it's running it as the UID # which is all NFSv3 cares about.

Now if you were mounting a CIFS/NFSv4 share it should fail.

TheFiddlerWins
  • 2,973
  • 1
  • 14
  • 22