Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Identity Synchronization for Windows 1 2004Q3 Deployment Planning Guide 

Appendix A  
Pluggable Authentication Modules

This appendix explains how to configure Identity Synchronization for Windows and Pluggable Authentication Methods (PAM) so an LDAP store can provide synchronization capabilities between Solaris and Windows. The information is organized into the following sections:


Note

In this appendix, Windows refers to Windows environments using Active Directory for authentication. Windows NT environments may impose different approaches.



Overview

If your enterprise environment contains both Solaris and Windows hosts, you can simplify the administration of the user community if you use Identity Synchronization for Windows to manage the two environments as a single set of users.

Combining PAM and Identity Synchronization for Windows can accomplish the following goals:

In addition, you can configure your environment to ensure that passwords are never sent over a medium that permits eavesdropping.

Solaris' implementation of PAM has long-offered the ability to use an LDAP store; however with the advent of intrinsic PAM modules in Solaris 9 you can now use a product such as Identity Synchronization for Windows.


Note

You can patch Solaris 8 to support this functionality using
Patch number 108993 for Sparc or Patch number 108994 for x86.


While some Solaris PAM modules are LDAP-aware, other modules do not use LDAP in a way that triggers Identity Synchronization for Windows’ interception actions.

For example, when you configure the PAM_UNIX module to use LDAP (using a directive specified in the /etc/nsswitch.conf file), the module never binds (as the user in question) against the LDAP store when authenticating. Instead, the PAM_UNIX module reads the user's LDAP entry, internally compares the password found on the LDAP entry to the password provided, and then PAM_UNIX makes its authentication decision accordingly.

Because the PAM_UNIX module authentication is done outside the purview of the LDAP store, none of the hooks put into place by Identity Synchronization for Windows will be used. Consequently, passwords will fail to flow from the LDAP store to Windows.

Specifically, to initiate the synchronization process, Identity Synchronization for Windows requires all authentication systems to bind to the LDAP store. Furthermore, the binding mechanism you use must be a form that presents the user's password in a non-obfuscated manner, such as a simple bind, which precludes the use of SASL and Digest mechanisms. Using Transport Layer Security (TLS) for the connection between PAM and the LDAP store makes the use of simple binds acceptable for security.

The PAM_UNIX module’s authentication methods should suffice in environments where passwords never change or where password changes always flow from the LDAP store to Windows. However, you must not use the PAM_UNIX module in environments where passwords change on Windows.

In contrast to the PAM_UNIX module, the PAM_LDAP module binds to the LDAP store using a pre-formed, “user-centric” DN and a user-provided password when authenticating. This action in particular allows Identity Synchronization for Windows to maintain the synchronization of an entry. Consequently, you will use this PAM_LDAP module in conjunction with Identity Synchronization for Windows and existing PAM modules.

The following section explains how to configure PAM and Identity Synchronization for Windows.


Configuring PAM and Identity Synchronization for Windows


Note

In this section, Windows refers to Windows environments using Active Directory for authentication. Windows NT environments may require different approaches.


Use the following steps to configure Identity Synchronization for Windows and PAM for environments in which passwords can change on Windows:

  1. Configure an LDAP repository for PAM ((more...) )
  2. Install and configure Identity Synchronization for Windows to synchronize the LDAP repository and Windows ((more...) )
  3. Populate the LDAP repository with user data ((more...) )
  4. Configure a Solaris host to use the LDAP repository ((more...) )
  5. Establish password authentication through the LDAP repository and enable users to change their own passwords ((more...) )
  6. Verify that user information (including passwords) flows between environments ((more...) )

The rest of this section provides detailed information about each step and uses examples to illustrate the process.

Step 1: Configure an LDAP Repository for PAM

This section explains how to configure an Identity Synchronization for Windows-supported LDAP repository for PAM, using the following example information:

