FreeIPA for amateurs: why?

You may have noticed I've posted a bit about FreeIPA recently, and also when I first set it up.

Other smart folks have blogged about using FreeIPA before (note some of those links are old and refer to bugs that have long since been fixed, and workflows that have been long since improved - the FreeIPA guide for Fedora 18 is probably the best entry point at present, though it misses improvements between 3.1.x from F18 and 3.3.x in F20). But one thing I didn't explain very well yet, and I'm not sure any of the other posts entirely covers, is why you'd want to run FreeIPA in the first place.

I didn't have much of an answer at the time I first installed it - I was trying to fix a single specific problem, and didn't really have a conception of what else it would give me. It's something that's particular unclear if you're just an amateur hobbyist, not a sysadmin in a large environment. Why would you care about FreeIPA if all you have is <10 boxes and one real user?

Believe it or not, there are a ton of good reasons. I've really enjoyed having FreeIPA set up since I got it working, and wouldn't go back to living without it.

Let's recap briefly what FreeIPA is for. Very approximately, it's a centralized identity store and access control system for your network. Instead of creating user accounts and configuring authentication and access control system by system, using passwd files and ssh keys and various other mechanisms, you set up a single server which knows who exists, manages their passwords, manages authentication and decides who gets to connect to what. (If you know what Active Directory is, it's basically that, only it's on Linux and written by Red Hat so of course it's much better).

You might think, like I did, that this isn't much of a big deal. You know your account name, you know your password. You set up your password every time you set up a new box, copy some ssh keys around, and you're fine, right?

Well...kinda, yeah. When's the last time you changed your password? It's kind of a pain in the ass, right? You have to remember to change it everywhere. Probably not worth bothering with, anyway. It's a pretty strong password.

Well, yeah, it's pretty strong, but then you probably had to type it into that Windows terminal in a hotel that one time. Did you check all the USB ports? Want to bet much on the hotel 'sysadmin''s security procedures?

So the most obvious thing a centrally managed system gets you is, change your password once, it's changed. On every system enrolled in your FreeIPA domain. That makes it a lot easier to change passwords, so you're going to do it more often, so you're not going to get hacked by the bellhop of that hotel.

That's just the start of it, though. FreeIPA also does access control. You can set up admin users of various types and split up admin permissions between them on a network-wide basis - maybe your personal account needs to be root on your client systems, but doesn't really need to be an IPA admin, or be the admin user for your server boxes? Split that stuff up, improve security. You can trivially set up guest accounts, for instance, that can get a login on all or some of your client boxes but can't get in to any others or do various other things, like sudo.

Ah, sudo. You can manage your sudo policy centrally in FreeIPA. That's really damn useful. It requires a bit of one-time manual configuration when you enrol a new client still in 3.x, unfortunately, but I hope they make that go away soon. And of course the policy can be fine-grained and complex, like your account can sudo anything without a password on (unimportant hosts) but can only sudo these commands with a password on (important hosts).

We're still just scratching the surface, though!

One of the really nice things FreeIPA does is give you a Kerberos setup that works out of the box.

(waits for screaming to die down)

Yes, that's about how I feel about Kerberos too. No, don't run away. That's why FreeIPA is great - you don't really have to completely understand Kerberos to use it. Heck, I still don't really understand Kerberos and I'm using it. You just need to follow a few monkey guides here and there.

The reason people are always telling you to use Kerberos is it does single sign-on, and yes, that's a great reason and really cool the first time you see it working. There's another reason which gets slightly buried in the detail, though, and that is that well-configured Kerberos means the box running the service you're accessing never has to see your password. Not in the clear, not hashed, not in a TLS session, not at all. Clients talk to the Kerberos server (so, the FreeIPA server in this case), and so do the app host boxes - the two don't talk directly, and the client never sends its password directly to the server. There are Kerberos methods which involve the client sending a password to the host and the host verifying it with the FreeIPA server, but that's not the best way.

The next plan I have for my setup is to make the Kerberos server accessible from the public internet, and enable 2FA. The result of that will be that whether I'm on my local network or not, I can auth to my server and then get SSO to all my enabled services (including email), using 2FA. That's pretty neat!

FreeIPA also provides all sorts of other services, almost as a coincidence. It kinda needs to handle TLS certificates as a consequence of its intended capabilities, for example - so as a byproduct, you can very easily issue a certificate for any of your FreeIPA-enrolled machines, signed by the FreeIPA domain CA, and you have nice centralized control over them - issue them, revoke them, renew them, track them, and all your enrolled systems will trust them (so long as you follow the instructions in my last post, until FreeIPA 4.x arrives). Obviously you'll need to get your certificate issued by a public CA for services you intend to expose to the general public, but for ones that will only be accessed by your own machines that are enrolled in your FreeIPA domain, this is easier, cheaper and probably better (as you control the whole chain).

It really is an awesome system, both in capability and implementation - I've had very few problems with it since I deployed it, it rapidly promoted itself to the mental category of 'things that I almost unconsciously expect to just keep working'. I'd keep a local root password on all your systems - I use randomly-generated passwords stored in a password manager - for emergency recovery purposes, but you'll likely never or very rarely have to use it. In case you're worried about offline operation, don't - SSSD caches credentials for use locally until you can connect to the server again (so, for instance, you can always log in to your laptop when you can't access your network or the internet at all).

If you have more than a couple of machines and/or you host a few services for yourself, I'd really recommend looking into it.