Export (0) Print
Expand All
Expand Minimize

Windows 2000 Kerberos Interoperability

Abstract

The Microsoft® Windows® 2000 operating system implements the standard Kerberos network authentication protocol to improve security and interoperability. While new to Windows, the Kerberos protocol is not new and has been implemented on a number of operating system platforms. This paper describes common scenarios for interoperability between Windows 2000 and other Kerberos implementations.

On This Page

Introduction
Kerberos Basics
Interoperability Scenarios
Implementation Approaches
Appendix A

Introduction

This paper examines the various options for integrating Microsoft® Windows® 2000 operating system-based Kerberos support with other non-Windows-based Kerberos realms and services. This paper begins by defining a canonical non-Windows-based Kerberos realm to provide a framework for integration. The paper then presents customer interoperability scenarios detailing integration options and arranges them on a spectrum of ease of implementation, and level of functionality. This paper presumes a basic knowledge of the Kerberos protocol. See Windows 2000 Kerberos Authentication (in Microsoft TechNet) for an overview of Kerberos in Windows 2000.

Kerberos Basics

An individual Kerberos deployment is often referred to as a realm and is analogous to a Windows domain. A Kerberos realm consists of a Key Distribution Center (KDC) and applications and services that use the Kerberos authentication protocols. Like a Windows domain, end-users belong to a specific Kerberos realm, logon or authenticate to that realm and are known throughout that realm. The tools and services discussed here focus on the MIT reference implementation of the Kerberos version 5, although they are analogous to those available in many other implementations of Kerberos version 5.

Kerberized Applications

Kerberized applications include any application or service that uses the Kerberos protocol to authenticate (prove identity) to the network. Kerberized applications include desktop operating systems such as Windows 2000, and network services or applications. Kerberized applications consist of the application or service itself and credential cache for storing authentication information. In addition to Kerberized applications, there are a group of Kerberos utilities that are used to manage the user's Kerberos credentials: kinit, kdestroy, klist and kpasswd.

Credential Cache

The credential cache is used by Kerberos to store authentication information. Once authenticated to a Kerberos realm, the Kerberized application obtains tickets that are used to identify the application to network resources. These tickets are cached so that they can be reused during their lifetime.

Kinit

The kinit utility logs in to the Kerberos realm using the client's key that is derived from the user's password. The Kerberos client receives a Ticket Granting Ticket (TGT) as confirmation of successful authentication. Kerberized applications use the TGT as a stepping-stone for obtaining service tickets for Kerberos services.

Klist

All tickets (including the initial TGT) are placed in a credential cache that can be viewed using the klist utility.

Kdestroy

When the user is finished with Kerberized services, the kdestroy utility can be used to destroy the credential cache to prevent it from being misused by another user. Often implementations perform kinit as part of login and kdestroy as part of logout so that Kerberos is entirely transparent to the user.

Kpasswd

Kpasswd is a utility used by Kerberos users to change passwords for a given identity. Kpasswd is not defined in the Kerberos standard and therefore, is implementation defined.

Kerberos Key Distribution Center (KDC)

A Kerberos Key Distribution Center (KDC), is a network service that accepts requests for tickets from Kerberos clients, validates their identity and grants tickets to them. The protocol is an IETF standard (RFC-1510). A common Kerberos implementation in a distributed network will include a central, or master, KDC and a series of replica, or slave servers to provide authentication services for Kerberos clients. The slave replicas also provide the Kerberos KDC service, have a reasonably recent copy of the key database (KDB), and a change propagation service—kpropd (daemon) running to accept kprop updates from the master KDC. In it's simplest form, a Kerberos KDC consists of a Key Database (KDB) and Kadmin and Kprop tools.

Key Database (KDB)

The Key Database holds account information for network users and resources. The Kerberos KDC uses this Key Database to verify the identity of Kerberos clients. In a distributed environment, this database must be distributed and maintained as part of the KDC replicas. The security of the Kerberos realm depends on keeping the KDB secure.

Bb742432.kerbin01(en-us,TechNet.10).gif

Kadmin

Kadmin is a utility used by the Kerberos administrator to update account entries in the KDB. Changes to the KDB are done only at the master KDC using the local kadmin tool or via the kadmin service (only one kadmin service runs in the realm). Kadmin is not defined in the Kerberos standard and is, therefore, implementation defined.

Kprop

Kprop is a system utility that synchronizes the master KDB with the replica KDBs. Kprop is not defined in the Kerberos standard and is, therefore, implementation defined.

