ACD Linux System Administration notes

ACD Linux System Administration

Kerberos Notes

8-August-2002
Kerberos Testbed Notes are here

Goals

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 at http://web.mit.edu/kerberos/www/#what_is as well as a somewhat dated 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:

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.

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

Definitions

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 or TGT.
- 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 command:
```
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 OU basis.
Help the Windows KDC trust the MIT Kerberos Realm:
- On the domain controller for cit.ucar.edu, use the following command to set up the configuration for the MIT Kerberos realm (the computer will need to be restarted before this setting will be used):
```
C:> Ksetup /addkdc UCAR.EDU kdc.realm.ucar.edu
```
- Start the Domain Tree Management tool. Click Programs, then Administrative tools, and then Active Directory Domains and Trusts.
- Right-click on Properties of your domain, then select the Trust tab and press Add.
- The passwords used in this step are described below when we help the MIT Kerberos Realm to trust the Windows KDC.
- Create a trusted domain relationship with the MIT Kerberos realm. When prompted if this is a non-Windows Kerberos Realm, click OK.
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 Features".
- 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 "fredrick@ucar.edu". 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 here.

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.