Chapter 12Administering NIS+ Credentials
This chapter describes NIS+ credentials and how to administer
them.
Note - Some NIS+ security tasks can be performed more easily with Solstice AdminSuite
tools if you have them available.
Note - NIS+ might not be supported in a future release. Tools
to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating
environment (see System
Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)).
For more information, visit http://www.sun.com/directory/nisplus/transition.html.
NIS+ Credentials
NIS+ credentials are used to identify NIS+ users. This chapter assumes
that you have an adequate understanding of the NIS+ security system in general,
and in particular of the role that credentials play in that system.
For a complete description of NIS+ credential-related commands and their
syntax and options, see the NIS+ man pages.
Note - The description of DES credentials in this chapter is applicable
to 192-bit Diffie-Hellman DES credentials. While similar, authentication
using other key lengths differs in details. When the command line interface
is used to manipulate the keys, the differences are transparent to both the
user and the system administrator. Use nisauthconf(1M)
to display or set the prescribed key lengths.
How Credentials Work
Note - Some NIS+ security tasks can be performed more easily with Solstice AdminSuite
tools, if you have them available.
The credential/authentication system prevents someone from assuming
some other user's identity. That is, it prevents someone with root privileges
on one machine from using the su command to assume the
identity of a second user who is either not logged in at all or logged in
on another machine and then accessing NIS+ objects with the second user's
NIS+ access privileges.
 Caution - NIS+ cannot prevent someone who knows another user's login
password from assuming that other user's identity and the other user's NIS+
access privileges. Nor can NIS+ prevent a user with root privileges from assuming
the identity of another user who is currently logged in on the same machine.
Credential Versus Credential Information
To understand how DES credentials are created
and how they work, you need to distinguish between the credential itself and
the information that is used to create and verify it.
Credential information: The data that
is used to generate a DES credential and by the server to verify that credential.
DES credential: The bundle of numbers
that is sent by the principal to the server to authenticate the principal.
A principal's credential is generated and verified each time the principal
makes an NIS+ request. See The DES Credential in Detail for a detailed description
of the DES credential.
Authentication Components
In order for the credential/authentication process
to work the following components must be in place:
Principal's DES credential information.
This information is initially created by an NIS+ administrator for each principal.
It is stored in the cred table of the principal's home domain. A principal's
DES credential information consists of:
Principal name. This would be a user's
fully qualified login ID or a machine's fully qualified host name.
Principal's Secure RPC netname. Each
principal has a unique Secure RPC netname. (See DES Credential Secure RPC Netname
for more information on Secure RPC netnames.)
Principal's public key.
Principal's encrypted private key.
Principal's LOCAL credential
Server's public keys. Each directory
object stores copies of the public keys of all the servers in that domain.
Note that each server's DES credentials are also stored in the cred table.
Keyserver copy of principal's private key.
The keyserver has a copy of the private key of the principal that is currently
logged in (user or machine).
How Principals Are Authenticated
There are three phases
to the authorization process:
Preparation phase. This consists of the
setup work performed by an NIS+ administrator prior to the user logging in;
for example, creating credential information for the user.
Login phase. This consists of the actions
taken by the system when a user logs in.
Request phase. This consists of the actions
taken by the software when an NIS+ principal makes a request for an NIS+ service
or access to an NIS+ object.
These three phases are described in detail in the following subsections.
Credentials Preparation Phase
The easiest way for
an NIS+ administrator to create credential information for users is to use
the nisclient script. This section describes how to create
client information using the NIS+ command set.
Prior to an NIS+ principal logging in, an NIS+ administrator must create
DES credential information for that principal (user or machine). The administrator
must:
Login Phase--Detailed Description
When a principal logs
into the system the following steps are automatically performed:
The keylogin program is run for the principal.
The keylogin program gets the principal's encrypted private
key from the cred table and decrypts it using the principal's login password.
Note - When a principal's login password is different from his or her
Secure RPC password, keylogin cannot decrypt it and the
user starts getting "cannot decrypt" errors or the command fails
without a message. For a discussion of this problem, see Secure RPC Password Versus Login Password Problem.
The principal's decrypted private key is passed to the keyserver
which stores it for use during the request phase.
Note - The decrypted private key remains stored for use by the keyserver
until the user does an explicit keylogout. If the user
simply logs out (or goes home for the day without logging out), the decrypted
private key remains stored in the server. If someone with root privileges
on a user's machine switched to the user's login ID, that person would then
have use of the user's decrypted private key and could access NIS+ objects
using the user's access authorization. Thus, for added security, users should
be cautioned to perform an explicit keylogout when they cease work. If they also log out of the system, all they
need do is log back in when they return. If they do not explicitly log out,
they will have to perform an explicit keylogin when they
return to work.
Request Phase--Detailed Description
Every time an NIS+ principal
requests access to an NIS+ object, the NIS+ software performs a multistage
process to authenticate that principal:
NIS+ checks the cred table of the object's domain. If:
The principal has LOCAL credential information, NIS+ uses
the domain information contained in the LOCAL credential to find the principal's
home domain cred table where it obtains the information it needs.
The principal has no credential information, the rest of the
process is aborted and the principal is given the authorization access class
of nobody.
NIS+ gets the user's DES credential from the cred table of
the user's home domain. The encrypted private key is decrypted with the user's
password and saved by the keyserver.
NIS+ obtains the server's public key from the NIS+ directory
object.
The keyserver takes the principal's decrypted private key
and the public key of the object's server (the server where the object is
stored) and uses them to create a common key.
The common key is then used to generate an encrypted DES key. To do this, Secure RPC generates a random number which
is then encrypted using the common key. For this reason, the DES key is sometimes
referred to as the random key or the random
DES key.
NIS+ then takes the current time of the principal's server
and creates a time stamp that is encrypted using the DES key.
NIS+ then creates a 15-second window, which is encrypted with
the DES key. This window is the maximum amount of time
that is permitted between the time stamp and the server's internal clock.
NIS+ then forms the principal's DES credential, which is composed
of the following:
NIS+ then passes the following information to the server where
the NIS+ object is stored:
The access request (whatever it might be)
The principal's DES credential
Window verifier (encrypted), which is the encrypted window
plus one
The object's server receives this information.
The object's server uses the Secure RPC netname portion of
the credential to look up the principal's public key in the cred table of
the principal's home domain.
The server then uses the principal's public key and the server's
private key to regenerate the common key. This common key must match the common
key that was generated by the principal's private key and the server's public
key.
The common key is used to decrypt the DES key that arrived
as part of the principal's credential.
The server decrypts the principal's time stamp with the newly
decrypted DES key and verifies it with the window verifier.
The server then compares the decrypted and verified time stamp
with the server's current time and proceeds as follows:
If the time difference at the server exceeds
the window limit, the request is denied and the process aborts with an error
message. For example, suppose the time stamp is 9:00am and the window is one
minute. If the request is received and decrypted by the server after 9:01am,
it is denied.
If the time stamp is within the window limit, the server checks
to see if the time stamp is greater than the one previously
received from the principal. This ensures that NIS+ requests are handled in
the correct order.
Requests received out of order are rejected with an error
message. For example, if the time stamp is 9:00am and the most recently received
request from this principal had a time stamp of 9:02am, the request would
be rejected.
Requests that have a time stamp equal to the previous one
are rejected with an error message. This ensures that a replayed request is
not acted on twice. For example, if the time stamp is 9:00am and the most
recently received request from this principal also had a time stamp of 9:00am,
this request would be rejected.
If the time stamp is within the window limit, and greater
than the previous request from that principal, the server accepts the request.
The server then complies with the request and stores the time
stamp from this principal as the most recently received and acted on request.
To confirm to the principal that the information received
from the server in answer to the request comes from a trusted server, the
server encrypts the time stamp with the principal's DES key and sends it back
to the principal along with the data.
At the principal's end, the returned time stamp is decrypted
with the principal's DES key.
If the decryption succeeds, the information from the server
is returned to the requester.
If the decryption fails for some reason, an error message
is displayed.
|
Previous