Interoperability Scenarios

There are several ways to mix and match the Kerberos technology implemented in Windows 2000 with other Kerberos implementations. There are three primary variables in Kerberos interoperability:

  1. The Kerberos Client being used to authenticate users to Kerberos services

  2. The Kerberos KDC providing authentication services for a realm

  3. The network resources to be accessed (authorization method)

There are four fundamental implementation approaches that address the multiple scenarios derived from the variables above. The table below shows the permutations of these variables and shows the recommended implementation approach for each.

Access to Windows 2000 Resources

Access to Non-Windows 2000 Resources

Windows 2000 Client Authentication to Windows KDC

Native

One-way Trust or
Service Account

Windows 2000 Client Authentication to Non-Windows KDC

Two-way Trust

Client Configuration

Non-Windows Client Authentication to Non-Windows KDC

Two-way Trust

Native

Non-Windows Client Authentication to Windows KDC

Client Configuration

One-way Trust or
Service Account

Native

Native refers to the scenarios of using matched sets of Kerberos technology such as Windows 2000 Professional-based clients authenticating to a Windows 2000-based KDC and accessing Windows 2000 resources. In this scenario, there are no interoperability challenges and therefore no additional implementation or configuration required for Kerberos functionality. For example, in Windows 2000 when a new user is added to the Active Directory he or she automatically uses Kerberos for all network authentication upon the first logon to the system.

Client Configuration

Client configuration refers to setting-up a Kerberos client to use a KDC for authentication. For example, to have a Linux desktop authenticate to a Windows 2000-based KDC at logon. Most Kerberos clients allow for specification of Kerberos realm and KDC for authentication as part of the logon to the local machine. Windows 2000 provides the Kerberos KDC services as part of the domain controller, so the clients logon to the domain controller itself. The domain controller locates the KDC through service location records in the DNS. This frees the administrator from having to maintain explicit Kerberos configuration data on each client for locating a KDC.

One-way Trust

One-way trust refers to creating a relationship of trust between a domain and a realm such that tickets generated in one realm will be recognized and accepted by resources in the other. For example, a one-way trust relationship where a Kerberos realm trusts a Windows 2000 domain would allow Windows 2000 users to logon to the Windows 2000 domain (that is, the MIT server would accept or trust the authentication performed by the Windows 2000 KDC). This is generally used when the Kerberos realm is being used for resources. Another trust can be created so that users logged in to the Kerberos realm, can access resources in the Windows 2000 domain. If both trusts are present, this is generally referred to as a two-way trust relationship.

Service Account

Windows 2000 can also support Non-Windows 2000-based Kerberized services in the Windows 2000 domain. These services can be represented in the Windows 2000 domain with an account in Active Directory called a service account. For example, a Unix-based service can be made accessible to Kerberos clients in a Windows domain by creating a service account in Active Directory for the service. In this case, the telnet service is part of the Windows domain as compared to the one-way trust case above where the telnet service was part of the MIT Kerberos realm.

Account Mapping

When a Windows 2000 domain trusts a Kerberos realm, the principals in the Kerberos realm do not contain the group associations that are used by Windows 2000 for access control (authorization). The easiest way to handle this is to use accounts in the Windows 2000 domain to provide authorization information for Kerberos principals from trusted realms through account mapping. This mapping can be done on a one-to-one basis where each account in a realm is mapped to a corresponding account in the Windows 2000 domain. The mapping could also be done on a one-to-many basis where multiple individual accounts in a realm are mapped to one account in the Windows 2000 domain.

To ensure seamless interoperability it is necessary to keep the accounts in the two realms synchronized with each other. This can be done using the interfaces of Active Directory such as ADSI and LDAP or through the use of meta-directory technology such as Zoomit Via.

Implementation Approaches

One-way Trust or Service Account

Case 1 – MBA Students

Access to Non-Windows 2000 Resources

Windows 2000 Client Authentication to Windows KDC

One-way Trust or Service Account

Scenario

A large university has a mature Kerberos environment and clear separation of users. Unix users only logon to Unix systems using the Kerberos realm and Windows 2000 users only logon to the Windows 2000 domain. A new Windows 2000 lab has been installed for an MBA project. The MBA students have laptops running Windows 2000 Professional and primarily use Windows 2000 file and print services, but also need to access the Kerberized services located on the Unix servers in a Kerberos realm.

Goals

