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.
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.