Use the following steps to configure an Identity Synchronization for Windows-supported LDAP repository for PAM.

  1. Configure the LDAP store using the Solaris idsconfig command line tool.
  2. The idsconfig tool prompts you for values that are needed to form the Directory Information Tree (DIT) to be contained in the LDAP store. The idsconfig tool will manipulate the requisite LDAP store schema to accommodate the impending user population.

    When you configure the test system, the following idsconfig summary screen is displayed (Figure A-1):

    Figure A-1  Summary of Configuration Screen

  3. Evaluate the following key parameters’ values:
    • Domain to serve
    • Base DN to setup
    • Profile name to create
    • Service Auth Method pam_ldap
    • If necessary, use the idsconfig tool to change the context of these parameter values so they are appropriate for your deployment scenario. If you are working in a test environment where you can change DNS entries and set machine IP addresses to arbitrary values, you could use the names and addresses provided in this appendix.

  4. After idsconfig stores the generated configuration, the idsconfig tool will direct you to create virtual list view (VLV) indexes.

  5. Note

    VLV indexes (also called browsing indexes) enable PAM to quickly search for groups, users, and so forth. Refer to the following website for information about creating VLV indexes:

    http://docs.sun.com/source/816-6699-10/scripts.html#15172


    Pay particular attention to the number of VLV indexes that you are prompted to create. The idsconfig tool will provide a list of VLV indexes that are contextually sensitive to the state in which it finds the LDAP store.

    Figure A-2 shows the resulting topology, as seen from the Sun One Directory Server console:

    Figure A-2  Resulting Topology

When you are finished configuring the LDAP repository for PAM, continue to Step 3: Populating the LDAP Repository.

Step 2: Configuring Identity Synchronization for Windows

Now you can begin the process of bridging the LDAP store with the Windows’ authentication system. You accomplish this process by installing and configuring Identity Synchronization for Windows against the following two systems:

You can install Identity Synchronization for Windows on the Solaris 8 host (LDAPHOST.EXAMPLE.COM) and then configure the software so that all of the distributed processes required by Identity Synchronization for Windows will run on LDAPHOST.EXAMPLE.COM.


Note

Instructions for installing and configuring Identity Synchronization for Windows are provided in the Sun Java System Identity Synchronization for Windows 1 2004Q3 Installation and Configuration Guide and the Sun Java System Identity Synchronization for Windows 1 2004Q3 Release Notes.


When you finish configuring Identity Synchronization for Windows, continue to Step 3: Populating the LDAP Repository.

Step 3: Populating the LDAP Repository

After configuring an LDAP repository for PAM, you can push user entries into the LDAP store.

Assume you want to create a new, single user named George Washington that is subordinate to the following entry:

ou=people,dc=pam,dc=example,dc=com

In addition, you want to use an ou=people “container” that is subordinate to the Base DN you provided to idsconfig in Step 2. You may have to make contextual changes to the Base DN you are going to use.

Use the following steps to populate the LDAP repository:

  1. From the Directory tab in the Sun ONE Directory Server console, right-click on the people node (located just below the highlighted pam (2 acis) entry) and when the pop-up menu is displayed, select New -> User.
  2. When the Sun One Directory Server’s Create New User dialog box opens, enter the appropriate information in the text fields provided (for example, see Figure A-3).
  3. Figure A-3  Creating a New User

  4. Select Posix User from the list in the left pane and the right pane changes so you can specify Posix User attributes.
  5. Enable the Enable Posix User Attributes button and then enter the appropriate information in the text boxes provided (see Figure A-4).
  6. Figure A-4  Enabling Posix User Attributes

  7. When you are finished, click OK to save your changes and close the Create New User dialog box.
  8. Verify that the new user (George Washington) is displayed in the console (Figure A-5).
  9. Figure A-5  Sun ONE Directory Server Console

  10. You must edit the gwashing entry to add the shadowaccount objectclass.
    1. Right-click on gwashing and when the pop-up menu is displayed, select the Edit with Generic Editor option.
    2. In the Generic Editor dialog box, complete the appropriate text fields
      (for example, see Figure A-6).
    3. Figure A-6  Adding the shadowaccount Objectclass

  11. When you are finished, click OK to save your changes and close the dialog box.


PAM clients can now authenticate against (and change the password for) this entry. Continue to Step 4: Configuring a Solaris Host to Use PAM.

Step 4: Configuring a Solaris Host to Use PAM

After configuring the LDAP store, you must configure an arbitrary Solaris system and create a PAM client to test the viability of PAM-based authentication.

To configure a Solaris host and create a PAM client you must

  1. Install and configure a test Solaris system
  2. Configure the client machine
  3. Specify new rules for authentication and password management

To illustrate this process, example instructions are provided in the next three sections.

Installing and Configuring a Solaris Test System

Install and configure a test Solaris system as an independent, standalone machine.


Note

To simplify this example, consider configuring a machine that is devoid of any naming service directives (such as NIS or NIS+).

Also, consider using a Solaris 9 x86 4/04 system, which contains several beneficial patches created for PAM and its associated subsystems.