The goal is that the university wants to keep its existing Kerberos realm, the students can continue to logon to their Windows 2000 KDC and also access Unix-based resources on the University network such as telnet and email.

  • Kerberos Clients: Windows 2000 Professional

  • Kerberos KDC: Windows 2000 KDC

  • Target Resource: Unix-based applications and services

Implementation

By default, the Windows 2000 Professional client will locate its domain and authenticate to its corresponding KDC. The Windows 2000 KDC will then issue the client a TGT upon successful authentication. A one-way trust between the Windows 2000 domain and, the Kerberos realm, will allow authenticated Windows 2000 users to access Unix-based resources within the realm. Windows 2000 users will provide tickets from the Windows 2000 domain to resources in the Kerberos realm. Resources and applications in the Kerberos realm will determine access rights to those resources based on the authorization method implemented for those resources1.

In the case that the university did not have an existing Kerberos realm, but still had a Unix-based telnet service that they wanted to make available to the MBA students they could do this using a service account in the Windows 2000 domain. By creating a service account in the Active Directory for the host's telnet service, that service becomes part of the Windows 2000 domain to which the students belong. The Unix-based telnet service could then be accessed by the students the same as any other service in the domain.

Case 2 – Auto Manufacturer

Access to Non-Windows 2000 Resources

Non-Windows Client Authentication to Windows KDC

One-way Trust or Service Account

Scenario

A leading automobile manufacturer is deploying the Windows 2000 platform. In addition, the company wants to centralize all partner (extranet) account administration and has decided to standardize on Windows 2000 for management of partner user accounts. The primary application for its dealer network is a Unix-based order processing system. Internally, the automaker has a number of employees that have accounts in Kerberos realms that need access to the same order processing system as well as other Unix-based services such as telnet. In addition, many of the dealers run wide variety of desktop operating systems including Solaris, HP-UX and Linux.

Goals

The goal of this scenario is that users would logon to their Unix machines using Windows 2000 accounts and passwords (that the automaker manages in Active Directory). The dealers would be able to access the Unix-based order processing application in the same way they did using their native Kerberos realm. Additionally, non-Windows network services such as telnet, or custom line-of-business application services that use Kerberos authentication could authenticate to the Windows 2000 KDC.

  • Kerberos Clients: Solaris, HP-UX and Linux desktops

  • Kerberos KDC: Windows 2000 KDC

  • Target Resource: Unix-based applications and services

Implementation

Windows 2000 implements the standard Kerberos protocol (RFC-1510) so client user accounts stored and managed in the Windows 2000 Active Directory are represented in the same way as accounts in Kerberos realms. The kinit utility in the existing Unix Kerberos clients can be configured to request tickets from the Windows 2000 domain as its primary Kerberos KDC. Upon successful Kerberos login to the Windows 2000 Domain, a TGT will be returned and stored in the credential cache of the Unix Kerberos client. Similarly, kdestroy and klist, the other primary client tools, also function, as the Unix-based applications would expect.

Similar to case one above, the Windows 2000 KDC will provide standard Kerberos authentication credentials to resources and applications in the Kerberos realm. Kerberized applications in the Kerberos realm will then use these credentials determine access rights to resources. The authorization methods are often specific to Unix-based applications and services. Additionally, applications that depend on Kerberos functions defined in the General Security Service Application Program Interface (GSS-API) or raw Kerberos in UNIX will continue to function as expected.

Also, similar to case one, if the automaker decided to standardize on account management in the Windows 2000 Active Directory for employees and partners (intranet and extranet), they could take advantage of service accounts rather than configuring one-way trust. By creating service accounts for all of the Unix-based services, all users could access all of the services, including the order processing system as part of the Windows 2000 domain.

Client Configuration

Case 1 – Insurance Company

Access to Non-Windows 2000 Resources

Windows 2000 Client Authentication to Non-Windows KDC

Client Configuration

Scenario

An insurance company would like to deploy Windows 2000 Professional to its agents and have them authenticate to an existing Kerberos realm. Windows 2000 Professional is used only as a desktop operating system with all network resources stored on Unix servers that are part of the existing Kerberos realm. The insurance agents will run Windows 2000 on their laptops and need to dial into the corporate network to access a claims database application on a Unix Server that requires Kerberos authentication.

Goals

