ACD Linux System Administration notes

ACD Linux System Administration

Kerberos Testbed

8-August-2002

Background

We (ACD and ASP) hosted a Kerberos testbed during July-August of 2002 in order to prove MIT Unix Kerberos interoperability with Windows 2000 Active Directory and workstations. The work is being done by a group consisting of Tim Fredrick, Wendy Derman, and Rich Johnson. Others who are interested in participating in the Kerberos Development Team are welcome to join.

The purpose of this testing is to faciliate a plan whereby UCAR central authentication (what we currently know as the "gatekeeper password") can be moved to Kerberos. And then pass-through authentication would be done with the Active Directory so that it uses the same password. The benefit to users is that they will have fewer passwords to remember in our work environment. And the benefit to the organization is that we will have better security through stronger password policies across the board.

This testing should also verify that no domain functions are affected adversely by kerberos authentication to an MIT KDC as opposed to the Domain Controller.

While not on a specific timeframe, the timing is important as many groups have already expressed concern over the increasing number of passwords in our organization. My eventual goal is to create a proposal which we can jointly deliver to the DSAC and to the CSAC technical committees at UCAR.

A general description of our goals and of Kerberos technology in general (along with some terminology definitions) exists at http://acd.ucar.edu/~fredrick/linux/kerberos.

Our Setup

Windows 2000 domain: asptest.asp.ucar.edu (NetBIOS name="ASPTEST")
Unix Krb5 Realm: ACD.UCAR.EDU
asp-authtest.asp.ucar.edu: A 400MHz Pentium II running Windows 2000 Server, Service Pack 2. This machine is considered the primary DC for the "ASPTEST" domain. It uses itself for DNS in order to take advantage of Dynamic DNS. It is also a WINS server for the testbed.
asp-authtest2.asp.ucar.edu: A 233 MHz Pentium II running Windows 2000 Server, Service Pack 2. This machine is considerered a DC for the "ASPTEST" domain. The CIT domain has 3 DC's, so we wanted to have other DC's in the testbed configuration. It uses asp-authtest for DNS.
acd-hopper.asp.ucar.edu: This is a 200MHz Pentium Pro machine with Windows 2000 workstation, Service Pack 2. Is is the "workstation" that will be used for testing.
diskserver2.acd.ucar.edu: This is a 400MHz Celeron PC with Redhat Linux 7.3 and MIT Kerberos RPM's (krb5-server-1.2.5-6). It is our KDC which serves the ACD.UCAR.EDU Kerberos Realm. I decided to place it on the acd.ucar.edu rather than the asp.ucar.edu subnet in order to reflect that the CIT domain controllers are on a separate subnet from the workstations that currently authenticate against them.
acd-vmtest.acd.ucar.edu: This is a VMWare Windows 2000 which runs on acd-doctor.acd.ucar.edu, a 2.4 GHz Pentium IV running Redhat Linux 7.3. The workstation has Windows 2000 Service Pack 3 and is considered the most "disposable" of our testbed platforms.

Can Standalone Workstations authenticate against MIT Krb5 (same DNS zone)?

Dates: August 2-12, 2002
Background

The simplest Windows to Kerberos authentication to understand is Standalone workstation to Unix Krb5 KDC. This is described in the Microsoft Interoperability document under the heading "Using an MIT KDC with a Standalone Windows 2000 Workstation". This is not pass-through authentication -- rather it is a modification of a Windows 2000 workstation on a workgroup with local accounts. By following Microsoft's instructions, those local accounts can be made to authenticate against the KDC instead of against the local password settings in its SAM.

Testing:

For the test, I followed the instructions in the MS Interoperability document:
Suppose our password is "mypass". On the KDC I created a host principal for the computer:
      kadmin -q "ank -pw mypass host/acd-vmtest.acd.ucar.edu"
On the Windows workstation I set the kerberos realm and added a kerberos realm to KDC mapping:
      ksetup /setdomain ACD.UCAR.EDU
      ksetup /addkdc ACD.UCAR.EDU diskserver2.acd.ucar.edu
      
On the Windows workstation, I set the local machine account password to "mypass" and rebooted:
      ksetup /setmachpassword mypass
After the reboot, I mapped Realm users to local user accounts (the 2nd command maps by username -- a realm user of "wderman" for example will map to the local account "wderman":
      ksetup /mapuser fredrick@ACD.UCAR.EDU fredrick
      ksetup /mapuser * *
      
Initially, the test didn't work -- authentication seemed to be happening, but not login. My theory was that the initial "Ticket Granting Ticket" (TGT) exchange was successful but then we had failure during the next step when the KDC sends the initial TGT back to the Windows workstation. The 2nd step involves encryption -- either des-cbc-crc or des-cbc-md5. On a hunch, I grabbed the simpler kdc.conf and krb5.conf files from a Redhat 6.2 install of krb5 1.1 and that worked, both on a Redhat 6.2 server (voyager.acd.ucar.edu) and on our testbed server running Redhat 7.3 (diskserver2.acd.ucar.edu). (see below for the configuration files) So I tried to integrate changes back into the resulting configuration from the default krb5 setup, and it continued to work. So I'm not sure yet why we didn't get the initial configuration to work.

Test Results

Can a workstation user with a local account use a KDC password? Yes, but he/she must choose the Kerberos realm name under "Log on to:"
Can a workstation user with a local account use a local password? Yes, but he/she must choose the local account name under "Log on to:"
How to change a user's password on the KDC: Run kadmin.local on the Unix based Kerberos server. And then use the cpw command. For example "cpw fredrick".
Can a workstation user with a local account change his KDC password? With this configuration, no. The CTRL-ALT-DEL method of changing a password results in the error message: "Unable to change the password on this account due to the following error: 1311: There are currently no logon servers available to service the logon request. Please consult your system administrator".
Does authentication work from a workstation in a different DNS domain than the KDC?:

Configuration Files

Can Standalone Workstations authenticate against MIT Krb5 (different DNS zone)?

Dates: August 8, 2002
Background

We were able to get a standalone Windows workstation in the acd.ucar.edu DNS zone to authenticate against a kerberos REALM ACD.UCAR.EDU served by a KDC also in the DNS zone acd.ucar.edu. Next, I tested a workstation (acd-hopper.asp.ucar.edu) located in the asp.ucar.edu DNS zone.

Testing

I did a clean install of Windows 2000 workstation and SP2 on acd-hopper.asp.ucar.edu. I configured it using the steps above to authenticate against the ACD.UCAR.EDU kerberos Realm.

Results:

The test worked, but not initially. I ended up having to set the primary DNS suffix of asp.ucar.edu by right clicking My Computer, Selecting Properties, then the Network Identification Tab. From there I clicked on Properties, and then "More..." and set the zone to asp.ucar.edu. Without doing this, the workstation seemed to want to set its zone to the realm name ACD.UCAR.EDU which prevented authentication from happening.
I also had to add to the krb5.conf file entries to map machines in zone asp.ucar.edu to the ACD.UCAR.EDU realm. These go in the [domain_realm] section and the updated krb5.conf file is listed at this link:

/etc/krb5.conf
[Screen Shot]

Can a workstation on a domain authenticate against MIT Krb5 (same DNS zone)?

Dates: August 12, 2002
Background

This is the test of "pass-through" authentication. We want to see if a workstation which is a member of a domain and which does not have local computer accounts can use pass-through authentication to autheticate a regular user against a kerberos REALM. Once that authentication happens, is the user a part of the Active Directory?

Testing

This test uses the ASPTEST domain served by the DC's asp-authtest.asp.ucar.edu and asp-authtest2.asp.ucar.edu. Right now, asp-authtest is its own DNS server, so for a workstation to be on the ASPTEST it must use asp-authtest (128.117.34.17) as the DNS server and as the WINS server. I used VMWare to create a clean Windows 2000 installation on a machine called acd-vmtest2.acd.ucar.edu. I then joined acd-vmtest2 to the ASPTEST domain.
Helping the Windows KDC trust the Kerberos Realm
On the DC (asp-authtest), for the ASPTEST domain, I used the following command to set up the configuration for the MIT Kerberos realm and restarted.
C:> ksetup /addkdc ACD.UCAR.EDU diskserver2.acd.ucar.edu
I started the Domain Tree Management tool. Clicked Programs, then Administrative tools, and then Active Directory Domains and Trusts.
I Right-clicked on Properties of your domain, then selected the Trust tab and press Add. I used the password which will be used on the Linux side below...
I created a trusted domain relationship with the MIT Kerberos realm. When prompted if this is a non-Windows Kerberos Realm, I clicked OK.
Help the MIT Kerberos Realm to trust the Windows KDC: I set up cross-realm principals in the MIT realm:
      % Kadmin -q "ank -pw password krbtgt/ASPTEST.ASP.UCAR.EDU@ACD.UCAR.EDU"
      % Kadmin -q "ank -pw password krbtgt/ACD.UCAR.EDU@ASPTEST.ASP.UCAR.EDU"
Create Account Mapping for "fredrick": I created an account mapping for Fredrick by:

Starting 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".
Located the account "fredrick", right clicked and selected "Name Mappings"
Click the "Kerberos Names" mappings tab.
Add the principle from the Unix based MIT realm (fredrick@ACD.UCAR.EDU).
Configure Workstation On the workstation (acd-vmtest2), all I had to do was run these commands and restart:
ksetup /addkdc ACD.UCAR.EDU diskserver2.acd.ucar.edu
To test that we are actually on the domain, I set up my "fredrick" profile to mount a shared folder \\asp-authtest\shared\fredrick as Z:\.

Results

It seemed to work. Here is the krb5 log from diskserver2:

Aug 12 09:37:26 diskserver2 krb5kdc[30051](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): ISSUE: authtime 1029166646, etypes {rep=3 tkt=1 ses=1},
   fredrick@ACD.UCAR.EDU for krbtgt/ACD.UCAR.EDU@ACD.UCAR.EDU
Aug 12 09:37:26 diskserver2 krb5kdc[30051](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): ISSUE: authtime 1029166646, etypes {rep=1 tkt=1 ses=1},
   fredrick@ACD.UCAR.EDU for krbtgt/ASPTEST.ASP.UCAR.EDU@ACD.UCAR.EDU
Aug 12 09:37:26 diskserver2 krb5kdc[30051](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): UNKNOWN_SERVER: authtime 1029166646, 
   fredrick@ACD.UCAR.EDU for LDAP/asp-authtest.asptest.asp.ucar.edu@ACD.UCAR.EDU,
   Server not found in Kerberos database
Aug 12 09:37:26 diskserver2 krb5kdc[30051](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): ISSUE: authtime 1029166646, etypes {rep=1 tkt=1 ses=1},
   fredrick@ACD.UCAR.EDU for krbtgt/ACD.UCAR.EDU@ACD.UCAR.EDU
Aug 12 09:37:27 diskserver2 krb5kdc[30051](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): UNKNOWN_SERVER: authtime 1029166646, 
   fredrick@ACD.UCAR.EDU for HOST/asp-authtest.asptest.asp.ucar.edu@ACD.UCAR.EDU,
   Server not found in Kerberos database
Aug 12 09:37:27 diskserver2 krb5kdc[30051](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
   128.117.33.122(88): ISSUE: authtime 1029166646, etypes {rep=1 tkt=1 ses=1},
   fredrick@ACD.UCAR.EDU for krbtgt/ACD.UCAR.EDU@ACD.UCAR.EDU

I was able to log in and see my shared folder. [Screen dump].

Files

The password problem

It turns out that we need to set up the kadmind daemon on the kerberos server. First I did this:

diskserver2:/var/kerberos/krb5kdc> sudo kadmin.local
Authenticating as principal root/admin@ACD.UCAR.EDU with password.
kadmin.local:  ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
Entry for principal kadmin/admin with kvno 5, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
Entry for principal kadmin/admin with kvno 5, encryption type Triple DES cbc mode raw added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc mode raw added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab.
kadmin.local:

Then I started the daemon:

diskserver2:/var/kerberos/krb5kdc> sudo service kadmin restart
Stopping Kerberos 5 Admin Server:                          [FAILED]
Starting Kerberos 5 Admin Server:                          [  OK  ]

Can a Windows XP Workstation on a domain use pass-through authentication?
Dates:  August 16, 2002

Background

This is another test of "pass-through" authentication.  We were successful in
getting Windows 2000 to authenticate in this way -- so now we want to follow
the same procedure to see if Windows XP Professional can authenticate against
an MIT Kerberos server and then connect to a domain.

In our setup, we have a Windows XP Professional workstation (on a VMWare
undoable virtual disk) installed with
the ACD auto-install disc and then moved to the ASPTEST domain.  There are
no local accounts on the workstation.  The XP computer is on the 33-net which
is a different subnet than the ASPTEST domain.  I set the WINS address
to be that of the ASPTEST domain (128.117.34.17).

Note that the ksetup.exe program is located in the support.cab file in
the \SUPPORT\TOOLS folder of the Windows XP Professional installation CD-ROM.
I ran SUPTOOLS.MSI in the same directory to install all of the support tools.
I then copied C:\Program Files\Support Tools\ksetup.exe into the 
C:\Windows\System32 folder.

Testing


 start/cmd
 ksetup /addkdc ACD.UCAR.EDU diskserver2.acd.ucar.edu
 (we get a warning:  "Note:  /addkdc requires a reboot to take effect
on pre-SPI Win2000 computers".  So presumably we don't have to reboot
Windows XP Professional).
 I logged onto the ACD.UCAR.EDU kerberos realm with my kerberos
password, and it appeared to authenticate me and log me in exactly as with
Windows 2000.
 I was able to print to printers that were previously installed (and
served by Samba running on a Linux machine on the CIT workgroup).
 I was also able to change my ACD.UCAR.EDU kerberos realm password
with CTRL-ALT-DEL.