Kerberos Sub-Realm Authentication for Branch Offices
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Deploying domain controllers in branch offices poses security risks due to potential physical insecurity, compromising the integrity of the entire network, especially when using Kerberos protocols that rely on a central authentication authority.
Innovation Solution
Implementing Kerberos sub-realms with distinct key version numbers and branch IDs to differentiate between virtual realms, allowing each branch office to operate as a virtual realm, thereby isolating and securing authentication and authorization processes, and limiting privileges to reduce the risk of domain compromise.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If branch offices deploy local KDCs to provide quick authentication, then authentication speed is improved, but security risk increases due to untrusted locations
Solution Approach 1:
The patent segments the authentication system into multiple virtual realms, each with its own KDC. Each branch office is assigned a unique virtual realm identifier (branch ID) that creates an isolated authentication domain. This segmentation allows local KDCs to operate independently with limited privileges, providing fast authentication while containing security risks to specific virtual realms rather than compromising the entire network.
2Reliability
If a single central KDC is used for authentication, then security is improved through centralized control, but authentication speed deteriorates due to remote access requirements
Solution Approach 1:
The system divides the centralized authentication authority into multiple virtual realms with local KDCs. Each virtual realm maintains its own KDC that can perform authentication locally without requiring clients to reach the central KDC, thereby improving authentication speed while maintaining security through virtual realm isolation.
Solution Approach 2:
The virtual realm acts as an intermediary layer between local KDCs and the central authentication authority. Local KDCs operate within their virtual realms and can grant access to services without direct exposure to the central KDC, providing both local authentication speed and centralized security control through the virtual realm mediation.
3Ease of operation
If branch KDCs are deployed with full privileges, then authentication functionality is improved, but system integrity deteriorates due to potential compromise
Solution Approach 1:
The patent implements separate virtual realms for different branch offices, where each virtual realm has its own KDC with limited privileges. The virtual realm structure isolates the impact of any single branch KDC compromise, preventing domain-wide integrity failures while maintaining full authentication functionality within each virtual realm.
Solution Approach 2:
Each virtual realm is configured with local-specific KDCs that have privileges tailored to their specific branch office requirements. The local KDCs can perform authentication and authorization for their respective virtual realms independently, providing appropriate functionality without requiring excessive privileges that could compromise overall system integrity.
Data Source
AI summary
Branch domain controllers (DCs) contain read only replicas of the data in a normal domain DC. This includes information about the groups a user belongs to so it can be used to determine authorization information. Password information, however, is desirably replicated to the branch DCs only for users and services (including machines) designated for that particular branch. Moreover, all write operations are desirably handled by hub DCs, the primary domain controller (PDC), or other DCs trusted by the corporate office. Rapid authentication and authorization in branch offices is supported using Kerberos sub-realms in which each branch office operates as a virtual realm. The Kerberos protocol employs different key version numbers to distinguish between the virtual realms of the head and branch key distribution centers (KDCs). Accounts may be named krbtgt_<ID> where <ID> is carried in the kvno field of the ticket granting ticket (TGT) to indicate to the hub KDC which krbtgt′ key was used to encrypt the TGT.