The goal is to support Windows 2000-based clients in the established Kerberos environment. The insurance company does not want to introduce a Windows 2000 domain into their existing environment, but needs to provide access to existing Kerberized applications to their agents that use Windows 2000-based laptops.

  • Kerberos Clients: Windows 2000 Professional

  • Kerberos KDC: Unix-based Kerberos V5 KDC

  • Target Resource: Unix-based applications and services

Implementation

Windows 2000 Professional- and Server-based desktops can be configured to authenticate to a non-Windows KDC. The Windows 2000-based Kerberos client will request a TGT and resource tickets from the non-Windows KDC and store it in the default credential store. The Windows 2000-based Kerberos client can then present credentials to Kerberized applications in the non-Windows environment.

There must be mapping between the user account in the Kerberos realm and a local user on the Windows computer. The local identity will be used to determine what access rights the user has on the local computer2. The mapping can be many-to-one (for example, all principals from a trusted Kerberos Realm map to the Guest user) or one-to-one (each user has a matching account on their Windows 2000-based computer).

Case 2 – Commercial Architects

Access to Windows 2000 Resources

Non-Windows Client Authentication to Windows KDC

Client Configuration

Scenario

A commercial architecture company would like to deploy Windows 2000-based servers as their file servers and use Kerberos network authentication throughout their company. Many of their engineers, however, use Unix-based workstations required to run complex drafting and design applications.

Goals

The Company would like to manage all user accounts in the Windows 2000 Active Directory, have the engineers logon to the Windows 2000-based server from their Unix machines, continue to use their desktop applications and access files stored on Windows 2000.

  • Kerberos Clients: Unix-based MIT Kerberos Clients

  • Kerberos KDC: Windows 2000 KDC

  • Target Resource: Windows File and Print Services

Implementation

The kinit utility in the existing Unix Kerberos clients can be configured to logon to the Windows 2000 domain when they logon to the Unix workstation. Once authenticated, the Windows 2000 KDC will provide the client with credentials that it will store in its credential cache. When a file is requested from the Windows 2000-based file server3, the Unix Kerberos client will present its credentials to the Windows 2000-based server. The Windows 2000-based server will interpret the credentials and grant or deny access based on the access control lists (ACLs) on the files. These credentials are only present in tickets issued from the Windows 2000 KDC.

Two-way Trust

Case 1 – Brokerage House

Access to Windows 2000 Resources

Windows 2000 Client Authentication to Non-Windows KDC

Two-way Trust

Scenario

A large brokerage house has standardized on Kerberos and has invested heavily in administration resources for the Kerberos realm. They are in the process of rolling out Windows 2000 Professional and Windows 2000 Server to their analysts. They would like the analysts to take advantage of all of the new features of Windows 2000 and standard application, file and print services.

Goals

The analysts authenticate to the Kerberos realm and can then access both Unix-based resources and Windows 2000-based applications and services.

  • Kerberos Clients: Windows 2000 Professional

  • Kerberos KDC: Unix-based Kerberos V5 KDC

  • Target Resource: Windows Application, File and Print Services

Implementation

This scenario builds on the client configuration and one-way trust implementations. First, the Windows 2000-based clients will be configured to logon to the Kerberos realm as discussed earlier. Secondly, a one-way trust relationship must be set up between the Windows 2000 domain and the Kerberos realm (the Windows domain trusts the Kerberos realm as an account domain). Finally, each Kerberos principal in the realm must have a corresponding Windows 2000 account. Each corresponding account (proxy account) in Windows 2000 must have the 'AltSecurityId' property populated with the Kerberos principal name including the realm, for example, analyst555@MITREALM.COM.

The analysts will logon to the Kerberos realm using their Kerberos principal name from the Kerberos realm and receive tickets that can be used to access resources in the Kerberos realm. In addition, when a resource from the Windows 2000 domain is requested, the user will be automatically mapped to the corresponding Windows 2000 account and be issued a ticket from the Window 2000 KDC replete with Windows authorization information. This authorization information contains the user's account Security Identifier (SID) and any group of which the user is a member. Windows 2000 uses this authorization information to determine access rights to resources. In this case, account information in the Windows domain and the Kerberos realm must be synchronized to ensure a seamless user experience (please see Appendix A for additional information on synchronization).

Case 2 – Brokerage House (cont.)

Access to Windows 2000 Resources

Non-Windows Client Authentication to Non-Windows KDC

Two-way Trust

Scenario

The same brokerage company has traders that use Unix workstations that need to continue to access the Unix-based trading applications as well as access the new Windows 2000 Server file, print and application services.

Goals

