Kerberos Interoperability Step-by-Step Guide for Windows Server 2003
This step-by-step guide examines the use of the Kerberos interoperability features with the Windows® Server 2003 operating system
Configuration Process Flow
- Create the computer and the user accounts on the Windows Server 2003 client
- Configure the UNIX host
- Create a service instance account in Active Directory
- Configure the MIT KDC server
- Configure the Windows Server 2003 client
- Set up client access to the MIT services
- 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:
- A Windows Server 2003 domain controller can serve as the Kerberos Key Distribution Center (KDC) server for client and host systems using non-Windows implementations of Kerberos. UNIX systems can use kinit and the RC4-HMAC, DES-CBC-MD5 or DES-CBC-CRC encryption type to authenticate to the Windows Server 2003 KDC.
- The Windows Server 2003 Kerberos Security Support Provider (SSP) implements the General Security Service Application Program Interface (GSS-API) Kerberos Mechanism Token formats described in RFC 1964. Windows Server 2003 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 Server 2003, and client applications on Windows Server 2003 using SSPI APIs can obtain session tickets to services on UNIX, both can utilize security services such as mutual authentication, message integrity, and confidentiality.
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
- Windows Server 2003 and Windows XP Professional clients can be configured to logon to a non-Windows Kerberos realm.
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:
- Ksetup. Configures Windows clients to use non-Windows Kerberos realms, KDCs, and Kpasswd servers.
- Ktpass. Sets the password, account name mappings, and generates keytab for Kerberos services on non-Windows servers that use the Windows Server 2003 Kerberos KDC.
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.
- Gssclient. Tests RFC 1964 interoperability.
- Klist. Examines the Kerberos credential cache.
Kerberos Interoperability Limitations
The Windows Server 2003 release has some known Kerberos interoperability limitations. These limitations include the following:
- Only the following encryption types are available for Cross-Realm interoperability:
- RC4-HMAC – (Recommended) Requires Windows Server 2003 SP1 or later KDC.
- DES-CBC-MD5
- DES-CBC-CRC
- If using either DES-CBC-MD5 or DES-CBC-CRC as the only encryption types, any upgraded user accounts (such as accounts upgraded from a Windows NT 4.0 domain) and the administrator account in a new domain must have the password changed before non-Windows Kerberos clients can use them. This is because the database does not contain the DES keys needed for those encryption types. If using RC4-HMAC, which is recommended because it is more secure than the DES encryption types, this is not an issue.
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 Directory 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 key. Either RC4-HMAC-NT (recommended), DES-CBC-MD5, or DES-CBC-CRC.
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
}
- 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 RC4-HMAC, DES-CBC-MD5 or DES-CBC-CRC.
- If your UNIX computer’s hostname is not pre-pended to the realm name—for example, foobar.contoso.com is not a child of reskit.com—you may be required to map the hostname to the Kerberos realm name manually, as follows:
[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
- Create the computer and the user accounts on the Windows Server 2003 client
- Configure the UNIX host
- Create a service instance account in Active Directory
- Configure the MIT KDC server
- Configure the Windows Server 2003 client
- Set up client access to the MIT services
- 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 Computers 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
- Create the computer and the user accounts on the Windows Server 2003 client
- Configure the UNIX host
- Create a service instance account in Active Directory
- Configure the MIT KDC server
- Configure the Windows Server 2003 client
- Set up client access to the MIT services
- 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 procedure.
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 with the following command:
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.
# 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_detect] [-sequence_detect] service_name service_password service_realm
<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
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