Kerberos is an example of something that just works but is not for the lazy. It was clearly designed by Engineers and not Kool Kidz. The infrastructure required to make it work is not completely trivial but it is free in nearly all senses of the word.
If you can't be arsed to get clocks in sync and DNS to work properly then this is not for you but then neither is any sort of reasonably useful IT related stuff.
Kerberos is a mythical Greek dog and Dramatis Personae is a Latin phrase adopted by theatre and the main text is in English. The canonical justification text (cited above) is clearly an Engineer's work.
This is a very nice exposition of the problem statement. However --
"Athena: You could solve the problem clumsily by requiring the mail server to ask for a password before I could use it. I prove who I am to the server by giving it my password.
Euripides: That's clumsy all right. In a system like that, every server has to know your password. If the network has one thousand users, each server has to know one thousand passwords. If you want to change your password, you have to contact all servers and notify them of the change. I take it your system isn't this stupid."
-- if this isn't a problem for you, as it isn't (or can't really be worked around) on a decentralized network like the internet, then Kerberos seems like an over-engineered marvel for a bygone era. For a closed intranet though, like universities or corporate networks, Kerberos is still around.
Kerberos 5 is somewhat distributed—"realms" loosely map to domains. Kerberos's architecture is very similar to Shibboleth, which is web-based and has a certain level of popularity.
> Charon uses the username to look up your password. Next Charon builds a packet of data that contains the ticket-granting ticket. Before it sends you the packet, Charon uses your password to encrypt the packet's contents.
> Your workstation receives the ticket packet. You enter your password. Kinit attempts to decrypt the ticket with the password you entered. If kinit succeeds, you have successfully authenticated yourself to Charon. You now possess a ticket-granting ticket, and that ticket can get you the other tickets you require.
In this system Kerberos needs to know your plaintext password, no? How was this problem solved?
This is a great high level guide but not so useful when it comes to setting up Kerberos.
Some of the typical issues are: 1. ensuring time synchronisation 2. dealing with the woeful error messages from Kerberos and AD. 3. configuring Firefox to do Kerberos auth. 4. tweaking Windows AD and Gpol/Registry to allow or disallow certain algo strengths. 5. ensuring names (host and principal and server) agree precisely (including case) between the ticket and the AD attributes and various config files.
6. dealing with bugs and other incompatibilities in Windows (e.g. ktpass) and Linux/Unix implementations. (thankfully mostly historical now). 7. firewalls (host and network)
I really should write up these in more details but in the meantime probably the best docs can be found on the official Kerberos site and within MS technet.
Absolutely. I have a maxim - "Time and DNS - come back when both are fixed"
Nowadays good sources of time are "free" - use them. If you can't manage your DNS then hand in your nerd card. You should have A->PTR->A record sorted. The Windows DNS and DHCP make this embarrassingly easy to get right. Be careful about using OpenDNS and co which will happily respond to incorrect queries with their own IP addresses.
For docs on using krb and Samba and co. see Gentoo and Arch wikis - lots of info there.
At what level do you want to understand things? I feel that getting the basics is best done by trying it out yourself, though a badly configured public server can be used to attack other people, so be mindful of who has access to your server when you're trying things out. If you just want the theory, Wikipedia is a pretty good resource for technical things.
If you just want to see how DNS works, set up a server yourself. You could start with a simple caching one like unbound, and then get yourself a domain and set up a real server (eg. nsd or bind) for that. You could for example use Hurricane Electric's free DNS service as your main nameservers and make use of zone transfers and notifications to keep things up-to-date from your local server, giving you a small-scale "real-world" DNS setup.
DNS is a server that translates domains to IP addresses. A DNS entry maps domain name to some various properties like "A entry", "AAA entry", "CNAME entry", etc., most of which I don't know what they do. DNS servers are linked together by magic, to provide a somewhat-eventually-consistent global domain->IP mapping.
What I want to know:
How the whole thing works, what DNS properties ("entries") mean exactly and why, and eventually how to run my own DNS server.
Thanks for the tips, sounds like a good starting point.
And what if i somehow landed a job at a small office without any expert knowledge (only from tinkering with my own unix machines since years) and now i need to set up a simple DNS in a virutal machine of us ?
We have all clients in one network. So i really need only a simple DNS without any complex setup. But sadly i cant find any good tutorial what i have to expect and be aware of. All i can find are some three line tutorials (do this and then this and here you go, now you have a DNS), but not more. Cant you point me to some good guide ?
dnsmasq is simple enough. If you just need to define some local names, you can literally just install it and configure those addresses in /etc/hosts on the same machine. The server will pick them up automatically and serve them as A records.
Nice card. Those two crosses probably tell a story.
DNS is really just a fancy address book. My point above was really aimed at AD sysadmins - if you have AD then you will also have MS DNS which is very easy to setup compared to say BIND or PowerDNS (my weapons of choice).
Your nerd card is old. Older than the WWW. No wonder you need to grok DNS. (Jokes aside this nerd card is a really cool format. May I should put this in the about me section somewhere)
I wouldn't shy away from serving SNTP from virtualized Windows domain controllers nowadays--it's okay for its designed purpose, although "good" time probably involves appliances / GPS or somesuch radio devices.
But if that isn't good enough for you, you can easily replace w32time with the reference NTP implementation, which is what I do to all of my Hyper-V hosts and physical forest root PDCs:
I feel like the subset of computing applications that require accurate time doesn't intersect with the amount of applications where you want to rely on a raspberry pi and can get signals directly from a satellite (i.e. not in a DC).
A more practical example would probably just be to find a professionally hosted stratum 1 server to sync off.
Aye, all good and worthy things. A Windows domain, however, typically establishes its own hierarchical time system (PDCe -> RWDCs (+ clients) -> RODCs (+ clients)), with only the PDCe relying on external time sources. Windows SNTP is not really designed for high precision/high accuracy anyway, so, you just kinda go "meh good enough" not too far into the adventure. Also the time management CLI tools stink.
Whoever was responsible for naming the service "w32time" and naming the command to manage the configuration of that service "w32tm" should be fired out of a cannon into the sun.
"Disclaimer: we cherry-picked our best NTP server; our other servers aren’t as accurate. Our Hetzner server, via IPv6, is typically +4ms/-4ms, and via IPv4 is typically +10ms/-10ms, our AWS server +20ms/-20ms, and so is our Microsoft Azure server."
FWIW, I'm not aware of any Windows krb5 cases that rely on PTR records. In short: the client decides on the name of the service it wants to access, and then it asks the KDC for a ticket to talk to that service.
I cut my teeth on Kerberos at CMU (sparc, old MacOS), then Solaris and Linux in the age where you might run into Heimdal, and then digging into it on Windows and AD revealed a lot of surprises, although not all of them were bad... er, that is to say, the errors were not more inscrutable than other implementations'.
Most of the problems in Windows AD land revolved around bad time, and ignorant sysadmins butchering servicePrincipalName/userPrincipalName values.
I was going to mention the same guide. Not only it has been really helpful but also the Kerberos/Lovecraft analogies are spot on. Also, it has the best introduction I've ever read in a technical manual:
When HP Lovecraft wrote his books about forbidden knowledge which would reduce the reader to insanity, of "Elder Gods" to whom all of humanity were a passing inconvenience, most people assumed that he was making up a fantasy world. In fact he was documenting Kerberos.
What is remarkable is that he did this fifty years before kerberos was developed. This makes him less of an author, instead: a prophet.
What he wrote was true: there are some things humanity was not meant to know. Most people are better off living lives of naive innocence, never having to see an error message about SASL or GSS, never fear building up scripts of incantations to kadmin.local, incantations which you hope to keep evil and chaos away. To never stare in dismay at the code whose true name must never be spoken, but instead it's initials whispered, "UGI". For those of us who have done all this, our lives are forever ruined. From now on we will cherish any interaction with a secure Hadoop cluster —from a client application to HDFS, or application launch on a YARN cluster, and simply viewing a web page in a locked down web UI —all as a miracle against the odds, against the forces of chaos struggling to destroy order. And forever more, we shall fear those voices calling out to us in the night, the machines by our bed talking to us, saying things like "we have an urgent support call related to REST clients on a remote kerberos cluster —can you help?"
ELI5? This is a at-least a 3rd-grade reading level and I mean at-least.
I've looked into Kerberos before. Who hasn't looked into Kerberos is the IT department at my day job. You can walk up to an open Ethernet jack, declare yourself root and access anyone's NFS.
Don't worry. All we make is security processors, the things that do the bulk encryption for the internet. No problem. Leave that source code flapping in the wind.
"While this topic probably can not be explained to a 5 year-old and be understood, this is my attempt at defragmenting documentation"
Regarding the unsecured network jack problem, I once saw it "fixed" at $large_oil_company by using stickers above all the Ethernet jacks saying in angry letters "It is forbidden to connect non-$company machines!".
This is not shocking many large companies I have worked with are the same way. This is one of the hidden dangers of many big data implementations I have seen. super secure with kerb enabled free for all with out.
Kerberos assumes there's a out-of-band mechanism for bootstrapping and establishing trust with every participating server. More specifically: Every server needs to have a unique secret (symmetric) key, which needs to be known by the KDC. Distributing these symmetric keys is outside the scope of the Kerberos protocol, and often done manually.
If you're performing cross-domain authentication, there's also another level of interdomain keys needed to create referral tickets, which are also symmetric and need to be trusted.
This works well in an organizational setting, where everything in the known-world is centrally managed. It doesn't scale well to the entire Internet.
Kerberos is mutual authentication with a bootstrapping overhead on the client side (you need keys, and distributing them can be challenging) and makes heavy use of accurate time. It doesn't adapt well to that sort of use case, and works better with an IT department backing it up. The protocol itself is just fine over an untrusted network -- that's what it was built for -- but that's not the usage you see. The SSO aspect of Kerberos is very nice, but OAuth and others push more toward "federated identity," a slightly different take on the same thing.
Even beyond that, it's heavy. Arguably, that OAuth stuff is a bit lighter. That's more a taste thing. Kerberos, when executed well (see Google pre-BeyondCorp/etc), is awesome.
A very minor nit, the client (user) does not require bootstrapping or pre-shared keys. If your DNS for the realm you are kiniting to are correct, you can get your client keys without any client side configuration.
When a client kinits, no validation of the kdc is performed. As the kdc never gets the password, the most an invalid can do is issue you invalid keys, which will get denied by any service that sees them.
Severs require keytabs to validate user keys, and these can be much harder to distribute to all your servers that need to authenticate users.
Kerberos doesn't work through NAT, for one. (I think that there might have been an extension, but it never took off.)
Open ID Connect will support the more complicated "delegation" scenarios that Kerberos enabled. Think, authentication across multiple service boundaries. That kind of thing.
I used it to connect to campus servers back in college, through my home NAT.
There is an optional field in the Kerberos ticket that can contain your client address, as an additional point of validation to prevent certain classes of replay attack. That particular feature can conflict with NATs. But it's optional.
My favorite when talking Kerberos back in school days - the "Ticket Granting Ticket". Which the author goes over. Love me some ticket granting tickets!
MAD uses it rather extensively. That's one of the reasons you see a confusing mashup of case in docs relating to AD. DNS: example.co.uk, Kerberos Realm: EXAMPLE.CO.UK To add confusion there is the NETBIOS shortname for a "Domain" (which is really a realm) which in this case could be EXAMPLE or EX or whatever.
As a Linux sysadmin/user in an MS world, I have pretty much managed to Kerberize everything I can get my hands on via Samba (winbindd). I also use Evolution with the EWS plugin to get to Exchange and use Kerberos to auth to that. All my sshd's support GSSAPI auth and so does PuTTY for my Windows loving colleagues. Firefox and Chrome(ium) support GSSAPI.
Whether I like it or not, MAD is here to stay and so I have to embrace it .... 8)
I have fully documented build docs for several Linux distros for our corp needs. I now have feature parity with Windows for our use cases. A bit more testing and tweaking needed to cover edge and corner cases, then I will get a volunteer to try it out, etc etc. One step at a time.
Anyway, to answer your question: everywhere that has AD installed or FreeIPA and the like and of course places that use Kerberos itself eg MIT!
Microsoft Active Directory (ADS) uses Kerberos for single sign on. As soon as you login to an domain you get a Kerberos ticket. So it's actually quite wide spread.
Yes, I have setup Java and Apache servers to do authentication with Kerberos. The support is quite mature now. The only hassles tend to be with the Windows servers and PCs deprecating weaker algorithms which require tweaking krb5.conf and occasionally digging into AD attributes.
It's used in research computing environments. My university used to to authenticate to the general access clusters, and a you'll find references to its use in government labs if you dig in their support pages. Additionally, if AFS [0] is being used, it's a safe bet that Kerberos is also present.
When AFS was created the Kerberos spec wasn't final yet. So they use something similar called a PAG (instead of a ticket). You need a special tool to convert your Kerberos ticket to an AFS PAG. Real support for Kerberos V is something that's on the wishlist for quite some time.
All of our linux/freebsd boxes on our network at work must be hooked up to kerberos. most of the day I don't have to type my password for anything HTTP/SSH unless it's for sudo.
How do you integrate kerberos sso and http? Is there web browser support? The last time I looked at this, I could get sso to work with apache on the server side and windows (internet explorer) clients - but for anything else I don't think I got ticket forwarding etc to work? (Granted this is a long while back).
I'd love to hear a few keywords about your stack (heimdal/mit, web server(s), directory server(s) etc)?
Have a look at the Arch and Gentoo wikis both have a lot of notes.
I wrote this: https://wiki.gentoo.org/wiki/Kerberos_Windows_Interoperabili... It is a little out of date (I keep the latest set of notes on our corp wiki) but will get you most of the way there. The notes on the Arch wiki also have some quite up to date notes on using pam_mount and getting mount.cifs working with Kerberos (ie I've read the docs and experimented, so you don't have to)
winbindd in Samba 4.x is really rather good and will happily manage the Kerberos side of things for you for a minimal setup cost. If you find yourself following a howto that starts whittering on about using setspn.exe on a DC then run away! I recently noticed that SSSD is available on rather a lot of Linux distros and is well respected. Must have a look.
As I mentioned in another thread there is a lot of support for SSO with Kerberos/GSSAPI in nearly everything you can get your paws on. Even Nagstamon can do it! Chrome on Windows - Group Policy, Chrome or Chromium on Linux - policies in a JSON file in a certain location, Firefox - about:config - you can send out FF settings with a file (can't remember the name), IE - Group Policy. PuTTY for ssh. OpenSSH client and server. Squid. Apache, nginx, IIS all do it.
I login to this laptop using my AD username and password. If the wifi is a bit slow and winbindd can't get to the domain then it uses a cached (cryptographically hashed) version of my password to allow me in or not. When it finds the DC (VPN or LAN) then it is able to fix up my Kerberos ticket cache on my behalf.
I know for a fact (by direct experience) that this all works on Gentoo, Arch and Ubuntu (Xenial and Trusty). Any Unix-alike distro that can run mitkrb or heimdal and Samba 4 should be able to do all of this.
No, just as a AD member server. Without winbindd, samba has to fall back to the libc pam/nss functionality which is not as full-featured as the one provided by winbindd. So there's some performance benefits which might or might not matter for you, but there's also some cases that don't work at all without winbindd; at least we were unable to allow non-domain clients (e.g. personal laptops) access to a smb share without winbindd.
If you dig into this topic you can find mails from samba core devs on samba-technical saying that you REALLY should run winbind for a samba AD member server.
We use Keycloak (hooked up to FreeIPA) which will try to authenticate against Kerberos and then fall back to a regular login screen or a cookie for more limited SSO. The actual web apps are configured with OpenID Connect or SAML and don't know anything about Kerberos.
FreeBSD, OpenSSH, Apache mod_kerb2 (and mod_auth_ldap for authorization), Active Directory.
1. install server
2. msktutil tool joins machine to domain (simple tool; no dependencies) and now you have /etc/krb5.keytab file
3. minor configuration for base OS -- LDAP using keytab instead of bind user with static password, etc
4. webservers just need an HTTP principal keytab created (simple msktutil command, then extract it from the /etc/krb5.keytab file into a file apache can read/write)
5. I can ssh to every server without a password after running "kinit" on my macbook
6. it just works and it's reliable, time tested, and secure.
Interesting! Why did your company choose Kerberos over, say, SSL/SMIME certificates?
(Honest question, because I had the impression that typically, companies base their PKI on SMIME certificates, because it is easier to setup than an OpenPGP based PKI, and because these certs are supported by most email clients out of the box, in addition to HTTPS and SSH.)
I'm only chiming in here because we do the same. We have an AD! Bizarrely it is actually rather easy to use despite the nightmare of rubbish docs on t'internets. We use winbindd (SSSD is another well respected option - must try it) and the algorithmic idmap backend which guarantees the same uid/gid on all Linux boxes. winbindd also sorts out Kerberos keytabs for the machine itself ("join the domain") and logged in used via winbind's NSS and PAM add ons. Finally, winbind can cache logins for offline logins which is nice for say this laptop that I am using right now.
All browsers that I use (IE, Chrom{e|ium}, Firefox) support GSSAPI. Apache, IIS, nginx support GSSAPI. OpenSSH and PuTTY support GSSAPI. There is a lot of support for it out there. Oh and of course Squid for all your proxy needs and HAProxy works as expected (I use it to front Exchange to get PCI DSS compliance even for Exchange 2010 - but that is more a TLS thing). Evolution EWS works through that lot using Kerberos for auth for the full Exchange client experience, including calendaring, without needing Outlook.
Kerb is for auth whereas SSL is for encryption. I think you may be confusing use cases a bit. To be fair all that stuff can be a bit confusing and there is a lot of overlap. SSL can be used for identity proof (often proof by assertion) and so can Kerberos (proof by faith in the rest of your realm)
SSSD has been really, REALLY good to my group... except during initial setup. The logging failed me several times in trying to track down problems. The biggest one was when one of the our sysadmins had mistyped "default". Everything appeared to be connecting, getting data from LDAP... and then SSSD would crash with an empty log file.
It worked fine on all of our other machines with the incorrect spelling. The versions of Debian and SSSD were the same. I assume some library was different, but I never found it. I eventually noticed the typo, fixed it, and everything started working.
That was a couple of years ago. After those initial debugging hurdles, it has "just worked" through upgrades and major software changes.
I'm probably jinxing it by praising it. I'm now expecting SSH to stop working on every machine.
Trust me, setting up sssd with debug logging etc. is like the second coming of Jebus compared to ye olde school way of doing it with pam_krb5 + nss_ldap..
Can't say either way, but after spending a few minutes Googling S/MIME support, it seems completely incompatible with most web browsers and web email services. The only exception appears to be Office 365 with Internet Explorer on Windows? While end-to-end encryption of emails is nice, I'm not sure the benefits outweigh the drawbacks, unless required by regulation. It'd be nice if more webmail providers and browser makers supported S/MIME, especially considering new privacy rules in the EU...
When you go to an arcade or carnival, there are many people playing many games and it can be hard to make sure everyone gets to play how much they paid. So you get a ticket from the ticket booth, take it to the game you want to play, put it in, and play! If you don't pay, you won't get a ticket. Without a ticket, you can't play. So even though the games don't use money directly, they know that your ticket means you paid. Other kids can't steal your tickets because when you buy them, the ticket guy prints your fingerprint on each one!
Sometimes, adults like to make work into games too. So they make tickets for using their computers and they get those tickets at the Kerberos booth.