Configuring the Client Machine


Note

The following example instructions assume that you installed and configured the Solaris host as described in the previous section.


You must configure a PAM client machine to locate the LDAP host with a repository that the client will use to access (and effectively change) the LDAP store. To configure the PAM client, use the Solaris ldapclient command, which stores the client’s configuration information on the local host.


Note

Be sure to make a back-up copy of the /etc/nsswitch.conf file before you run the ldapclient command. Running ldapclient has several side effects — which includes completely replacing the system’s /etc/nsswitch.conf file with a copy of the content in /etc/nsswitch.ldap.


Figure A-7 illustrates an example ldapclient command:

Figure A-7  Example ldapclient Command


Note

  • You should use an IP address for this configuration instead of a DNS name, because a DNS is not always available when the PAM system needs it.
  • It is also important to use a proxy credential set to prevent anonymous authenticators from manipulating data in the LDAP store.

    The system provides a set of proxy credentials you can use when manipulating PAM data on the host LDAP store. (These proxy credentials match those created when you used the idsconfig command to initialize the LDAP store.)

  • The generated configuration stores the proxy’s password as an encrypted value, which is done for security purposes.

In addition to generating the requisite LDAP contact information, running ldapclient replaces the contents of the /etc/nsswitch.conf file with a copy of the contents found in /etc/nsswitch.ldap (which is why you were advised to back-up the /etc/nsswitch.conf file). Consequently, most (or all) of the directives found in /etc/nsswitch.conf will include the LDAP directive (which means the LDAP store will be consulted when resolving the associated service request).

In this example, the resulting /etc/nsswitch.conf file left on the system by the ldapclient command dropped the DNS directive from the list of used services when resolving hosts. As the example LDAP store may not be populated with the requisite host information needed to supplant DNS, the /etc/nsswitch.conf file is adjusted (which is the only change made to the post ldapclient command version of the /etc/nsswitch.conf file in this example).

You should edit the host’s declaration to read as follows:

hosts: files ldap dns

Instead of the following reconfigured value (using ldapclient):

hosts: ldap [NOTFOUND=return] files

It is possible that this adjustment will not address your environment’s needs correctly if you are running your DNS from the LDAP store. Consequently, be sure to apply this change only if your environment’s context depends on it. In addition, continue to compare and contrast the service directives with the effective /etc/nsswitch.conf file to the pre-ldapclient variant to validate that all services are now being directed accordingly.

Specifying Rules for Authentication and Password Management


Note

The example instructions provided in this section assume that you installed and configured the Solaris host as described in the Installing and Configuring a Solaris Test System section.


The next step to perform when you are configuring a Solaris host to use PAM is to change the /etc/pam.conf file to incorporate the new rules you want it to use for authentication and password management. (See (more...) for an example /etc/pam.conf file.)


Caution

Before making any changes to the /etc/pam.conf file, be sure you make a back-up copy of the original /etc/pam.conf file. Changes made to the /etc/nsswitch.conf and the /etc/pam.conf files can render your PAM client host inaccessible, which usually means that your configuration is set to deny everyone’s (including root) authentication access to the machine.

To recover from this situation:

  1. Leave a terminal/command window open on the machine and use this terminal session to adjust the pam.conf file for correctness.
  2. In a new terminal/command window, try connecting to the localhost using the rsh or ssh command and then try logging in.
    • If your log-in fails to authenticate, you can still correct the problem using the open terminal/command window from Step 1.
    • If you “confuse” your Solaris system beyond the point of no return (assuming you are still logged in) your only viable option (short of reinstalling) is to restore the /etc/nsswitch.conf and /etc/pam.conf files back to their original state.
    • Using the Solaris sys-unconfig command may not restore your system because this command does not affect the /etc/nsswitch.conf and /etc/pam.conf files.

  3. Repeat this trial and adjust procedure until you achieve the acceptable/expected system behavior.

The changes you must make to /etc/pam.conf are trivial, but they must be explained. Essentially these changes fall into one of two categories:

Authentication

