1

It's probably something fundamental but I can't find a certain statement. Why can't KDC authenticate then provide the service ticket directly. Is it about security or performance or some other thing? Since users don't log in each time they request a service and assumably they will keep logged in for a long time, AS doesn't seem so busy. Why do they have to be seperated?

3 Answers3

2

When you get a ticket initially (by requesting one from the KDC) you get back a TGT, or Ticket Granting Ticket. This is then used to contact the Ticket Granting Server to request application or other tickets.

In every system I've had personal experience with, the KDC and TGS were the same machine, in fact the same application. However, 100% of my experience lies in the open source MIT and Heimdal services. In this case, once again in my experience, both services are performed in the same binary.

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
2

Thank you both for pointing that KDC mostly is just one machine. I did some more reading and I found out why it is imperative for protocol. What I mentioned before is possible. Since AS and TGS use the same database, AS can provide service tickets but it is used for users who want just one service(but it breaks Single Sign-On). I failed to understand TGTs were the thing that kept people logged in.

Also TGS provided service tickets have to be delivered to Application Server in two minutes. While TGTs have longer lifetime and they could be replayed

Thanks to perfect tutorial here

0

It’s to allow for redundancy, I believe — you could theoretically have a bunch of TGSes and a bunch of KDCs (as they have different workloads), although I’ve never seen a setup where each KDC isn’t also a TGS and vice versa.

Mo.
  • 2,166
  • 16
  • 9