6

Suppose I have a corporate domain mydomain using MS Active Directory. In the domain I have the users myuser and youruser. Now, on one specific Ubuntu machine mymachine, myuser has sudo rights, and does sudo su youruser (or sudo -u youruser sh). Since myuser has the necessary sudoers config, he does not need to enter youruser's password, and will effectively become youruser on that machine.

  1. What kind of youruser privileges will myuser have at this point? Obviously, if youruser also has a home directory on the machine, myuser can now access it and read his private local files. But what will happen if trying to access a network domain resource using kerberos, samba etc? I guess since he has never entered youruser's password he is not authenticated as a domain user, does not have a kerberos ticket etc. So if there's a network service that checks group memberships for his user id, will that also fail? How does this work? Is he considered to be a different user, say, mymachine\\youruser as opposed to mydomain\\youruser?

  2. Suppose there's a web service running as a daemon on the machine, using a dedicated domain user myserviceuser. If this web service needs to access network resources, i.e., authenticate with Kerberos, how should the daemon be set up, for example from an upstart script? Normally you start it using something like sudo -u myserviceuser <cmd>, but given the above assumptions, will this grant the web service any rights to access network resources? Shouldn't the password for this user have to be entered somewhere?

2 Answers 2

2

There's not nearly enough clear documentation on this stuff IMO.

  1. You are right - if a service is protected by kerberos then su/sudo is not sufficient to bypass the necessary authorisation (UNLESS the target user has a cached ticket because they are currently logged on, or a keytab). Most resources (eg local filesystem) rely on uidnumber and gidnumber to identify a user, and can be bypassed by root/sudo access

  2. This is a fun one that i an dealing with presently at work. Say a service account apache needs to access a kerberised NFS share. You need to export a keytab for apache to the local filesystem and source that when the service starts, periodically renewing its ticket via perhaps cron. RHEL7 has gssproxy, which appears to simplify this but i haven't got to that point yet.

A keytab is effectively a saved credential. If someone can access it, they can masquerade as that user. Exporting a new keytab in IPA and AD changes the account's password.

Microsoft kerberos is slightly different but most rules still apply.

4
  • Thanks. This info led me to this article itadmintools.com/2011/07/creating-kerberos-keytab-files.html. I'll probably look into creating a keytab etc, but to get something basic up and running, am I reasonably correct in thinking that a cron job that periodically runs kinit would be sufficient to get the user authenticated? And for basic testing this cron job could in theory contain the password in plain text? A keytab is obviously a better solution when it comes to managing the password itself, but ignoring that for a moment, is running kinit sufficient?
    – JHH
    Jun 24, 2015 at 12:36
  • If we're still talking about the web service user, yes you would use kinit to obtain a tgt. If kinit supports being passed a password (on my phone, not sure offhand ) then it should work. Make sure you post some results for the next person in your shoes.
    – Andy
    Jun 25, 2015 at 8:58
  • Well, some flavors of kinit seem to support passing password through stdin and some don't, but echo $PASSWORD | kinit works on my system (again, I should really look into the keytab thing :))
    – JHH
    Jun 25, 2015 at 9:10
  • 1
    @JHH, you might also consider k5start as an alternative to using kinit directly, as this might be more robust for keeping active a long-lived tgt for a service. You can install this (for example) as a system service with an appropriate script in /etc/init.d (or equivalent for your distribution's init system). Sep 17, 2015 at 15:12
0

I am in a similar situation with autofs home directories on Kerberized NFSv4 directories:

  • If I am coming from another kerberized machine, I can SSH to the target machine with a forwardable TGT and my account on the target machine logs in normally with my automounted home directory.
  • If I am not coming from another kerberized machine, I can (subject to local ACL) log in with a password to that machine and have PAM generate a ticket. The automounted home directory also comes up in this situation.
  • I cannot log into this machine if I am dependent on the account having an entry in ~/.ssh/authorized_keys because the home directory is inaccessible to the SSH daemon on the target. It's not inaccessible because it's unmounted, rather it's inaccessible because the SSH daemon does not have the TGT to access the home directory containing the authorized_keys file.
  • Once I have gained access to a machine, regardless of sudo permissions, I cannot sudo su to another user's account without their home directory being inaccessible -- again I do not have their TGT.
  • On that machine, I can su to their account and have their home directory available at login if I have their password because logging in through su passes through PAM and that gives me a TGT that will allow automount to succeed.
  • On architectures where the TGT is stored in an accessible keystore (like a system keychain), the TGT is not erased by logging out unless one does an explicit kdestroy. Now I can sudo su to that user's account and the automount home directory will succeed.

The common thread here is that the TGT isn't accessible unless a forwardable ticket is transferred from another machine or a the user has the password to get the ticket with some form of login or kinit.

Allowing that service accounts may occasionally host users (say, for centralization of complex configuration like ~/.kube/), it's insufficient to put a keytab in the account directory for the same reason that authorized_keys does not work. It's also not sufficient to depend on tickets with a long lifetime and cron jobs to replenish a system keychain because a reboot would wipe the keychain and it would be unavailable until the next cron invocation (which would likely be some time). It's also a mess to set up cron like that across a cluster of machines.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .