3

Could someone summarise why realms are necessary in Kerberos and the advantages of the concept.

I'm struggling to isolate everything I know / beginning to understand into some well defined points for revision. My research just uncovers articles with so much depth can barely make sense of it. I understand what they are. I am aware that using them means that data is distributed thus advantageous in the event of a system failure and that it is easier to manage many small realms instead of one huge one.

Thanks in advance

1 Answer 1

2

Since your question is rather broad, I will attempt an equally broad answer.

Authentication is often put in terms of a security boundary or scope. For example, a State-issued Driver's license is a credential used to validate your identity and is scoped to have meaning ultimately to the issuing State (though others may chose to trust that credential).

A Kerberos Realm is, in broad terms, a modeling of administrative scope.

You might also liken realms to similar technical administrative boundaries: a DNS namespace and it's subdomains ... or an IP namespace and it's subnets. Each of these have various technical implications whether to use a large, top-level space or carve out a group of smaller spaces - but one of their chief functions is to model administrative scope.

In the case of Kerberos, the key goal of realms are to make a larger administration space (say 10,000s or 100,000s of usernames) smaller by dividing them into sub-realms along organizational or functional boundaries.

Other important implications:

  • ability to delegate administration of a realm to a group other than a core admin group
  • ability to distinguish one user of a realm from another
  • ability to dictate the trust policy for users of one realm by another (cross-domain trust)
  • ability to set configuration parameters on one realm that might differ for another

(Aside: it so happens that a Kerberos Realm may coincide with a DNS domain. This isn't required, but can make discovery of Kerberos realms easier by client software and users; as well as suggest natural "edges" in which to carve your authentication space. This will depend entirely on your authentication/authorization needs)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .