Table of Contents



This step-by-step guide examines the use of the Kerberos interoperability features with the Windows® Server 2003 operating system

Configuration Process Flow

  1. Create the computer and the user accounts on the Windows Server 2003 client
  2. Configure the UNIX host
  3. Create a service instance account in Active Directory
  4. Configure the MIT KDC server
  5. Configure the Windows Server 2003 client
  6. Set up client access to the MIT services
  7. Set up the trust for the non-Windows Kerberos realm


 

Overview


The Windows Server 2003 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 Server 2003 release support the following configurations:

Note

For more details on GSS-API and SSPI interoperability please review: http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/sspi_kerberos_interoperability_with_gssapi.asp

Interoperability with other Kerberos implementations requires minor configuration changes from the default installation. For example, a Windows Server 2003 computer that uses a MIT Kerberos realm must be configured to locate the Kerberos realm, available KDC servers and, optionally, available Kerberos change password servers. Microsoft provides command-line tools to help with the configuration steps. These tools are:

 

Kerberos Configuration Utilities


The Kerberos configuration utilities are available in the Support Tools on the Windows Server 2003 distribution media, in the \support\tools\support.cab file.

Kerberos Test Utilities

The Kerberos test utilities Gssclient and Gssserver are available from MIT. Klist is located in the Windows Server 2003 Resource Kit.

Kerberos Interoperability Limitations

The Windows Server 2003 release has some known Kerberos interoperability limitations. These limitations include the following:

 

Using non-Windows Kerberos Clients

Configuration Process Flow

1.   Create the computer and the user accounts on the Windows Server 2003 client

2.   Configure the UNIX host

3.   Create a service instance account in Active Directory

4.   Configure the MIT KDC server

5.   Configure the Windows Server 2003 client

6.   Set up client access to the MIT services

7.   Set up the trust for the non-Windows Kerberos realm

Configuration steps when using non-Windows Kerberos clients

To create Computer and User Accounts

Use the Active Directory Users and Computers MMC snap-in to create computer and user accounts for the host and user security principals logging into the Windows Server 2003 domain. You must have the name of the UNIX host to complete these procedures.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Active Direin. You must have the name of the UNIX host to complete these procedures.

Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review detailsctory Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

1.   Create a new computer account

Important

Windows Server 2003 account names are not multipart like the principal names in the MIT implementation of Kerberos. 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. The account should be created with a unique descriptive name.  The name of the account does not need to match or even contain any part of the hostname, though it is a good descriptive practice to have the hostname as part of the account name.  For example, if the fully-qualified name of the host is contoso.reskit.com, good account names could be contoso, contoso_unix, or contoso_MIT. 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. 

2.   Create a new user account

Select the Users folder, right-click and select New, then choose user. Type a unique user name for the purpose of logging on to 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.

To configure the UNIX hosts

Use Ktpass on the Windows Server 2003 KDC to create the keytab file (a keytab is a file used to store the keys used by a host or service) 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 (check the documentation for your Kerberos Implementation as the keytab path may be different or configurable).

1.   From the command line, use the following command to generate the keytab file for the UNIX host, map the principal to the account, and set the host principal password.

C:> Ktpass –princ host/hostname@DNS-REALM-NAME –mapuser account -pass password –crypto ENCRYPTION-TYPE –out UNIXmachine.keytab

where

hostnameis the fully-qualified name of the host, for example, foobar.reskit.com.

DNS-REALM-NAME is the uppercase DNS name of the Windows Server 2003 domain; for example, RESKIT.COM.

account is the user account previously created for the UNIX host as performed in the procedure to create Computer and User Accounts.

password is a complex password to be set on the account.

ENCYRYPTION-TYPE is the encryption type used to encrypt the keyRESKIT.COM.

account is the user account previously created for the UNIX host as performed in the procedure to create Computer and User Accounts.

 

Note

In order to create a keytab using the RC4-HMAC-NT encryption type you need to use the ktpass.exe from Windows Server 2003 SP1 or later.

2.   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

3.   Edit the file (/etc/krb5.conf) to refer to the Windows Server 2003 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 = rc4-hmac; or des-cbc-md5, or des-cbc-crc

default_tgs_enctypes = rc4-hmac; or des-cbc-md5, or des-cbc-crc

 

[realms]

RESKIT.COM = {

kdc = winkdc1.reskit.com:88

}

[domain_realm] .foobar.contoso.com = RESKIT.COM

Without this entry, your Kerberos applications might try to connect to the wrong realm and fail.

See the Kerberos version 5 manual pages for more information on krb5.conf.

4.   Be sure that your system clocks are synchronized (within the maximum permitted clock skew; 5 minutes by default) to the KDC system’s clock. Otherwise, Kerberos authentication will fail due to clock skew errors.

Support for non-Windows Kerberos Services

Services running on UNIX systems can be configured with service instance accounts in the Active Directory.

Configuration Process Flow


  1. Create the computer and the user accounts on the Windows Server 2003 client
  2. Configure the UNIX host
  3. Create a service instance account in Active Directory
  4. Configure the MIT KDC server
  5. Configure the Windows Server 2003 client
  6. Set up client access to the MIT services
  7. Set up the trust for the non-Windows Kerberos realm

 

Service Instance Accounts

The service instance account is a user account that Kerberos-aware service uses as its security context. Kerberos clients and servers on UNIX systems can authenticate using the Windows Server 2003 KDC and Windows clients can authenticate to Kerberos services that support GSS API.

Windows Server 2003 account names are not multipart like the principal names in the MIT implementation of Kerberos. 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.

To create a service instance account in the Active Directory

Insert subsection body here.

1.   Create a new user account

Use the Active Directory® Users and Computermultipart like the principal names in ths MMC snap-in to create user accounts for the host and user security principals logging into the Windows Server 2003 domain. You must have the name of the UNIX host to complete these procedures.

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.

2.   Use the Ktpass tool to set up an identity mapping for the user account. Use the following 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.

Note

: To generate RC4-HMAC keytabs use the Windows Server 2003 SP1 or later version of ktpass.exe. For more details see Knowledge Base article 836725 “New version of KTPASS.EXE can generate 128 Bit RC4-HMAC kerberos keytabs”.

      3.   Merge the keytab file with the /etc/krb5.keytab file on the UNIX host.

 

Using an MIT KDC with a Stand-alone Windows Server 2003 Client

For the Windows Server 2003 client to use a non-Windows KDC, you must configure both the non-Windows KDC and the Windows Server 2003 client.

Configuration Process Flow

  1. Create the computer and the user accounts on the Windows Server 2003 client
  2. Configure the UNIX host
  3. Create a service instance account in Active Directory
  4. Configure the MIT KDC server
  5. Configure the Windows Server 2003 client
  6. Set up client access to the MIT services
  7. Set up the trust for the non-Windows Kerberos realm



 

Configuring the server and client

Two procedures are required to use a MIT KDC with a Windows Server 2003 client: use the Kadmin utility to configure the KDC, and use Ksetup to configure the client.

To configure the MIT KDC server

On the MIT KDC, create a host principal for the computer by using the Kadmin utility, which is part of the MIT Kerberos distribution. You will need to create a complex password to complete this procfont-family:arial;font-size:13px;">

 

Configuring the server and client

Two procedures are required to use a MIT KDC with a Windows Server 2003 client: use the Kadmin utility to configure the KDC, and use Ksetup to configure the client.

To configure the MIT edure.

1.   Use the command:

# Kadmin –q “ank host/machine-name.dns-domain_name”

For example, if the Windows Server 2003 client name is WS03SRV1 and the Kerberos realm name is REALM.RESKIT.COM, the principal name is host/ws03srv1.realm.reskit.com.

Note

After executing the above command you will be prompted to provide a password. Provide a complex password and make note of it. You will be required to provide the same password in a subsequent command on the Windows Server 2003 client.

To configure the Windows Server 2003 client

Run the Ksetup utility to configure the Windows Server 2003 client to be aware of the non-Windows KDC and realm. Since the MIT realm is not an Active Directory domain, the computer will be configured as a member of a workgroup. This is automatic when you set the Kerberos realm and add a KDC server. You will be required to restart your computer for the changes to take effect.

1.   Run the following commands:

C:\> Ksetup /setrealm REALM.RESKIT.COM

C:\> Ksetup /addkdc REALM.RESKIT.COM kdc.realm.reskit.com

2.   Set the local machine account password

C:\> Ksetup /setmachpassword password

Replace password with the password you supplied above in the procedure To configure the MIT KDC server.

3.   Restart your computer for the changes to take effect. 

Note

Whenever changes are made to the realm or domain membership, a restart is required.

4.   Use Ksetup to configure single sign on to local workstation accounts. In order to do this, you define the account mappings which maps local machine accounts to Kerberos principals. For example:

C:\> Ksetup /mapuser auser@REALM.RESKIT.COM guest

C:\> Ksetup /mapuser * * which maps clients to local accounts of the same name.

5.   Use Ksetup with no arguments to see the current settings.

C:\> Ksetup

 

Setting Trust with a Kerberos Realm

You can set up a trust relationship between Windows Server 2003 domains and non-Windows Kerberos realms. To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

Configuration Process Flow

1.   Create the computer and the user accounts on the Windows Server 2003 client

2.   Configure the UNIX host

3.   Create a service instance account in Active Directory

4.   Configure the MIT KDC server

5.   Configure the Windows Server 2003 client

6.   Set up client access to the MIT services

7.   Set up the trust for the non-Windows Kerberos realm

Configuring the Realm Trust

You can set up a trust relationship between Windows Server 2003 domains and non-Windows Kerberos realms. The following procedure sets up trust between Windows Server 2003 domain RESKIT.COM and MIT realm REALM.RESKIT.COM. By default the trust will be non-transitive. This can be changed to transitive within the New Trust Wizard or by using the netdom.exe tool from the Windows Server 2003 Support Tools. 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.

1.   C:\> Ksetup /addkdc REALM.RESKIT.COM kdc.realm.reskit.

These mappings are stored in the registry under HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains.

To set up a trust

The following procedures use the Active Directory Domains and Trusts snap-in. However, you can use the Netdom tool to establish trust to an MIT Kerberos realm. The Netdom tool is located in the \support\support.cab file on the distribution media. See the Windows Support Tools Help for details.

1.   On the domain controller for the Windows Server 2003 domain, use the following command to set up the configuration for the non-Windows Kerberos realm:

For example: C:\> Ksetup /addkdc REALM.RESKIT.COM kdc.realm.reskit.com

2.   To enable delegation across the Realm trust run the following command:

For example: C:\> Ksetup /SetRealmFlags REALM.RESKIT.COM Delegate

3.   Start the Active Directory Domains and Trusts snap-in. Click Programs, then Administrative tools, and then Active Directory Domains and Trusts.

4.   Right-click on Properties of your domain, then select the Trusts tab and select New Trust. The passwords used in this step are described in Step 5.

5.   Create a trusted domain relationship with the MIT Kerberos realm using the following parameters:

Trust Name: <MIT Kerberos Realm>

Trust Type: Realm

Transitivity of Trust: Transitive

Direction of Trust: Two-way

Trust Password: <provide the password you created for the MIT Kerberos realm>

Procedural steps for creating a trust relationship are available in Create a two-way, realm trust in the Active Directory Operations Guide or in Create a realm trust in the Active Directory product help of the Windows Server 2003 Technical Library.

The sequence of these steps is shown in the following screenshots:


Figure 1. Set up a Trust



Figure 2. Define the non-Windows Realm to trust
Figure 3. Define the type of trust to be Realm trust



Figure 4. Define the transitivity of the trust



Figure 5. Define the direction of the trust



Figure 6. Enter trust password



Figure 7. Confirmation of Trust settings



Figure 8. Trust creation status report


6.   It is recommended that you enable the Realm trust to support RC4 encryption.  This requires that the KDCs be Windows Server 2003 SP1 or later. To enable, run the following command:

For example: C:\> Ktpass –MitRealmName REALM.RESKIT.COM –TrustEncryp RC4

7.   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):

For example: % Kadmin –q “ank krbtgt/RESKIT.COM@REALM.RESKIT.COM”

For example: % Kadmin –q “ank krbtgt/REALM.RESKIT.COM@RESKIT.COM”

Note

After executing each of these commands you will be prompted to supply a password for the account.  This password should match the password supplied when creating the Cross-Realm trust in the Active Directory Domains and Trusts snap-in as performed previously in step 5.

 

Creating Account Mappings

Account mappings are used to map a foreign Kerberos identity (in a trusted non-Windows Kerberos realm) to a local account identity in the domain. These account mappings are managed through the Active Directory Users and Computers snap-in.

These account mappings will allow the non-Windows Kerberos realm to act as an account domain. Users with non-Windows Kerberos principals that have mappings to domain accounts, can logon to a workstation that is joined to a trusted domain using the non-Windows Kerberos principal and password from the non-Windows 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 non-Windows Kerberos principal password. This is because downlevel Windows NT systems will be using NTLM for authentication.

Users can change their passwords in the non-Windows Kerberos realm (if the realm is configured with a change password server) by selecting the Change Password… feature from the CTRL+ALT+DEL sequence.

To create account mappings

1.   Start the Active Directory Users and Computers snap-in. Point to Programs, then Administrative tools, and then Active Directory Users and Computers.
2    Start advanced features by clicking View, and then Advanced Features as shown in Figure 9 below.


Figure 9. Advanced Features

 

3.   Locate the account to which you want to create mappings, and right-click to view Name Mappings. This example uses the account teresa.

4.   Click the Kerberos Names mappings tab.

5.   Add a principal from the foreign MIT realm. The example shown in Figure 10 below uses teresa@REALM.RESKIT.COM.



Figure 10. Kerberos Name Mapping

 

Creating Transitive Cross-Realm Trust with Child Domains

The following illustration shows the architecture of the transitive cross-realm trust with a child domain.


Figure 11. Cross-realm trust to parent domain


In order for child domains or other domains in a forest of Windows Server 2003 functional level to make use of a Cross-Realm trust between a non-Windows realm and its parent domain there are some operations that need to be completed. This is not available in Windows 2000 or Windows Server 2003 interim functional level forests.

To create a transitive cross-realm trust

.

1.   Mark the Cross-Realm trust as ForestTransitive.  To do this run the following netdom.exe command:

netdom trust <Parent Domain> /domain:<non-Windows Realm> /ForestTransive:Yes

For example: C:\> netdom trust CONTOSO.COM /domain:REALM.FABRIKAM.COM /ForestTransitive:Yes

2.   Add the appropriate Top Level Name (DNS Name Suffix) to the Cross-Realm Trust.

netdom trust <Parent Domain> /domain:<non-Windows Realm> /AddTLN:<DNS suffix of non-Windows Realm>

For example: C:\> netdom trust CONTOSO.COM /domain:REALM.FABRIKAM.COM /AddTln:realm.fabrikam.com

3.   Confirm the name suffix addition wit\> netdom trust CONTOSO.COM /domain:REALM.FABRIKAM.COM /ForestTransitive:Yes

2.   Add the appropriate Top Level Name (DNS Name Suffix) to the Cross-Realm Trust.

netdom trust <Parent Domain> /domain:<non-Windows Realm> /AddTLN:<DNS suffix of non-Windows Realm>

netdom trust <Parent Domain> /NameSuffixes:<non-Windows Realm>

For example: C:\> netdom trust CONTOSO.COM /NameSuffixes:REALM.FABRIKAM.COM

Output should look similar to the following:

C:\>netdom trust CONTOSO.COM /NameSuffixes:REALM.FABRIKAM.COM

Name                            Type Status   Notes

---------------------------- ------ -------- -----

1. *.realm.fabrikam.com Name Suffix   Enabled

The command completed successfully.

Using MIT GSS Sample Applications

Kerberos GSS-APIs. These sample applications run properly on a UNIX system configured to use a Windows Server 2003 KDC. The samples are located in the following directory:

/<MIT_Extraction_Directory>/src/appl/gss-sample

Configure the UNIX host to use the Windows Server 2003 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 Server 2003 KDC.

GSS Sample Client and Server Applications

You can also run the GSS sample application, GSS server, and GSS client using Windows Server 2003 KDC as the authentication server. See the readme file in the gss-sample directory for more information.

To create the sample service account and keytab

1.   On the Windows Server 2003 KDC create a user account with the name sample.

2.   Create the keytab using the following command:

C:>ktpass –princ sample/krbhost.reskit.com@RESKIT.COM –mapuser

RESKIT\sample –pass Password1 –ptype KRB5_NT_SRV_INST –out

sample.keytab

3.   Copy sample.keytab over to KRBHOST.

4.   Import sample.keytab into the default keytab:

# ktutil

ktutil: rkt sample.keytab

ktutil: wkt /etc/krb5.keytab

To run the GSS sample client and server application using the Windows Server 2003 KDC

1.   Start the GSS server. Text similar to the following will be displayed.

ktutil

ktutil: rkt sample.keytab

ktutil: wkt /etc/krb5.keytab

To run the GSS sample client and server application using the Windows Server 2003 KDC

1.&nstyle="margin:3pt 0in 3pt 0.25in;"># gss-server sample@<host>

2.   Authenticate with an account from the non-Windows Realm:

# kinit <user>@<realm>

3.   Start the GSS client:

# gss-client <host> sample@<host> "Message"

The following example output shows the result of running the GSS client and server application on KRBHOST with the Windows Server 2003 KDC. The user is authenticated as teresa from the REALM.RESKIT.COM Kerberos realm, and the host is krbhost.reskit.com.

# gss-server sample@krbhost.reskit.com

context flag: GSS_C_MUTUAL_FLAG

context flag: GSS_C_REPLAY_FLAG

context flag: GSS_C_CONF_FLAG

context flag: GSS_C_INTEG_FLAG

Accepted connection: "teresa@REALM.RESKIT.COM"

Received message: "Kerberos interop works great."

NOOP token

<blank line>

# kinit teresa@REALM.RESKIT.COM

Password for teresa@REALM.RESKIT.COM:

<blank line>

# gss-client krbhost.reskit.com sample@krbhost.reskit.com "Kerberos interop works great."

Sending init_sec_context token (size=1160)...continue needed...

<blank line>

context flag: GSS_C_MUTUAL_FLAG

context flag: GSS_C_REPLAY_FLAG

context flag: GSS_C_CONF_FLAG

context flag: GSS_C_INTEG_FLAG

"teresa@REALM.RESKIT.COM" to "sample/krbhost.reskit.com@RESKIT.COM", lifetime 36000, flags 136, 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 8 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 3 6 1 5 6 2 }

5: { 1 3 6 1 5 6 4 }

6: { 1 2 840 113554 1 2 2 1 }

7: { 1 2 840 113554 1 2 2 2 }

Signature verified.

The MIT Kerberos Krb5 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/<fully qualified hostname>. You will need to either add a ptr record in DNS for the IP address of the host or create an entry in the /etc/hosts file. 

To test GSS API (RFC-1964) Interoperability

You can demonstrate the interoperability between the Windows Server 2003 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 Server 2003.

The source code for the sample applications for the GSS client, and for the GSS server port to Windows Server 2003 using SSPI are available from MIT at: http://web.mit.edu/jaltman/Public/KFW/ms_samples_security_sspi_gss.zip The calls to GSS API were replaced with equivalent calls to SSPI, the corresponding Win32 network security interface.

To run the GSS server application on the Windows Server 2003 member

1.   Create a sample2 service account with the following example command:

C:\>net user sample2 Password1 /add

2.   Set the servicePrincipalName on the service account with the following example command:

C:\>setspn –A sample2/ws03member1.reskit.com RESKIT\sample2

3.   Run the SSPI-version of GSS server with the following example command:

c:\>gssserver sample2/ws03member1.reskit.com Password1 RESKIT.COM

4.   On the UNIX system, start the GSS client, and specify the Windows Server 2003 host and service name. Note that the service name is in the form service@<Windows Server 2003 host DNS name>. An example of the command and the subsequent output (from the sample) follows. 

# gssclient ws03member1.reskit.com sample2@ws03member1.reskit.com "Kerberos interop works great."

The output of gssserver running on Windows Server 2003 looks similar to the following:

C:\> gssserver