Unix workstation users must access Unix-based network applications, local workstation resources and file, print and application services of Windows 2000 Server.

  • Kerberos Clients: Unix-based Kerberos Clients

  • Kerberos KDC: Unix-based Kerberos V5 KDC

  • Target Resource: Windows 2000 File and Print Services

Implementation

With the exception of the client configuration step, this implementation is very similar to that of case one above. A one-way trust relationship must be set up between the Windows 2000 domain and Kerberos realm. Additionally, each UNIX user account must have a Windows 2000 account whose 'AltSecurityId' property corresponds to the user's principal name including the realm, for example, analyst555@MITREALM.COM.

With this mapping in place, a Unix user can obtain tickets replete with Windows authorization information that will be used by Windows 2000 to determine access rights to resources. Again, account information in both KDCs must be synchronized to ensure a seamless user experience (please see Appendix A for additional information on synchronization).

Appendix A

Synchronizing Accounts

Active Directory is the account store for Windows 2000 Domains. Some of the scenarios discussed above require one-way account synchronization, from the Kerberos realm to the Windows 2000 Active Directory.

Because Kerberos exists in many forms in many platforms, there is no one correct way to synchronize Active Directory accounts with a Kerberos realm's principals. Instead, many options must be presented for the administrator to choose from. There are two primary update interfaces to Active Directory, ADSI and LDAP C-API (both using LDAP), and three primary synchronization mechanisms to choose from, the kprop service, the kadmin service, and external batch. These options—protocols and mechanisms—will be presented and then one example will be explained in detail—LDAP update called from an external batch procedure.

Directory Update Mechanisms

In order to synchronize Active Directory with a Kerberos realm's database, Active Directory supports two mechanisms: ADSI (Active Directory Service Interfaces) and LDAP C-API (Lightweight Directory Access Protocol). The platform on which the synchronization agent runs will determine the interface used; LDAP C-API will be used on Unix platforms, and ADSI or LDAP C-API used on Windows 2000. Regardless of which API is used, LDAP is the on-the-wire protocol used to communicate with Active Directory.

After an update mechanism is selected, basic synchronization routines such as adding a user, modifying a user's attributes, and deleting a user must be implemented. Additionally, some form of security mechanism must be implemented to authenticate/authorize the updating principal or process.

Account Mapping

To allow for user policy and authorization, as discussed in the scenarios above, every Kerberos realm principal must have a Windows 2000 domain account mapped to it. This mapping is contained in the AltSecurityId property of each Windows 2000 user. For example, in a university setting, there could be a many-to-one domain account called Students that maps to all students on campus, or alternatively a one-to-one account mapping for user555 to the Kerberos principal user555@UNIXREALM.COM. A one-to-one mapping is recommended because it allows for maximum administrative flexibility and control. The rest of this section discusses how to achieve one-to-one account mapping.

Synchronization Mechanism

There are several choices for which mechanism is used to synchronize Windows 2000 Active Directory. Common to all three approaches is the need for an underlying secure update mechanism to add, delete, or modify user accounts over LDAP. The primary choices for synchronization include:

  • Modification of Kprop, the existing synch mechanism for the Kerberos realm,

  • Modification of Kadmin, the existing admin mechanism for the Kerberos realm,

    or

  • Implementing a trusted batch program/script to call Kadmin.

Each of these choices is described in more detail below.

Modification of Kprop

The kprop service can be modified to contact a Windows 2000-based kpropd service. The advantage of using the kprop service is primarily that the synchronization architecture already exists on the Kerberos side. The main disadvantages are the need for implementing a Windows kpropd service and parsing the KDB dump format. To accomplish kprop synchronization, a kpropd must be created for Windows 2000 that is to run on a DC in the domain. This kpropd is running as a trusted member of the kprop service for the Kerberos realm that is the master source for the user accounts. When the kpropd receives an update, the changes can be applied via the secure update package to the Active Directory. (Passwords cannot be set however, because Kerberos passwords are stored as keys—one-way password hashes.) Kpropd receives a KDB dump file of all the principals in the Kerberos realm. The KDB dump file is a list of principals and encrypted keys. Kpropd can use this to create accounts that are in the KDB dump that are not in the directory and update account information for those that are. The Windows kpropd must remember to delete accounts it previously created that are not present in the current dump. This is because the MIT kprop deals with complete dumps, not incremental changes.

Modification of Kadmin

