| Open Software Foundation | S. Mullan (HP) | |
| Request For Comments: 92.0 | ||
| January 1996 |
The authentication portion of the DCE Security Service is primarily based on Version 5 of the Kerberos [RFC 1510] network authentication system. For the most part, this has allowed the DCE Security Server to be able to operate as a Kerberos Key Distribution Center (KDC) for Kerberos Version 5 clients [John 95]. Today, with some restrictions, you are able to successfully use Kerberos Version 5 clients with a DCE Security Server as the KDC. However, in releases 1.0 and 1.1, DCE has not officially supported or tested interoperability with Kerberos Version 5. That support and testing is now being added to DCE 1.2.
This document discusses the requirements and functionality necessary for supporting interoperability of DCE and Kerberos Version 5 clients, including the Kerberos V5 remote utilities.
This technology is being provided for customers who have Kerberos V5 clients and wish to use the DCE Security Server as a Kerberos KDC. It will also allow users with valid Kerberos V5 credentials to remotely login without exposing unencrypted passwords on the network.
The primary goals of the DCE 1.2.2 and Kerberos V5 interoperability project are [see RFC 63.1]:
rlogin, rlogind, rsh,
rshd) which provide authentication, encryption.
The requirements are stated more specifically in Section 6.
The following are not goals:
rcp) which
interoperates with the Kerberos V5 remote utilities.
ftp, or
telnet.
Also, refer to section 10 for details of which specific versions of DCE and Kerberos V5 will be tested and supported.
The process of determining whether a client may use a service, which objects the client is allowed to access, and the type of access allowed for each.
Verifying the claimed identity of a principal.
Berkeley Software Distribution of UNIX.
A ticket plus the secret session key necessary to successfully use that ticket in an authentication exchange.
A DCE service providing authentication, authorization, and other security services. It is based on Kerberos V5, but has significant extensions and added functionality.
Internet Engineering Task Force.
Key Distribution Center, a Kerberos V5 network service that supplies tickets and temporary session keys.
Refers to the specification of Kerberos Version 5 contained in [RFC 1510].
Identified by a unique name, a realm consists of a KDC, and the clients and servers registered to that KDC.
A record that helps a client authenticate itself to a server; contains client's identity, session key, timestamp, and other information, all sealed using the server's secret key.
A Kerberos client which has been built against a non-DCE Kerberos V5 library.
Refers to the MIT distribution of Kerberos V5. Thus, this refers to the components as implemented in that offering.
A Kerberos V5 Ticket-Granting Ticket which can be used to obtain additional tickets to servers.
The specific requirements for this project are as follows:
rlogin and rsh utilities which
optionally provide user authentication including forwarding of
credentials to the remote host, and encryption of session data
(at least if built with U.S. Domestic DCE sources). These
utilities must be able to interoperate with other Kerberos V5
remote utilities. More specifically:
rlogin, rlogind, rsh, and
rshd based on the BSD Version 4.4-Lite sources. (The
4.4-Lite release of BSD was chosen because it is not encumbered,
i.e., it has no licensing restrictions.)
rlogin and rsh which interoperate with a
non-DCE Kerberos V5 rlogind and rshd,
respectively.
rlogin and rsh which interoperate with a
non-DCE Kerberos V5 KDC.
rlogind and rshd which interoperate with
a non-DCE Kerberos V5 rlogin and rsh,
respectively.
rlogind and rshd which interoperate with
a non-DCE Kerberos V5 KDC (rlogind and rshd
do not directly communicate with the KDC; however, they do share
a key with the KDC).
rlogind and rshd which support the
Kerberos V5 \&.k5login access control mechanism.
rlogin and rsh which can delegate the
user's Kerberos credentials and promote them to DCE credentials
(if applicable) on the remote host, thus avoiding the need to
prompt for and send an unencrypted password over the network.
The following requirements are not committed, but will be provided as time and resources permit:
rlogin, rsh which can authenticate to a
host in a foreign realm.
rlogind, rshd which can accept and
authenticate requests from a host in a foreign realm.
A DCE 1.2.2 client will be able to coexist with a Kerberos V5 client on the same machine, using a DCE Security Server as the KDC. This requires that they be able to share keytab and credential cache files located on the local machine. In order for a DCE application to share a credential cache or keytab file with a Kerberos V5 application, they must be able to write to the file in a format that is understandable by each other.
There are currently 2 versions of formats for the keytab and credential cache files.\*(f! Prior
The beta 5 release of Kerberos introduces a 3rd version; files created with this version are not compatible with DCE 1.2.2.to DCE 1.1, the files were created in the version 1 format. Kerberos introduced the version 2 format with the 2nd beta release, but did not maintain backwards compatibility with files created using the version 1 format. This bug was eventually fixed in the 4th beta release of Kerberos.
DCE 1.1 is partially based on Kerberos V5 beta 4, and thus can read and write files created in either format. The table below describes the compatibility of file versions. In the lefthand column is the DCE or Kerberos release (krb5b1 denoting the first beta release of Kerberos V5), and in the second and third columns are the 2 different file formats. A Yes implies that applications built with that release can read and write files in the version noted, and a No implies that it cannot.
Kerberos Credential Cache/Keytab
File Compatibility
+--------------------+--------+--------+
| Release | krb5v1 | krb5v2 |
+--------------------+--------+--------+
| DCE 1.0/krb5b1 | Yes | No |
| Krb5b2 | No | Yes |
| Krb5b3 | No | Yes |
| DCE 1.{1,2}/krb5b4 | Yes | Yes |
| Krb5b5 | Yes | Yes |
+--------------------+--------+--------+
For DCE 1.2.2, users will be able to select which version their
host will write the files in by specifying a value for the
krb5_kt_vno and krb5_ccache_vno
configuration variables. These values are stored in the DCE
host specific data file (see hostdata(1M)). Upon
creating a new credential cache or keytab file, DCE will read
the value of the appropriate configuration variable to determine
what version should be used. If the configuration variables do
not exist, DCE will use the default version provided by the
Kerberos release it is based on.
Depending on the value set, there will be some tradeoffs. For
example, if the krb5_ccache_vno is set to 2, binary
compatibility with DCE 1.0 applications may be affected, since
DCE 1.0 cannot parse the version 2 format. If the
krb5_ccache_vno is set to 1, any Kerberos V5
applications based on beta 2 or 3 will not be able to parse a
credential cache file created by a DCE application. Users
should set these variables to try to maximize their
interoperability requirements. DCE 1.2.2 utilities
(kinit, klist, kdestroy) will be
able to refresh, read, or destroy credential files created in
either version 1 or 2.
There will be a dcecp command to allow users to
display or change the configuration variables; see section 8.6.
Prior to the beta 5 release of Kerberos V5, configuration of
realms and KDC servers were specified in the files
/krb5/krb.realms and /krb5/krb.conf. The
beta 5 release of Kerberos V5 combined these files into one file
located in /etc/krb5.conf. The files are not
compatible, and since DCE is not based on Kerberos V5 beta 5, it
does not understand the /etc/krb5.conf format.
If the beta 5 release of Kerberos V5 is compiled with the
preprocessor macro OLD_CONFIG_FILE defined, then the
old configuration files will be used instead of
/etc/krb5.conf. This should be considered if the
Kerberos V5 beta 5 applications will be run on a DCE client
using a DCE Security Server. The /krb5/krb.conf file
is initialized during the configuration of the DCE client. The
/krb5/krb.conf is periodically checked for stale
configuration and updated by the security validation service
(secval(1m)) of dced(1m).
If the /etc/krb5.conf file is used for configuration
instead, the user or administrator will be responsible for
setting up and maintaining the file so that the Kerberos V5
applications can use the DCE Security Server as a KDC.
Section 9 of RFC 1510 defines the interoperability requirements which must be supported by all Kerberos V5 implementations. For 1.2.2, we are only supporting KDC interoperability. Each requirement is noted below with a justification of whether or not it will be supported and tested for 1.2.2.
RFC 1510 states that the DES-CBC-MD5 encryption
mechanism must be supported. However, the current release of
Kerberos V5 (beta 5) does not conform to this requirement, so
this will not be supported.
RFC 1510 states that the following checksum methods must be
supported: CRC-32, DES-MAC,
DES-MAC-K, DES-MD5. We will only support
and test CRC-32, since supporting the others would
require a full merge of DCE to the latest version of Kerberos
V5.
RFC 1510 states that all implementations must understand hierarchical realms in both the Internet Domain and the X.500 style. RFC 1510 also states that the KDC must be able to determine the names of the intermediate realms between the KDC's realm and the requested realm when a ticket granting ticket for an unknown realm is requested. The DCE 1.2.2 Security Server will recognize realm names in the Internet Domain style, but any functionality requiring hierachical trust between a DCE cell and a Kerberos V5 realm will not be tested or supported.
See Section 7.3.1 for a more detailed description of the plans for inter-realm communication between a non-DCE KDC and a DCE KDC.
RFC 1510 states that DOMAIN-X500-COMPRESS must be
supported. Hierachical/transitive trust between a DCE cell and
a Kerberos V5 realm will not be supported; thus the transited
field encoding algorithms will not be tested.
RFC 1510 states that the PA-TGS-REQ preauthentication
method must be supported. This will be supported by the DCE
1.2.2 Security Server and will be tested via the Ticket-Granting
Service (TGS) Exchange.
RFC 1510 allows the KDC to optionally support the
PA-ENC-TIMESTAMP preauthentication protocol. The DCE
1.2.2 Security Server will support the
PA-ENC-TIMESTAMP preauthentication protocol, and this
will be tested.
Mutual authentication (via the KRB_AP_REP message)
will be tested and supported by the DCE 1.2.2 Security Server.
Although the server involved in mutual authentication does not
directly communicate with the KDC, it shares a key with the KDC
which is used in the mutual authentication protocol between the
client and server.
Forwardable and forwarded tickets will be supported by the DCE 1.2.2 Security Server and are required to meet the remote utility requirements.
RFC 1510 states that all KDC's must pass on tickets that carry no addresses. This is supported by the DCE 1.2.2 Security Server and will be tested.
RFC 1510 states that proxiable tickets must be supported. The DCE 1.2.2 Security Server will support proxiable tickets.
RFC 1510 states that all implementations must recognize renewable and postdated tickets but need not actually implement them. The DCE 1.2.2 Security Server will support renewable and postdated tickets and this will be tested.
User-to-user authentication (via the ENC-TKT-IN-SKEY
KDC option) will be tested and supported by the DCE 1.2.2
Security Server.
RFC 1510 states that all implementations must pass all authorization data subfields from ticket-granting tickets to any derivative tickets unless directed to suppress a subfield as part of the definition of that registered subfield type.
This will be tested and supported by the DCE 1.2.2 Security Server.
Tests will be written to validate the requirements above. These tests will be built against the beta 5 release of MIT Kerberos V5 and tested with a DCE 1.2.2 Security Server acting as the Kerberos KDC. Also, manual testing will be performed with at least 2 Kerberos V5 products based on the beta 4 release of Kerberos V5.
Inter-realm support between a DCE cell and a Kerberos V5 realm is not a committed requirement for DCE 1.2.2. However, we will attempt to implement the features described below as time and resources permit.
Communication between a DCE cell and a Kerberos V5 realm is important in order to fully utilize the interoperability features of DCE 1.2.2 and Kerberos V5 clients. For DCE 1.2.2, the following inter-realm functionality may be supported:
kinit, klist and kdestroy can
interoperate with a non-DCE Kerberos V5 KDC. For example, users
will be able to authenticate as a principal in a remote Kerberos
V5 realm from a DCE client using the DCE kinit
command. In addition, the DCE klist and
kdestroy commands can be used to list or destroy the
user's credentials obtained from the remote realm.
By registering the Ticket-Granting Service of each realm as a principal in the other realm, inter-realm authentication can be requested by principals in two different Kerberos V5 realms. For example, the following TGS principals and keys need to be created in order for principals in realm 1 and realm 2 to authenticate to each other:
realm1 realm2
------ ------
krbtgt/realm2@realm1{keyA} krbtgt/realm1@realm2{keyB}
krbtgt/realm1@realm2{keyB} krbtgt/realm2@realm1{keyA}
If a client in realm 1 needs to authenticate to a server in
realm 2, the TGS request is accompanied by a TGT encrypted in
the key of the remote TGS principal
krbtgt/realm2@realm1. The foreign KDC recognizes the
request to be inter-realm and decrypts it with the trusted
inter-realm key and returns a ticket to the requested foreign
server. If inter-realm authentication is only required in one
direction, just one of the trusted principal pairs needs to be
created.
If realm 1 is a DCE cell instead of a Kerberos V5 realm, only
one of the principals (krbtgt/realm2@realm1) can be
created. The DCE registry database cannot store a principal
with a foreign realm (krbtgt/realm1@realm2). Thus,
inter-realm communication only works in one direction (DCE to
Kerberos).
In order to avoid the limitations of the DCE registry, a special
naming convention will be used to represent the foreign
principal krbtgt/realm1@realm2 and allow it to be
stored in the DCE registry database as:
/.../realm1/fkrbtgt/realm2
or equivalently as a Kerberos V5 principal:
fkrbtgt/realm2@realm1
There are a couple of cases in which DCE will need to recognize
and convert a principal from a foreign realm specified as
krbtgt/realm1@realm2 to
fkrbtgt/realm2@realm1. When a DCE KDC determines that
a TGS request is from a principal in a foreign Kerberos V5
realm, the DCE KDC will convert the server principal specified
in the ticket to the format above by transposing the server and
realm names and replacing the krbtgt client name with
fkrbtgt. The DCE KDC will then retrieve the key
stored in the DCE registry associated with this name in order to
decrypt the ticket in the TGS request.
In addition, the salt used in the generation of the foreign TGS
principal's DES key from the plaintext password must be
identical in the DCE cell and the Kerberos V5 realm. Since the
default salt is determined by the principal and realm names, it
is important that the structure be the same. Before the DCE KDC
generates a salt for the foreign TGS account, it will convert
the name (as represented by the krb5_principal data
structure) from fkrbtgt/realm2@realm1 to
krbtgt/realm1@realm2 so that it will be consistent
with the Kerberos V5 realm.
Since the Kerberos 5 convention is to capitalize realm names, DCE 1.2.2 will allow the realm names to be specified in capital letters:
/.../realm1/fkrbtgt/REALM2 /.../realm1/krbtgt/REALM2
However, creation of DCE cell names with capital letters will not be supported.
The following dcecp commands establish the necessary
principals and keys in the DCE cell for inter-realm
authentication to a foreign Kerberos V5 realm (appropriately
named FOREIGN-REALM):
principal create krbtgt/FOREIGN-REALM
principal create fkrbtgt/FOREIGN-REALM
group add none -member krbtgt/FOREIGN-REALM
group add none -member fkrbtgt/FOREIGN-REALM
organization add none -member krbtgt/FOREIGN-REALM
organization add none -member fkrbtgt/FOREIGN-REALM
account create krbtgt/FOREIGN-REALM \e
-group none -organization none \e
-mypwd {cell_admin password} -pass {password1}
account create fkrbtgt/FOREIGN-REALM \e
-group none -organization none \e
-mypwd {cell_admin password} -pass {password2}
In the Kerberos V5 realm, the matching trust accounts must be created with the same passwords as specified above, using the Kerberos V5 administration tools. This relies on the ability of the administrators to securely exchange the passwords used to setup the trust accounts.
Inter-cell authentication between DCE cells will not be affected by this functionality.
A highly requested feature missing from DCE is secure remote
utilities which do not expose the user's password to the
network. DCE 1.2.2 will provide secure versions of the BSD
remote programs rlogin, rlogind,
rsh, and rshd. These remote utilities will
be based on BSD 4.4-Lite and will provide the following security
features (where client and server are in the same DCE cell or
Kerberos realm):
rlogin/rsh client
and rlogind/rshd server.
\&.k5login access
control file or the /krb5/aname translation database.
The remote utilities will be built against the beta 5 release of Kerberos V5. The remote utilities will be very similar to the Kerberos V5 based remote utilities, in order to be interoperable with them.
dce_config will be enhanced to provide seamless
integration of the remote utilities into the DCE environment.
The following additional configuration steps will be added
[Brez 95]:
eklogin, klogin, ekshell,
and kshell ports to the /etc/services
configuration file (see services(4)).
host/fully-qualified-hostname
principal and keys required for mutual authentication between
the remote utility client and server processes.
/etc/inetd.conf to automatically start
the remote utility servers when a request for remote access is
made (see inetd(1M)).
BSD Remote login consists of the rlogin client and the
rlogind server. Listed below are the steps involved
in authentication of the user:
rlogin client process and the rlogind server
process via the Kerberos V5 Client/Server Authentication
Exchange protocol.
rlogin forwards the user's
ticket-granting ticket to the rlogind server. This
assumes the user possesses a ticket-granting ticket which is
forwardable. A forwardable TGT can be obtained with the
-f option of kinit or via the
sec_login_forwardable flag to
sec_login_stup_identity(3).\*(f! The
The sec_login_forwardable functionality is not
committed at this time. Refer to section 9.1 for more
information.
rlogind server receives the forwarded credentials and
stores them in a local credential cache file.
rlogind server checks the
\&.k5login access control file and the krb5
aname database to determine if the user is authorized
to access the remote machine. The \&.k5login access
control file is located in the home directory of the account
which is being remotely logged into.
rlogind server then promotes the forwarded
credentials to DCE credentials by executing the
k5dcelogin utility program (see section 7.3.4). If
the k5dcelogin command fails to create a DCE login
context, the errors are ignored in order to be interoperable
with a non-DCE KDC (requirement (6-b-v)).
rlogind server executes the system login program
with an option to avoid prompting for a password.
rlogin process
falls back to the standard BSD 4.4-Lite rlogin.
See the user interface definition for rlogin and
rlogind in section 8 for a complete list of options.
BSD remote shell consists of the rsh client and the
rshd server. The authentication enhancements are
identical to that of rlogin and rlogind with
the following exceptions:
rsh
executes the rlogin command.
rshd server executes the specified command instead
of the system login program.
See the user interface definition for rsh and
rshd in section 8 for a complete list of options.
The k5dcelogin command will be used to promote
Kerberos credentials to DCE credentials, so that users will be
able to fully utilize DCE security features on the remote host.
Listed below are the steps to accomplish this:
sec_login_setup_identity(3) in the next
step.
Ideally, the functionality of the k5dcelogin should be
contained within the login program. However, the
login path is vendor specific, thus
k5dcelogin provides a solution which does not require
modification of OS login source.
[RFC 86.0] discusses the Pluggable Authentication Modules architecture and how it can be integrated with OSF-DCE. Since this is not yet a DCE deliverable, the remote utilities do not need to be integrated with the PAM APIs. However, the functional definition should not preclude the integration with those APIs.
The user interface for the rlogin command, based on
the BSD 4.4-Lite version, is defined below, in manpage-like
fashion. Only the additional options related to authentication
are described.\*(f!
The -k option may not be supported: see section 7.3.1.
NAME
rlogin -- remote login
SYNOPSIS
rlogin [-8EFKLdfx] [-e char] [-k realm] [-l username] host
DESCRIPTION
KERBEROS AUTHORIZATIONrloginstarts a terminal session on the remote hosthost.The security relevant options are as follows:
-kThe-koption requestsrloginto obtain tickets for the remote host in realmrealminstead of the remote host's realm as determined bykrb_realmofhost(3).-xThe-xoption turns on DES encryption for all data passed via theroginsession. This may impact response time and CPU utilization, but provides increased security. (This option is subject to export control.)-KThe-Koption turns off all Kerberos authentication.-fThe-foption requestsrloginto forward the user's Kerberos credentials to the remote host.-FThe-Foption causesrloginto forward the user's Kerberos credentials to the remote host and to allow the remote host to forward them to subsequent remote hosts.
Each user may have a private authorization list in a file\&.k5loginin their login directory. Each line in this file should contain a Kerberos principal name of the formprincipal/instance@realm(in a DCE cell, this principal name is referred to as/.../cell/principal/instance, where realm is equivalent to cell). If the originating user is authenticated to one of the principals named in\&.k5login, access is granted to the account. The principalaccountname@localrealmis granted access if there is no\&.k5loginfile, andaccountnamewas established as a mapping from the remote user's principal name using the Kerberos aname database. Otherwise a login and password will be prompted for on the remote machine as inlogin(1). To avoid some security problems, the\&.k5loginfile should exist on the local filesystem and must be owned by the remote user.The user must possess a ticket granting ticket which is forwardable in order to request the
-for-Foptions. Seekinit(1)for information on obtaining a forwardable TGT.If Kerberos authentication fails, a warning message is printed and the standard Berkeley rlogin is used instead.
The user interface for the rlogind server, based on
the BSD 4.4-Lite version, is defined below. Only the additional
options related to authentication are described.
NAME
rlogind -- remote login server
SYNOPSIS
rlogind [-aklnxK]
DESCRIPTION
rlogindis the server for therlogin(1)program.The security relevant options are as follows:
-kCheck authorization in~/\&.k5login. If the Kerberos authorization fails, the standard Berkeley authorization is checked (ruserok(3M)). If both fail, then login permission is denied.
-KSimilar to-kexcept that the authorization check must succeed in order for the login to succeed.
-xCreate an encrypted session. Therlogindwill listen for requests on theekloginport, and will decrypt all session data with the session key. If the data is not encrypted by the client with the correct key, the output will be decrypted incorrectly and will be meaningless. (This option is subject to export control.)
The user interface for the rsh command, based on the
BSD 4.4-Lite version, is defined below. Only the additional
options related to authentication are described.\*(f!
The -k option may not be supported: see section 7.3.1.
NAME
rsh -- remote shell
SYNOPSIS
rsh [-FKdfnx] [-k realm] [-l username] host [command]
DESCRIPTION
rshexecutescommandon the remote hosthost.The security relevant options are as follows:
-kThe-koption causesrshto obtain tickets for the remote host inrealminstead of the remote host's realm as determined bykrb_realmofhost(3).-xThe-xoption turns on DES encryption for all data exchange. This may introduce a significant delay in response time. (This option is subject to export control.)
-KThe-Koption turns off all Kerberos authentication.-fThe-foption requestsrshto forward the user's Kerberos credentials to the remote host, allowing the user to be authenticated without a password.-FThe-Foption causesrshto forward the user's Kerberos credentials to the remote host and to allow the remote host to forward them to subsequent remote hosts.
The user interface for the rshd server, based on the
BSD 4.4-Lite version, is defined below. Only the additional
options related to authentication are described.
NAME
rshd -- remote shell server
SYNOPSIS
rshd [-aklnxKL]
DESCRIPTION
rshdis the server for thersh(1)program.The security relevant options are as follows:
-kCheck authorization in~/\&.k5login. If the Kerberos authorization fails, the standard Berkeley authorization is checked (ruserok(3M)). If both fail, then login permission is denied.
-KSimilar to-kexcept that the authorization check must succeed in order for the login to succeed.
-xCreate an encrypted session. Thershdwill listen for requests on theekshellport, and will decrypt all session data with the session key. If the data is not encrypted by the client with the correct key, the output will be decrypted incorrectly and will be meaningless. (This option is subject to export control.)
The user interface for the k5dcelogin command is
defined below.
NAME
k5dcelogin-- convertkrb5credentials to DCE credentials.
SYNOPSIS
k5dcelogin [cmd] [...]
(where\&...means options tologin(1)or tocmd)
DESCRIPTION
k5dceloginpromotes forwarded Kerberos V5 credentials to a DCE login context and executes the systemlogin(1)command with any options specified on thek5dcelogincommand line.If
cmdis specified, it is executed instead of the system login program. Any options specified are passed as arguments to thecmd.This command is executed by the
rlogindandrshddaemons as the last step of the authentication process.
The user interface for displaying or modifying the
krb5_ccache_vno and the krb5_kt_vno
configuration variables is shown below.
dcecp -c hostvar set -krb5_ccache_vno vno
dcecp -c hostvar set -krb5_kt_vno vno
dcecp -c hostvar show -krb5_ccache_vno
dcecp -c hostvar show -krb5_kt_vno
The following enhancements are not committed for DCE 1.1.2, but will be implemented if there is sufficient time in the schedule.
Three new additional flags can be passed to
sec_login_setup_identity() in the flags argument to
request a forwardable, renewable, or proxiable ticket-granting
ticket. These flags are of type sec_login_flags_t:
/* * Request a forwardable TGT. */ const unsigned32 sec_login_forwardable = 0x20; /* * Request a renewable TGT. */ const unsigned32 sec_login_renewable = 0x40; /* * Request a proxiable TGT. */ const unsigned32 sec_login_proxiable = 0x80;
This will provide a DCE solution for requesting Kerberos V5
ticket flags without using the DCE kinit utility
program.
This section discusses the specific versions and configurations of DCE and Kerberos V5 which will be tested and supported.
Interoperability of Kerberos Version 5 clients with DCE Security Servers prior to the 1.2.2 release will not be tested and therefore is not supported.
Interoperability of Kerberos Version 5 clients based on MIT releases other than beta 4 or beta 5 will not be tested and therefore is not supported.
There is one known interoperability restriction with a DCE 1.2.2
Security Server. If the well-known DCE pre_auth_req
Extended Registry Attribute is attached to a principal with a
value of 2 (PA-ENC-THIRD-PARTY), the principal will
not be allowed to login from a Kerberos V5 based login
application. If the principal will be logging in from a
Kerberos V5 client, system administrators should not attach the
pre_auth_req ERA or attach it and set it to 0 or 1.
Credential cache and keytab file compatibility of file version formats other than version 1 or version 2 will not be tested and therefore is not supported.
Cross-realm/cell interoperability with DCE clients or a DCE Security Server prior to DCE 1.2.2 and Kerberos V5 clients or a Kerberos V5 KDC based on MIT releases other than beta 4 or beta 5 will not be tested and therefore is not supported.
| Sean Mullan | Internet email: mullan_s@apollo.hp.com | |
| Hewlett-Packard Co. | Telephone: +1-508-436-4129 | |
| 300 Apollo Drive | Fax: +1-508-436-4129 | |
| Chelmsford, MA 01824 | ||
| USA |