We’ve just migrated a set of Centos6/7 hosts from pure OpenLDAP based authentication to IPA and Kerberos. What surprised us is that a local root user on an IPA enrolled host can use ‘su’ to become an IPA user.

If the chosen IPA user is currently logged in, the “local root” can use the IPA users Kerberos credentials to move around hosts in the domain as the IPA user. Kerberos ticket forwarding allows the local root user to assume the IPA users identity on any permitted host in the field until it can no longer renew the Kerberos ticket (7 days by default)

It feels like a backward step. We have developers who need root on test vm’s

If an IPA admin happens to be logged into the test VM, then the developer can sudo su to the IPA admin and then log into the IPA servers with Kerberos delegation. They can then make changes to the IPA servers, all without ever needing the IPA users' password.

I can see how the Linux security model allows this, but it feels like a flawed situation.

Is there any way to safely have local admins that aren't domain admins? (Even if it only applies to Centos7 hosts. Centos6 is on the way out here)


Well, yeah. PAM allows root to do whatever it wants, including assume the identity of other users.

If an ipa admin happens to be logged into the test vm then the developer can sudo su to the ipa admin and then log into the ipa servers with kerberos delegation.

Don't do that. Use a separate admin account for identity services, and forbid it from logging into random app hosts. It is just as good of an idea as not using a Windows AD DS domain admin account as your daily driver, just don't.

Perhaps use freeipa host based access control to keep the identity admins from touching application hosts, and vice versa.

Also, only give root to people you trust with all the accounts that can log into a host. This may mean replacing root access with less privileged users and scripts to do specific things as root. Or, provide network disconnected hosts without IPA auth for untrusted root users. Less convenient, but they can't pass the ticket on a system without Kerberos.

|improve this answer|||||
  • I was afraid this might be the situation. Makes me wonder if windows has the same issue. Perhaps local admin on windows isn't as privileged as root on linux? – Fenster34 Nov 10 '19 at 18:50
  • 1
    Privilege escalation exists on both platforms: adsecurity.org/?p=2362 Comparing which operating system is "better" at security is not very productive. Properly implementing least privilege is. – John Mahowald Nov 10 '19 at 19:45
  • I’ve been digging around and it seems things arent as bleak as I first feared. It seems Kerberos ticket granting tickets arent automatically copied by ssh to the new host. So if i log into a box managed by someone i dont fully trust, they dont automatically get my tgt. I need to test this out tomorrow but i think as long as i dont run kinit on the less trusted host, its admin cant impersonate me? It does mean i cant allow these hosts access to the file servers as that would encourage users to have tgt’s on this box. – Fenster34 Nov 11 '19 at 19:46
  • I wouldn't say can't impersonate just because you didn't forward. root has unlimited access. Any secret in memory or on disk isn't safe from root. Possibly no one's going to use this to escalate or move laterally, but are you going to risk it? – John Mahowald Nov 11 '19 at 20:44
  • True but i think the only secret that gets sent is the service ticket for the host. I dont think they can use that to authenticate as me against any other service or host principal. I agree the risk of misconfiguration makes it likely that the tgt will get forwarded at some point. Going to accept your answer though as its clearly the right way to go. Thanks for helping out – Fenster34 Nov 11 '19 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.