Introduction
This step-by-step guide examines the use of the
Kerberos interoperability features with the
Windows® 2000 operating system.
The Windows® 2000 operating system
implementation of the Kerberos version 5 protocol is
designed for interoperability with other security
services based on the MIT Kerberos version 5 reference
implementation. The interoperability objectives for the
Windows 2000 release support the following
configurations:
- A Windows 2000 Server domain controller can serve
as the Kerberos Key Distribution Center (KDC) server
for MIT Kerberos-based client and host systems. UNIX
systems can use kinit and the DES-CBC-MD5 or
DES-CBC-CRC encryption type to authenticate to the
Windows 2000 KDC.
- The Windows 2000 Kerberos Security Support
Provider (SSP) implements the General Security Service
Application Program Interface (GSS API) Kerberos
Mechanism Token formats defined in RFC 1964. Windows
2000 does not provide the GSS API; instead, the
Kerberos support is available to Microsoft Win32®
API-based applications using the SSPI APIs implemented
by the Kerberos SSP. Client applications on UNIX using
GSS API can obtain session tickets to services on
Windows 2000, and can complete mutual authentication,
message integrity, and confidentiality. (Context flags
that are verified are GSS_C_MUTUAL_FLAG,
GSS_C_REPLAY_FLAG, GSS_C_CONF_FLAG, GSS_C_INTEG_FLAG.)
- Windows 2000 Professional clients can be
configured to use a Kerberos realm, with single
sign-on to the Kerberos realm and the local Windows
2000 Professional-based client account.
Interoperability with Kerberos services requires
minor configuration changes from the default
installation. For example, a Windows 2000 workstation
that uses a Kerberos realm must be configured to locate
the Kerberos realm, available KDC servers and available
Kerberos change password servers. Microsoft provides
command-line tools to help with the configuration steps.
These tools are:
- Ksetup. Configures Kerberos realms, KDCs,
and Kpasswd servers.
- Ktpass. Sets the password, account name
mappings, and keytab generation for Kerberos services
that use the Windows 2000 Kerberos KDC.
The Kerberos configuration utilities are available on
the Windows 2000 distribution media, in the
\support\reskit\netmgmt\security folder.
The Kerberos test utilities are available in the
Windows 2000 software development kit (SDK), in the
\mssdk\samples\winbase\security\win2000 folder.
These tools are:
- Gssclient. Tests RFC 1964 interoperability
(gss directory).
- Gssserver. Tests RFC 1964 interoperability
(gss directory).
- Klist. Examines the Kerberos credential
cache.
The Windows 2000 release has some known Kerberos
interoperability limitations. These limitations include
the following:
- Only DES-CBC-MD5 and DES-CBC-CRC encryption types
are available for MIT interoperability.
- Hierarchical realm support for cross-platform
trust between the Windows 2000 and MIT Kerberos realms
is not included; however, transitive trust is
supported between Windows 2000 domains in the domain
tree.
- The KDC does not support post-dated tickets.
- Any upgraded user accounts and the administrator
account in a new domain must have the password changed
before non-Windows Kerberos clients can use them.
Using Kerberos Clients
Creating Computer and User Accounts
Use the Active DirectoryTM service management tool to create
computer and user accounts for the host and user
security principals logging into the Windows 2000
Kerberos domain.
To configure the UNIX hosts
- Use the Active Directory Management tool to create
a new user account for the UNIX host:
- Select the Users folder, right-click and
select New, then choose user.
- Type the name of the UNIX host.
The
account can be created in any container. It might be
useful to create a new organizational unit (OU) and
create the accounts there.
- Use Ktpass to create the keytab file and
set up the account for the UNIX host, and then copy
the keytab file to the UNIX system and merge the
keytab file into /etc/krb5.keytab, as follows:
- Use the following command to generate the UNIX
host keytab file, map the principal to the account,
and set the host principal
password:
C:> Ktpass –princ
host/hostname@NT-DNS-REALM-NAME –mapuser account
-pass password –out unixmachine.keytab
where:
— hostname is
the host DNS name, for example,
foobar.microsoft.com.
—
NT-DNS-REALM-NAME is the uppercase name of
the Windows 2000 domain; for example,
RESKIT.COM.
— account is the user
account for the computer.
— password is a
complex password for the account.
Windows
2000 account names are not multipart as are Kerberos
principal names. Because of this, it is not possible
to directly create an account of the name
host/hostname.dns.com. Such a principal
instance is created through service principal name
mappings. In this case, an account is created with a
meaningful name hostname and a service
principal name mapping is added for
host/hostname.dns.com. This is the purpose of
using Ktpass with the –princ and
–mapuser switches.
- Securely transfer the keytab file
(unixmachine.keytab from the example above) to the
UNIX host. Then, merge the keytab file with any
existing keytab file for the UNIX computer. The UNIX
commands to merge the keytab file are:
% ktutil
ktutil: rkt unixmachine.keytab
ktutil: list
The output should appear similar to the
following:
slot KVNO Principal
---- ---- ---------
1 1 host/foobar.reskit.com@RESKIT.COM
ktutil: wkt /etc/krb5.keytab
ktutil: q
- Edit the file (/etc/krb5.conf) to refer to the
Windows 2000 domain controller as the Kerberos KDC.
The krb5.conf file entries should be similar to the
following:
[libdefaults]
default_realm = RESKIT.COM
default_tkt_enctypes = des-cbc-md5 ; or des-cbc-crc
default_tgs_enctypes = des-cbc-md5 ; or des-cbc-crc
[realms]
RESKIT.COM = {
kdc = server3.ntdom.microsoft.com:88
}
- The default encryption type entries,
default_txx_enctype, are optional. However, if the
Kerberos client receives an encryption type error,
set the default encryption type to either
DES-CBC-MD5 or DES-CBC-CRC.
- If your UNIX computer’s DNS name does not
include the realm name—for example,
foobar.reskit.com does not include
ntdom.reskit.com—you may be required to map
the hostname to the Kerberos realm name manually, as
follows:
[domain_realm]
.foobar.reskit.com = NTDOM. RESKIT.COM
Without this entry, your Kerberos
applications might try to connect to the wrong realm
and fail, which can be frustrating to
debug.
See the Kerberos version 5 manual
pages for more information on krb5.conf.
- Be sure that your system clocks are synchronized
(within two minutes) to the KDC system’s clock.
Otherwise, Kerberos authentication will fail due to
clock skew errors.
- Finally, you need to create UNIX accounts that
correspond to the Windows 2000 domain accounts so that
the login process will know to use Kerberos
authentication. You can do this by using the
vipw command or other administration tools,
depending on how you manage UNIX accounts. See the
Kerberos version 5 manual pages for more information.
 |
Support for Kerberos Services
Services running on UNIX systems can be configured
with service instance accounts in the Active Directory.
This allows full interoperability. Kerberos clients and
servers on UNIX systems can authenticate using the
Windows 2000 Kerberos server. And Windows 2000
Professional-based clients can authenticate to Kerberos
services that support GSS API.
Unlike Kerberos principal names, Windows 2000 account
names are not multipart. Because of this, it is not
possible to directly create an account of the name
sample/unix1.ntdom.microsoft.com. Such a
principal instance is created through the service
principal name mappings.
To create a service instance account in the Active
Directory
- Use the Active Directory Management tool to create
a user account for the UNIX service; for example,
create an account with the name sampleUnix1.
- Use the Ktpass tool to set up an identity
mapping for the user account. Use this
command:
C:> Ktpass –princ
service-instance@REALM –mapuser account-name -pass
password -out unixmachine.keytab
The
format of the Kerberos service-instance name is:
service/host.realm_name, for
example:
C:> ktpass –princ
sample/unix1.reskit.com@RESKIT.COM
-mapuser
sampleUnix1 –pass password –out
unix1.keytab
In this case, an account
is created with a meaningful name sampleUnix1,
and a service principal name mapping is added for
sample/unix1.reskit.com. This is the purpose of
using Ktpass with the –princ and
–mapuser switches.
- Merge the keytab file with the /etc/krb5.keytab
file on the UNIX host.
Note: You cannot map multiple service
instances to the same user account.
Using an MIT KDC with a Standalone Windows 2000
Workstation
For the Windows 2000 workstation to use a Kerberos
KDC, you must configure both the Kerberos KDC server and
the workstation as described next.
To configure the Kerberos KDC server and the Windows
2000 workstation
- Run the Ksetup utility to configure the
Kerberos KDC server and realm (for details, see the
Ksetup section later in this document).
- In the Kerberos realm, create a host principal
for the computer. Use the
command:
Kadmin –q “ank –pw password
host/machine-name.dns-domain_name”
For example, if the Windows 2000
workstation name is W2KW and the Kerberos
realm name is REALM.RESKIT.COM, the principal
name is
host/w2kw.realm.reskit.com.
Kadmin is
a utility that is part of the MIT Kerberos
distribution.
- Since a Kerberos realm is not a Windows 2000
domain, the computer must be configured as a member
of a workgroup. This is automatic when you set the
Kerberos realm and add a KDC server as follows:
C:> Ksetup /setdomain
REALM.RESKIT.COM
C:> Ksetup /addkdc
REALM.RESKIT.COM kdc.realm.reskit.com
- Set the local machine account password, as
follows:
C:> Ksetup /setmachpassword
password
- Restart your computer for the changes to take
effect. (This is a required step.) Whenever changes
are made to the external KDC and realm configuration,
a restart is required.
- Use Ksetup to configure single sign on to
local workstation accounts. Define the account
mappings; this will map local machine accounts to
Kerberos principals. For example:
C:>
Ksetup /mapuser auser@REALM.RESKIT.COM guest C:>
Ksetup /mapuser * *
Note that the
second command maps clients to local accounts of the
same name.
- Use Ksetup with no arguments to see the
current settings. (Note that the KDC server[s] is not
shown.)
|
Setting Trust with a Kerberos Realm
You can set up a trust relationship between Windows
2000 domains and Kerberos realms. The following
procedure sets up trust between Windows 2000 domain
RESKIT.COM and Kerberos realm
REALM.RESKIT.COM. By default the trust will be
non-transitive. This can be changed to transitive by
using the netdom.exe tool from the Windows 2000 Resource
Kit. The tool is located in the
\support\reskit\netmgmt folder on the
distribution media. See the tool Help menu for
details.
To set up access to services
Workstation computers that use services in an MIT
realm need to have a realm entry added. To do this, use
the Ksetup command on each system that uses the
MIT realm for services.
C:> Ksetup
/addkdc REALM.RESKIT.COM kdc.realm.reskit.com
These mappings are stored in the registry
under
HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains.
To deploy realm configuration data to multiple
computers, use the Security Configuration Template
mechanism instead of using Ksetup explicitly on
individual computers. The computer must be restarted
before the new realm setting will be used.
To set up trust
- On the domain controller for the Windows 2000
domain, use the following command to set up the
configuration for the foreign Kerberos realm (the
computer will need to be restarted before this setting
will be used):
C:> Ksetup /addkdc
REALM.RESKIT.COM kdc.realm.reskit.com
- 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 in Step
5.
- Create a trusted domain relationship with the MIT
Kerberos realm. When prompted if this is a non-Windows
Kerberos Realm, click OK as shown
Figure 1 below.
Figure 1. Set up a Trust
- 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/RESKIT.COM@REALM.RESKIT.COM”
% Kadmin –q “ank –pw password
krbtgt/REALM.RESKIT.COM@RESKIT.COM”
Instead of using the Domain Tree Management user
interface (UI), you can use the Netdom tool to establish
trust to an MIT Kerberos realm. The tool is located in
the \support\reskit\netmgmt folder on the
distribution media. See the tool Help menu for
details.
Creating Account Mappings
Account mappings are used to map a foreign Kerberos
identity (in a trusted MIT Kerberos realm) to a local
account identity in the domain. These account mappings
are managed through the Active Directory Management
tool.
These account mappings will allow the Kerberos realm
to act as an account domain. Users with Kerberos
principals that have mappings to domain accounts, can
logon to a workstation that is joined to a trusted
domain using the Kerberos principal and password from
the Kerberos realm.
If you need to access downlevel Windows NT systems,
the domain account that is used for mapping, needs to
have a password that is synchronized to the Kerberos
principal password. This is because downlevel Windows NT
systems will be using NTLM for authentication.
Users can change their passwords in the Kerberos
realm by selecting the Change password feature from the
<CTRL+ALT+DEL> sequence.
To create a mapping
- Start the Directory Management tool. Point
to Programs, then Administrative tools,
and then Active Directory Users and Computers.
- Start advanced features by clicking View,
and then Advanced Features as shown
in Figure 2 below.
Figure 2. Advanced
Features
- Locate the account to which you want to create
mappings, and right-click to view Name
Mappings. This example uses the account
jbrezak_proxy.
- Click the Kerberos Names mappings tab.
- Add a principal from the foreign MIT realm. The
example shown in Figure 3 below uses
teresa@REALM.RESKIT.COM.
Figure 3. Kerberos Name
Mapping
Using MIT Sample Applications
The MIT Kerberos Krb5-1.0 distribution media comes
with sample applications that demonstrate Kerberos using
both the Krb5 and GSS APIs. These sample applications
run properly on a UNIX system configured to use the
Windows 2000 KDC. The samples are located in the
following directories:
- /krb5-1.0.5/src/appl/sample
- /krb5/krb5-1.0.5/src/appl/gss-sample
Configure the UNIX host to use the Windows 2000 KDC,
create a user account in the Active Directory, and set
the password on the account. Verify that you can use
kinit to authenticate from the UNIX host to the
Windows 2000 KDC.
Sample Kerberos Client and Server Application
You can run the sample Kerberos client and server
application using the Windows 2000 KDC.
To run the sample Kerberos application
- Configure the sserver to start from inetd by
making an entry in /etc/services. See the Kerberos
version 5 manual page for sserver for more
information.
- Create a service instance account in the Active
Directory. Follow the steps described in the previous
section, "Support for Kerberos Services." To
summarize, the steps are:
- On the UNIX host, use kinit on your user
account and use klist to verify that you have a
ticket to the krbtgt/DOMAIN.NAME@REALM.NAME principal.
- Run the sclient program. Assuming the UNIX
host name is pdcunix, the command line (using default
values for the [port] and [service] arguments) is:
% sclient unix1
sendauth succeeded, reply is:
reply len 44, contents:
You are user@RESKIT.COM
GSS Sample Client and Server Applications
You can also run the GSS sample application, GSS
server, and GSS client using Windows 2000 KDC as the
authentication server. As with the Kerberos sample
client/server, you can use sample as the service
name. See the readme file in the gss-sample directory
for more information.
To run the GSS sample client and server application
using the Windows 2000 KDC
- Use the Windows 2000 sample user account
created for the Kerberos sample as described
above.
- Start the GSS server. Text similar to the
following will be displayed.
% gss-server sample &
- Start the GSS client:
% gss-client <host> sample "Message"
The following example output shows the result of
running the GSS client and server application on UNIX
with the Windows 2000 KDC. The user is authenticated as
teresa, the host is unix1, and the domain is
REALM.RESKIT.COM.
% gss-client unix1 sample "Kerberos interop works great!"
"teresa@REALM.RESKIT.COM" to
"sample/unix1.realm.reskit.com@REALM.RESKIT.COM", lifetime 34705,
flags 36, locally initiated, open
Name type of source name is { 1 2 840 113554 1 2 2 1 }.
Mechanism { 1 2 840 113554 1 2 2 } supports 6 names
0: { 1 2 840 113554 1 2 1 1 }
1: { 1 2 840 113554 1 2 1 2 }
2: { 1 2 840 113554 1 2 1 3 }
3: { 1 2 840 113554 1 2 1 4 }
4: { 1 2 840 113554 1 2 2 1 }
5: { 1 2 840 113554 1 2 2 2 }
Sending init_sec_context token (size=534)...continue needed...
context flag: GSS_C_MUTUAL_FLAG
context flag: GSS_C_REPLAY_FLAG
context flag: GSS_C_CONF_FLAG
context flag: GSS_C_INTEG_FLAG
Signature verified.
The MIT Kerberos Krb5-1.0 release of the GSS samples
uses DNS reverse name lookups to identify the target
server principal name. Therefore, the principal name for
the GSS service must be in the form
service/host.domain.name, where the domain name
must be the same as the Windows 2000 domain name. If
your UNIX host DNS domain name is different from the
Windows 2000 domain name (they can be the same or
different DNS domains), you need to define a DNS name
entry for the host.
For example, if the DNS host name is
unix1.xxx.reskit.com, the Windows 2000 domain
name is RESKIT.COM, and the GSS server principal
name is sample/unix1.reskit.com, you would create
the following entry in the /etc/hosts file: x.x.x.x unix1.reskit.com unix1.xxx.reskit.com unix1
where x.x.x.x is your IP address.
Note: If the host DNS domain name is different
from the Windows 2000 domain DNS name, you might see a
GSS client error verifying the data integrity.
Testing GSS API (RFC-1964) Interoperability
You can demonstrate the interoperability between the
Windows 2000 Kerberos Security Support Provider and the
GSS-Krb5 mechanism by running the Krb5 GSS sample
applications on UNIX and a port of the GSS sample
applications on Windows 2000.
The source code for the sample applications for the
GSS client, and for the GSS server port to Windows 2000
using SSPI are available in the samples area of the
Microsoft Windows 2000 SDK CD-ROM. The calls to GSS API
were replaced with equivalent calls to SSPI, the
corresponding Win32 network security interface.
This example uses the Windows 2000 domain controller
as the KDC.
To run the GSS server application using the Windows
2000 KDC
- Build the sample application GSS server in the
platform SDK.
- Use the sample account from the sclient
example. (Account password is "password")
- Run the SSPI-version of GSS server with the
following example command:
c:> gss-server sample/computer.reskit.com password
RESKIT.COM
- On the UNIX system, start the GSS client, and
specify the Windows 2000 host and service name. Note
that the service name is in the form service@Windows
NT host DNS name. An example of the command and the
subsequent output (from the sample) follows.
% gss-client computer sample@computer.reskit.com
"Kerberos interop works great!"
The output of gssserver running on Windows NT looks
similar to the following: D:\>
gssserver
Usage: gss-server [-port port]
[-verbose]
[-inetd] [-logfile file] [service_name]
[service_password] [service_realm]
D:\>
gssserver sample/computer.reskit.com password
RESKIT.COM
context flag: GSS_C_MUTUAL_FLAG
context
flag: GSS_C_REPLAY_FLAG
context flag:
GSS_C_CONF_FLAG
Accepted connection:
"RESKIT.COM\teresa"
Received message: "Kerberos
interop works great!"
You can use Klist to verify the tickets issued
by the Windows 2000 KDC for the sample server running on
the UNIX system and the Windows 2000 system. The output
will be similar to the following: % klist
Ticket cache: /tmp/krb5cc_ttyv0
Default principal: teresa@RESKIT.COM
| 9/12/1997
4:19:49 PM |
9/13/1997 2:18:48
AM |
krbtgt/RESKIT.COM@RESKIT.COM |
| 9/12/1997
4:19:56 PM |
9/13/1997 2:18:48
AM |
sample/computer.reskit.com@RESKIT.COM |
To run the GSS server application using the Windows
2000 KDC
- Build the sample application gssclient in
the platform SDK.
- Use the sample account from the sclient
example.
- Run the MIT version of GSS server with the
following example command:
$ gss-server sample@krbhost.reskit.com
- On the Windows 2000 system, start gssclient.exe to
connect with the MIT GSS server.
C:>
gssclient krbhost sample/krbhost.reskit.com
Hello
LoadLib = 77583214
checking
mithost...calling host krbhost, name
sample/krbhost.realm.com@REALM.COM, msg "Hello".
Sending init_sec_context token (size=2055)...continue
needed...
Block Size is 8, inbuffer =
6
Signature verified.
C:> klist
tickets
Cached Tickets:
Server:
krbtgt/RESKIT.COM@ RESKIT.COM
KerbTicket Encryption
Type: KERB_ETYPE_DES_CBC_MD5
Start Time: 2/22/1999
10:43:49
End Time: 3/24/1999 10:43:49
Renew
Time: 3/24/1999 10:43:49
EncryptionType:
3
TicketFlags: (0x40c00000) forwardable renewable
initial
Server:
sample/krbhost.reskit.com@RESKIT.COM
KerbTicket
Encryption Type: KERB_ETYPE_DES_CBC_MD5
Start Time:
2/22/1999 10:41:18
End Time: 2/22/1999
20:41:18
Renew Time: 3/1/1999
10:41:18
EncryptionType: 3
TicketFlags:
(0x40800000) forwardable
renewable
|
 On this page |
|
|
.gif){kind=spacer}