Usage: gssserver [-port port] [-verbose] [-once] [-logfile file]        [-confidentiality] [-delegate] [-integrity] [-use_session_key]        [-replay_n the form service@<Windows Server 2003 host DNS name>. An example of the command and the subsequent output (from the sample) follows. 

# gssclient ws03member1.reskit.com sample2@ws03member1.reskit.com "Kerberos interop works great."

The output of gssserver running on Windows Server 2003 looks similar to the following:

C:\> gssserver

<blank line>

C:\> gssserver sample2 Pass

word1 RESKIT

context flag: GSS_C_MUTUAL_FLAG

context flag: GSS_C_REPLAY_FLAG

context flag: GSS_C_CONF_FLAG

Accepted connection using mechanism Kerberos

Accepted connection: "RESKIT\Teresa"

Received message : "Kerberos interop works great."

reading token length: No error

<blank line>

The output of gss-client running on the MIT client looks similar to the following:

<blank line>

# gss-client ws03member1.reskit.com sample2@ws03member1.reskit.c om "Kerberos interop works great."

<blank line>

Sending init_sec_context token (size=1146)...continue needed...

<blank line>

context flag: GSS_C_MUTUAL_FLAG

context flag: GSS_C_CONF_FLAG

context flag: GSS_C_INTEG_FLAG

context flag: GSS_C_INTEG_FLAG

Name type of source name is { 1 2 840 113554 1 2 2 1 }.

Name type of source name is { 1 2 840 113554 1 2 2 1 }.

Mechanism { 1 2 840 113554 1 2 2 } supports 8 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 3 6 1 5 6 2 }

5: { 1 3 6 1 5 6 4 }

6: { 1 2 840 113554 1 2 2 1 }

7: { 1 2 840 113554 1 2 2 2 }

Signature verified.

You can use Klist to verify the tickets issued to the MIT client system. The output will be similar to the following:

# klist

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: teresa@REALM.RESKIT.COM

<blank line>

Valid starting      Expires            Service principal

You can use Klist to verify the tickets issued to the MIT client system. The output will be similar to the following:

# klist

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: teresa@REALM.RESKIT.COM

<blank line>

Valid starting      Expires            Service principal

09/19/06 10:29:31   05/20/06 10:29:31  krbtgt/REALM.RESKIT.COM@REALM.RESKIT.COM

09/19/06 10:30:04   05/20/06 10:29:31  krbtgt/RESKIT.COM@REALM.RESKIT.COM

09/19/06 10:29:45   05/19/06 20:29:45  sample2/ws03member1.reskit.com@RESKIT.COM

<blank line>

<blank line>

Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached

 

To run the GSS client application using the Windows Server 2003 member against an MIT GSS server

1.   Use the sample account and keytab from the example above.

2.   Run the MIT version of GSS server with the following example command:

$ gss-server sample@krbhost.reskit.com

3.   On the Windows Server 2003 system, start gssclient.exe to connect with the MIT GSS server.

C:> gssclient krbhost.reskit.com sample/krbhost.reskit.com "Kerberos interop works great!"

The output of gss-client running on Windows Server 2003 looks similar to the following:

C:> gssclient krbhost.reskit.com sample/krbhost.reskit.com "Kerberos interop works great!"

Context flag: ISC_REQ_CONFIDENTIALITY

Context flag: ISC_REQ_REPLAY_DETECT

Context flag: ISC_REQ_MUTUAL_AUTH

calling host krbhost.reskit.com, name sample/krbhost.reskit.com, msg "Kerberos interop works great!".

Sending init_sec_context token (size=1201)...continue needed...

<blank line>

context flag: GSS_C_MUTUAL_FLAG

context flag: GSS_C_REPLAY_FLAG

context flag: GSS_C_SEQUENCE_FLAG

context flag: GSS_C_CONF_FLAG

Block Size is 1, inbuffer = 30

Signature verified.

4.   On the Windows Server 2003 system, use Klist to verify the tickets issued by the Windows Server 2003 KDC.

C:> klist tickets

The output of Klist running on Windows Server 2003 looks similar to the following:

C:> klist tickets

<blank line>

Cached Tickets: (2)

<blank line>

Server: krbtgt/RESKIT.COM@RESKIT.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

End Time: 9/19/2006 20:52:06

Renew Time: 9/26/2006 10:52:06

<blank line>

Server: sample/krbhost.reskit.com@RESKIT.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

End Time: 9/19/2006 20:52:06

Renew Time: 9/26/2006 10:52:06