For purposes of authentication, you must edit the file as follows:

  1. Locate any entries in the original /etc/pam.conf file that direct the system to use a rule requiring PAM_UNIX_AUTH, and edit those entries to accept a binding directive and to pass the server_policy parameter to the PAM_UNIX_AUTH module.
  2. Figure A-8 shows a diff between the original /etc/pam.conf file and the edited file.

    Figure A-8  Edited /etc/pam.conf File

  3. Edit the file to add a new rule after the altered rule line.
    (Because the /etc/pam.conf file is processed from the top down, the line’s order is important here.)
  4. The new rule requires the service to include PAM_LDAP when deciding to accept an authentication request. The use_first_pass parameter tells the PAM_LDAP module that it must accept a password collected by an earlier rule’s module (usually satisfied by the PAM_AUTHTOK_GET module).


    Note

    A use case that deserves special consideration is how PAM treats local user log-ons. A local user is a user who is permitted by /etc/nsswitch.conf directives to examine files (such as the root account) and is enumerated in the /etc/passwd file. Local users are not necessarily stored in the LDAP store.

    You might argue that allowing the root user to be listed in the LDAP store would simplify management of an important user account that spans the topology; however, you could make an equally powerful case for systems whose root user must be kept "private" for a given machine.

    To accommodate the need to keep an account (such as root) as a local user, it is important to configure PAM in such a way so that PAM does not access the LDAP back-end store if the user has been described in the local files. You can address this situation by specifying the server_policy parameter for the PAM_UNIX_AUTH module in the given /etc/pam.conf configuration file.


Password Management

The only effective change required for password management, is to append the server_policy parameter to the PAM_AUTHTOK_STORE module. When you use the server_policy parameter, the module will update passwords for local users (if found) or access the LDAP store accordingly. Of course, if the module cannot find a user either locally or in the LDAP store, then the system will provide an appropriate error message.

When you have finished configuring the Solaris host, continue to Step 5: Verifying that PAM is Interoperating with the LDAP Store.

Step 5: Verifying that PAM is Interoperating with the LDAP Store

You are now ready to test whether the newly configured Solaris host can operate as a PAM client. However, before trying to log in as the example user, George Washington, you need to “cheat” just a bit.

If you review the screenshots of George’s user entry, note that George’s default home directory is /pres/home/gwashington. This directory does not yet exist on your test host nor have you configured the auto_home system on which to mount that file system automatically. Consequently, you can create the directory manually to avoid any unwanted complications (see Figure A-9).

Figure A-9  Creating a Directory

You should be able to see the PAM system in action immediately (because gwashing is both understood and displayed). Figure A-10 shows that the PAM LDAP client system you configured can authenticate as gwashing. In addition, this figure demonstrates that a password change can be accomplished and that the new password will be accepted on a subsequent authentication.

Figure A-10  Configured PAM LDAP System

If you check the LDAP store log (specifically looking for non-search operations) you should see an audit of the LDAP operations done in support of the preceding log-in and password-change test (for example, see Figure A-11).

Figure A-11  Auditing LDAP Operations

Step 6: Demonstrating that User Changes are Flowing to the Reciprocal Environment

Both Windows and the LDAP store (if so configured) use a one-way hash when storing a password. This facet prevents true replication of password data between the two systems, but does not prevent the premise of password synchronization.

For an environment that is participating in bidirectional password synchronization, any pre-existing user’s entry being tracked in both environments must be in one of the following states:

Case 1

Case 1 is trivial — there is no supplementary work to do on either system because the entries are current.

Case 2

In Case 2, the LDAP store is in a “holding pattern.” Specifically, the system is waiting for an opportunity to capture the current, correct password for the LDAP store. In this case, a properly configured Identity Synchronization for Windows system has marked the corresponding entry on the LDAP store’s side of the equation as outdated or stale.

When an Identity Synchronization for Windows-enhanced Directory Server system gets a bind against a stale user, Identity Synchronization for Windows replays the given bind credentials to the configured Windows Active Directory to see if the user-supplied password is acceptable. If Active Directory authenticates the password, Identity Synchronization for Windows modifies the LDAP store so that it now possesses the password (Directory Server may eventually hash the value as part of its password policy) and clears the stale status.

This Identity Synchronization for Windows process is known as on-demand synchronization, which results in both systems becoming synchronized with regard to the given entry after a successful bind occurs against the LDAP store.

Case 3

Case 3 can occur under normal circumstances, but most frequently occurs due to one of the following situations:

Case 4

This case is a contradiction. If both systems are stale, then how can you ascertain which system contains the authoritative information? Human intervention will be required in this case, and your decision as to where to place the true state of an entry will then put the entry into one of the three, previously mentioned cases.


Note

This situation can degenerate into a very tedious process as you may be required to examine every user entry