The kadmin utility is the tool for Kerberos realm administration. Functionality can be added to update the Windows 2000 domain when accounts are managed. The advantages are the familiarity of the kadmin interface to Kerberos realm administrators, the existing security measures already placed on kadmin, and the ability to update the Windows 2000 domain, immediately, when originating changes. The main disadvantage is the need for memory in case the update to the Windows 2000 DC fails, for example, in the case of a network partition. Kadmin implements basic administration services such as listing principals (listprinc), adding principals (addprinc), and deleting principals (delprinc). To accomplish kadmin synchronization, a sync-all operation must be added and the modprinc, addprinc, and delprinc operations must be modified. The sync-all operation would take care of initializing the Windows 2000 Domain with a list of all users by calling the secure update package for each user in the database. The listing logic is already provided by the existing listprinc command. The addprinc, modprinc and delprinc commands would also need to be modified to call the secure update package immediately for each change.

Synchronization Using the Kadmin Listprinc Operation

Synchronization can be implemented externally in a batch script/program by using the kadmin listprinc operation. The advantages of this method are ease of implementation and scheduling. Additionally, although the listprinc mechanism is unique to the MIT implementation, it is expected that all implementations of Kerberos have the ability to list all the principals in the database. Because this task is not inherently trusted like kadmin and kprop, care must be taken to securely allow it the correct privileges. Basically the steps are: get kadmin privileges, copy a list of principals to a dump file, compare that list to the last dump, and add, delete, or modify principals as necessary. Because of the ease of implementation, this example is explored in detail below.

Synchronization Walkthrough

This section explores the steps to construct a synchronization batch script using LDAP from UNIX, and the kadmin utility in MIT Kerberos4. The goal is to create an efficient program that can be called any time synchronization is desired. The basic idea of the example is to dump the current list of principals to a file, compare them with a previous synchronization, and update those that are necessary. The following steps detail the mechanics of this script:

Kinit as authorized kadmin principal

Only authorized users have the authority to access the kadmin service and list principals. Instead of having an administrator type in a password for each synchronization, the procedure can be automated. To do this, you must create a new authorized principal, create a keytab file for this principal, and then kinit using this keytab. It is important to give only the root the read privilege and ownership so the keytab won't be modified or misused. This user will be the update principal.

Listing and Sort the Principals and send to a Current List File

Once successfully logged on using kinit, kadmin can be called to list all the principals in the database. To make comparison easy later, it is worthwhile to sort the principals alphabetically, for example by using the UNIX sort command. The results of sort should be sent to a current list file for later comparison. Once again, this file should only be readable by root to prevent unauthorized access.

Compare the Current List to the Old List

The new list should be compared to the old list using an efficient UNIX utility such as the diff command. The results can be piped to a file that can be easily parsed for additions and subtractions. This step allows for updating only those entries that have changed since the last synchronization. If this is the initial synchronization, the old dump file should be empty and thus the entire new list should cause updates.

Add and Delete Users with the proper attributes

Among the principals in the comparison file are users, hosts, services, and instanced users. In the account synchronization scenario, we are primarily concerned with users. Host and Instanced Users generally have a / in the principal, for example, host/computer@UNIXREALM.COM. Searching the file for entries with a / gets rid of these entries. Services look exactly like users, so a list of services needs to be kept and checked against to prevent creation of corresponding Windows users.

Once the added and deleted users have been identified, the secure update package (using LDAP) can be called to perform the operations on Active Directory. For adding a user, it is important that the AltSecurityId property of the new Windows 2000 domain User contain the corresponding Kerberos realm principal name.

If the secure update package is Kerberized, there must be a Windows 2000 Domain user that maps to the update principal in the Kerberos realm, preferably the same one used above in the kinit step. If they are different, the batch script must use kinit with the corresponding keytab at appropriate times.

Copy the Current List to the Old List

This allows only changes to cause updates during the following synchronization. The old list should only contain principals for which the update package returned with no error.

Kdestroy the credential cache

This prevents misuse of the administrative Kerberos credentials necessary for this batch program's execution.

1The authorization methods are often specific to Unix-based applications and services.
2The ksetup.exe tool is used to manage these local account mappings.
3The Windows Services for Unix NFS server can be used to implement the file sharing between the Windows file server and the Unix clients. The current releases of NFS for Windows do not include support for Kerberos V5 authentication. This use of Kerberos authentication in NFS is being standardized in the IETF.
4MIT Kerberos 1.0.6 is available from http://web.mit.edu/kerberos/www/index.html
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft