ACD Linux System Administration
Kerberos Testbed Notes are here
I'd like to create an MIT Kerberos server such that we can
authenticate an AD user against the MIT Kerberos server.
Authentication would pass through the MIT Kerberos server
while authorization would be handled by the DC.
Here is a drawing of what I have in mind
What is Kerberos?
There is a somewhat good explanation on the Kerberos web site
http://web.mit.edu/kerberos/www/#what_is as well as a
FAQ. It is a form of authentication that has been thought out over
the years but is difficult to explain in a few words. In the Windows
world it is faster than NTLM and contains features not possible with NTLM.
The following 3 parties are involved:
Thinking of the Myth of Kerberos (and forgetting most of it :-) ), I constructed
a scenario. The KDC is played by Jupiter, the Kerberos Security Principal
is played by the oarsman, and the Validating Server is played by Kerberos, the
three-headed dog and guard of Hades. The resulting drawing
- A user who is trying to gain access to resources on a target server
- The target server that needs to validate a user's identity before giving access
- A special server that holds credentials for both the user and the target server so
that it can perform the necessary authentications to authorize the user's access.
- authentication: The process by which a user's
identity is verified (usually by a password exchange)
- authorization: Once authenticated, authorization
is the determination of what what the user (or computer) is
permitted to do.
- MIT Kerberos: Unix-based Kerberos -- see
http://web.mit.edu/kerberos/www/. Also see
my MIT Kerberos v5 server under RedHat Linux
- MS Kerberos: Microsoft implements kerberos 5 (RFC 1964) in the Active Directory. As a means of
authentication it is meant to replace NTLM (Windows NT) style authentication.
- KDC: Kerberos Key Distribution Center. A key is pretty much the same as a ticket.
The KDC authenticates and also issues tickets (in Windows 2000). Some kerberos servers
use 2 separate servers for authentication and distribution. The Windows 2000 key distibution
service is called KDCSVC and runs on DC's.
- Ticket Granting Service: One of the two functions of a KDC. When a security principal
attempts to access a service, it presents a ticket which originally came from the KDC.
This ticket authorizes a user to access the server.
- Authentication Service: The other function of a KDC. Before the user gets a ticket,
he or she must be verified to be an acceptable security principal. The security database is
used -- AD for instance. When a user is authenticated, the KDC issues a ticket-granting ticket
- TGT: This is a Ticket-Granting-Ticket. It is a way that the user is
pre-authorized. When the user wants to access a server, his client-server ubmits a TGT to
the KDC to quickly get a ticket for the server he is trying to access.
- Local Security Authority: portion of Windows that calls upon login services
(WINLOGON and NETLOGON) to get security credentials from users. The user-side is the
Local Security Subsystem (LSASS.EXE) and the server side is the Security Reference Monitor (SRM).
- Security Principal: This is an "entity" to be authenticated. Typically
security principals are users or computers that desire access to network resources.
- Realm: A database of credentials. A windows domain is really a realm and
vice versa. Security Principals are ojects within a realm.
- ticket: Encrypted information used by all parties to authenticate a security
principal. When the principle attempts to access a server, a ticket must be presented.
- Validating Server: This is the server which the security principal is trying to
access. In AD, this can be a Windows 2000 member server that offers a service. When a user
attempts to access that service, his client server submits a ticket for that server which it
previously obtained from the KDC. The member server validates that ticket determining that
only an authorized security principal can be its holder.
- KRBTGT Account: This is a special account. The password associated with that account
is combined with the realm name in order to create a ticket-granting ticket.
- Session Key: Random number generated by KDC when it builds a ticket. It is
the shared secret that the KDC, the client, and the validating server have in common.
- Time Stamp: Date/Time that the ticket was issued and the Date/Time that the ticket
will expire .
Steps to creating pass-through Authentication
[Click here for a printable form of these instructions]
So what we want to achieve is pass-through Authentication. Microsoft
describes the process here The article is long but the only part we're
really intersted in is the section "Setting Trust with a Kerberos Realm".
So to do pass-through authentication, we'll have to:
- Configure each workstation: Each workstation has to have the
MIT Kerberos Realm defined for it. If the MIT Kerberos Realm is called
UCAR.EDU, then I think this is done with the ksetup
C:\ Ksetup /addkdc UCAR.EDU kdc.realm.ucar.edu
ksetup sets a registry value -- if that's all it does, then we could
look into a group policy object (GPO) to do the setting on an OU by
- Help the Windows KDC trust the MIT Kerberos Realm:
- Help the MIT Kerberos Realm to trust the Windows KDC:
Use the following MIT Kerberos administration commands to create cross-realm
principals in the foreign MIT realm (note that the program is typically run on a UNIX system):
% Kadmin -q "ank -pw password krbtgt/CIT.UCAR.EDU@UCAR.EDU"
% Kadmin -q "ank -pw password krbtgt/UCAR.EDU@CIT.UCAR.EDU"
- Create Account Mappings: We may have to create account mappings between
domain accounts and MIT Kerberos Realm accounts, even though we are using
common usernames. These mappings are set up the Active Directory Management Tool.
Once the mappings are set up, users should be able to change their Kerberos
realm passwords from the CTRL-ALT-DEL sequence.
- Start the Directory management tool. Point to programs, then
Administrative tools, then Active Directory Users and Computers.
- Start advanced features by clicking "View", and then "Advanced
- Locate the account to which you want to create mappings. Right click
to view "Name Mappings".
- Click the "Kerberos Names" mappings tab.
- Add a principle from the Unix based MIT realm. For example
"firstname.lastname@example.org". Can we automate this in some way or do it by
batch? This will be a lot of clicking for the hundreds of accounts
that might be in a typical division.
Configuring a Unix Kerberos 5 Server under Redhat Linux
There are notes on the RedHat page
here and then I have written a document on how I set up diskserver2
to serve the realm ACD.UCAR.EDU
Problems and Concerns
- Apparently, Exchange doesn't support Kerberos -- it always uses
NTLM. If users don't know their Windows password and we are authenticating
against an MIT Kerberos REALM, they won't be able to use Exchange. A similar
problem exists for Microsoft Macintosh file/print services. Also the problem
exists for Remote Installation Service (RIS), ActiveSync, and II's ftpd.
Also exists for telnetd. All use NTML authentication.
- Downlevel clients use NTLM -- for example Windows NT. They are left
out of the picture as far as Kerberos Authentication goes. Hopefully they
can still use their CIT password in the same manner as we do right now.
- How much kerberization do we want to do? It seems like it might be
possible, for instance, to set it up so that rlogin, telnet, etc., would
work from Windows into Unix platforms as long as forwarding tickets were
issued by the MIT kerberos server. But according to the Microsoft article,
there is a fair amount of setup to make this happen. For the first pass,
I am just interested in authentication in order to take advantage of a
common username/password identity between the Windows and Unix universes.