For example, moving the entry from your LDAP store creates Case 3.
If you created an new user called George Washington on a Solaris PAM machine, and then use an idsync resync command to push the entry to Windows, you can verify that Identity Synchronization for Windows has also created the entry on Windows as follows:

  1. From the Windows Start menu, select Control Panel > Administrative Tools > Active Directory User and Computers.
  2. When the Active Directory User and Computers window is displayed, go the Active Directory Users pane (on the right) and select Users.
  3. You should see the George Washington entry as follows:

    Figure A-12  Viewing the User on Windows

  4. Right-click the George Washington entry and select Properties from the pop-up menu.
  5. When the George Washington Properties dialog box is displayed (Figure A-13), check the Account options section and you can see that the User must change password at next logon check box is enabled, which means George will be required to change his password the next time he logs on.

    Figure A-13  George Washington’s Properties

  6. If you log in as George, you can see that Windows is correctly tracking the entry because the log-in attempt results in an expired password message prompt, as shown in Figure A-14.
  7. Figure A-14  Forcing a Password Change

  8. Click OK to close the Logon Message dialog box, and the following Windows dialog box is displayed so you can provide a new password.
  9. Figure A-15  Change Password Dialog Box

  10. Enter and confirm a new password, but do not provide a value for the Old Password field (see Figure A-16).
  11. Because this is first time the user has logged on (since being created over protocol), supplying an old password value will cause an error message and Windows will ask you to enter the new password again. After this first log-on, Windows will require the user to provide the old password.

  12. Click OK to save the new password and close the dialog box.
  13. Figure A-16  Providing a New Password

    If Windows accepts the new password, a message is displayed stating that the new password has been accepted (see Figure A-17).

    Figure A-17  Accepting the New Password

At this point, George’s entry has moved from Case 3 (where the Windows entry is stale and the LDAP store is current) to Case 2 (where Windows is current and the LDAP store entry is stale).

George’s entry will maintain this condition until the next time he binds to the LDAP store. At that time, the entry will move to the Case 1 (where the entry is current on both Windows and the LDAP store).


Configuring Systems to Prevent Eavesdropping

This appendix does not include the procedure for configuring systems so that communication between systems is always conducted securely to thwart eavesdropping.

Some of the required configuration changes are addressed when you configure Identity Synchronization for Windows. For example, on Windows (for Windows 2000 or later), the Windows' password policies require that all password changes must be made using secured methods. Consequently, simply configuring the system partially addresses the security requirement.

However, it is still possible for eavesdroppers to see the bind attempts when Identity Synchronization for Windows components replay bind credentials. To address this issue, you must configure Identity Synchronization for Windows to communicate securely with its Windows data source by configuring the Identity Synchronization for Windows Connectors to trust certificates offered by the Windows’ Active Directory system.

In addition, you must ensure that all clients authenticating to the LDAP store to do so over TLS. For PAM clients, you must configure them to trust the LDAP store and ensure that idsconfig specifies TLS:pam_ldap:simple as the only authentication method for the LDAP store.

One final caveat — root accounts cannot use the passwd command arbitrarily to change an user’s password on PAM client hosts. You might consider this restriction to be a limitation, it depends on whether you trust the PAM client administrators or not.

/etc/pam.conf


Introducing Windows NT into the System

Previously in this appendix, it was stated that the term Windows referred to Windows platforms using Active Directory for authentication; however, the system being discussed in this appendix can use Windows NT in place of (or along with) newer variations of Windows.

Be aware however, Windows NT lacks the ability to use on-demand synchronization normally provided by Identity Synchronization for Windows.

The Identity Synchronization for Windows’ on-demand synchronization process must be able to bind to Windows over LDAP, with a set of candidate credentials — an ability that the Windows NT authentication system lacks. Consequently, when Identity Synchronization for Windows environments cohabitate with Windows NT they expect password changes to be captured at their source and at the time the change is made. This capture requirement has ramifications when you initially bring up an Identity Synchronization for Windows environment. Specifically, the Identity Synchronization for Windows system needs to see a password change for any entry before it can claim that the entry is synchronized.

Synchronization in an NT environment is similar to the processing steps described in Case 3, where you can modify the passwords of all entries in the LDAP store using an LDAP-based utility. As these modifications go through the LDAP store system, Identity Synchronization for Windows forwards the captured passwords to the Windows NT system, and then neither of the two systems would contain stale passwords. However, because you created the passwords by deterministic means, it may be easy to guess these passwords.

With this technique, you can limit potential damage if you use Windows NT’s password policy administration to force all users to change their password at their next logon. As each user changes their password, the Identity Synchronization for Windows password DLL installed on the Primary Domain Controller will forward the password change to the LDAP store.


Example /etc/pam.conf File

The following /etc/pam.conf file is provided to help you configure and run Identity Synchronization for Windows and PAM.


Note

This /etc/pam.conf file is only an example.

The file’s configuration is not appropriate for all situations. Analyze the content thoroughly before using it in a production environment.


Code Example A-1  Example /etc/pam.conf File

#

#ident  "@(#)pam.conf  1.20  02/01/23 SMI"

#

# Copyright 1996-2004 Sun Microsystems, Inc. All rights reserved.

# Use is subject to license terms.

#

# PAM configuration

#

# Unless explicitly defined, all services use the modules

# defined in the "other" section.

#

# Modules are defined with relative pathnames, i.e., they are

# relative to /usr/lib/security/$ISA. Absolute path names, as

# present in this file in previous releases are still acceptable.

#

# Authentication management

#

# login service (explicit because of pam_dial_auth)

#

login  auth requisite  pam_authtok_get.so.1

login  auth required  pam_dhkeys.so.1

login  auth required  pam_dial_auth.so.1

login  auth binding  pam_unix_auth.so.1 server_policy

login  auth required  pam_ldap.so.1 use_first_pass

#

# rlogin service (explicit because of pam_rhost_auth)

#

rlogin  auth sufficient  pam_rhosts_auth.so.1

rlogin  auth requisite  pam_authtok_get.so.1

rlogin  auth required  pam_dhkeys.so.1

rlogin  auth binding  pam_unix_auth.so.1 server_policy

rlogin  auth required  pam_ldap.so.1 use_first_pass

#

# rsh service (explicit because of pam_rhost_auth,

# and pam_unix_auth for meaningful pam_setcred)

#

rsh  auth sufficient  pam_rhosts_auth.so.1

rsh  auth binding  pam_unix_auth.so.1 server_policy

rsh  auth required  pam_ldap.so.1 use_first_pass

#

# PPP service (explicit because of pam_dial_auth)

#

ppp  auth requisite  pam_authtok_get.so.1

ppp  auth required  pam_dhkeys.so.1

ppp  auth required  pam_dial_auth.so.1

ppp  auth binding  pam_unix_auth.so.1 server_policy

ppp  auth required  pam_ldap.so.1 use_first_pass

#

# Default definitions for Authentication management

# Used when service name is not explicitly mentioned for authenctication

#

other  auth requisite  pam_authtok_get.so.1

other  auth required  pam_dhkeys.so.1

other  auth binding  pam_unix_auth.so.1 server_policy

other  auth required  pam_ldap.so.1 use_first_pass

#

# passwd command (explicit because of a different authentication module)

#

passwd  auth binding  pam_passwd_auth.so.1 server_policy

passwd  auth required  pam_ldap.so.1 use_first_pass

#

# cron service (explicit because of non-usage of pam_roles.so.1)

#

cron  account required  pam_projects.so.1

cron  account required  pam_unix_account.so.1

#

# Default definition for Account management

# Used when service name is not explicitly mentioned for account management

#

other  account requisite  pam_roles.so.1

other  account required  pam_projects.so.1

other  account required  pam_unix_account.so.1

#

# Default definition for Session management

# Used when service name is not explicitly mentioned for session management

#

other  session required  pam_unix_session.so.1

#

# Default definition for Password management

# Used when service name is not explicitly mentioned for password management

#

other  password required  pam_dhkeys.so.1

other  password requisite  pam_authtok_get.so.1

other  password requisite  pam_authtok_check.so.1

other  password required  pam_authtok_store.so.1 server_policy

#

# Support for Kerberos V5 authentication (uncomment to use Kerberos)

#

#rlogin  auth optional  pam_krb5.so.1 try_first_pass

#login  auth optional  pam_krb5.so.1 try_first_pass

#other  auth optional  pam_krb5.so.1 try_first_pass

#cron  account optional   pam_krb5.so.1

#other  account optional   pam_krb5.so.1

#other  session optional   pam_krb5.so.1

#other  password optional   pam_krb5.so.1 try_first_pass



Previous      Contents      Index      Next     


Part No: 817-6200.   Copyright 2004 Sun Microsystems, Inc. All rights reserved.