Appendix A Pluggable
Authentication Modules
This appendix explains how to configure Sun Java System Identity Synchronization for Windows 6.0 and
pluggable authentication modules (PAM) so that an LDAP store can provide synchronization capabilities between Solaris
and Windows systems.
This appendix covers the following topics:
Note –
In this appendix, Windows refers to Windows systems using Active Directory for authentication. Windows NT systems may impose different approaches.
Advantages of Combining PAM and Identity Synchronization for Windows
If your enterprise contains both Solaris and Windows systems, you can simplify the
administration of the user community if you use Identity Synchronization for Windows to manage the
two sets of users as a single set.
Combining PAM and Identity Synchronization for Windows can accomplish the following goals:
-
Enable an LDAP store to provide synchronization capabilities
between Solaris and Windows
For example, you can enable user information
(including passwords) created or modified on one system (Solaris or Windows)
to replicate to its counterpart so either system can act on the information.
-
Authenticate to the Solaris OS and manage passwords against
an LDAP store
-
Enable users to change their own passwords, if doing so does
not contradict security policy
Configure your systems to ensure
that passwords are never sent over a medium that permits eavesdropping
Note –
The Solaris OS implementation of PAM has long-offered the ability
to use an LDAP store. However, starting with the Solaris 9 OS, PAM modules
are included by default, which makes it possible to use a product such as Identity Synchronization for Windows.
You can update the Solaris 8 OS to support this functionality
by using Patch Number 108993 for SPARC® based systems or Patch Number
108994 for x86 based systems.
While some Solaris software 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) to 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 makes its authentication decision accordingly.
Because the PAM_UNIX module authentication is done
outside the purview of the LDAP store, so none of the hooks put into place
by Identity Synchronization for Windows will be used. Consequently, passwords will fail to replicate
from the LDAP store to Windows.
To initiate the synchronization process discussed in this appendix, Identity Synchronization for Windows requires
that all authentication systems bind to the LDAP store. Furthermore, the binding
mechanism must present the user's password in a clear manner, such as a simple
bind, which rules out the use of the Simple Authentication and Security Layer
(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 preformed, “user-centric”
distinguished name (DN) and a user-provided password when authenticating.
This binding action allows Identity Synchronization for Windows to maintain the synchronization of
an entry. Thus, you will use the 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
systems using Active Directory for authentication. Windows NT systems might
require different approaches.
To configure Identity Synchronization for Windows and PAM for environments in which passwords
can change on Windows, involves completing the following tasks:
-
To Configure an LDAP Repository for PAM
-
To Install and Configuring Identity Synchronization for Windows
-
To Populate the LDAP Repository
-
To Configure a Solaris System to Use PAM
-
To Verify That PAM Is Interoperating With the LDAP Store
-
To Demonstrate That User Changes Flow to the Reciprocal Environment
The remainder of
this section provides procedures for each task and includes examples to illustrate
the configuration process.
To Configure an LDAP Repository for PAM
This procedure describes how to configure an Identity Synchronization for Windows-supported
LDAP repository for PAM, using the following example information:
-
The LDAP store is Directory Server 6.0 software that is hosted on a Solaris Operating
System.
-
The host machine’s DNS name is LDAPHOST.EXAMPLE.COM.
-
The machine’s IP address is 192.168.220.219 in
the test environment.
In this example, the IP address has a concrete
value so that when you configure the PAM clients, you can use the repository’s
IP address to avoid potential conflicts based on how the PAM client machine
resolves its DNS queries.
Prerequisites to configure an Identity Synchronization for Windows- supported LDAP repository
for PAM.
-
Consult the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide to
verify that you are using a supported Directory Server.
-
For PAM to work with Directory Server 6.0, you must edit the /usr/lib/ldap/idsconfig script and change 5 to 6 in the following code:
if [ "${IDS_MAJVER}" != "5" ]; then
-
While executing the idsconfig command-line
tool, you need to know which values to assign to the various configuration
parameters. If you do not know, use the default values when prompted (other
than the configuration parameters 1, 2, and 4).
Use the following steps to configure an Identity Synchronization for Windows- supported LDAP
repository for PAM.
-
Configure the LDAP store by using the Solaris OS idsconfig command-line tool.
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:
-
To change the value of a configuration parameter, type its
associated configuration number.
-
Select an option from the list of predefined options that
can be supplied to the selected parameter.
-
Evaluate the following key parameters’ values:
If necessary, use the idsconfig tool to change the context of these
parameter values so they are appropriate for your deployment. If you are working
in a test environment where you can change DNS entries and set machine IP addresses to arbitrary values,
you may use the names and addresses provided in this appendix.
-
Continue with the proxy creation initiated by the idsconfig tool by providing the appropriate values (default or custom) for
the various parameters.
-
After the configuration is complete and idsconfig stores
the generated configuration, create virtual list view (VLV) indexes when prompted.
Note –
VLV indexes (also called browsing indexes)
enable PAM to quickly search for groups, users, and so forth. For information
about creating VLV indexes, go to:
Managing Browsing Indexes in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide
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.
The following figure shows the resulting topology, as displayed on the Sun Java System Directory
Server Console.
When you are finished configuring the LDAP repository for PAM, continue
to To Populate the LDAP Repository.
To Install and Configuring Identity Synchronization for Windows
This procedure starts the process of bridging the LDAP store with the
Windows authentication system. Install and configure Identity Synchronization for Windows on
the following two systems:
-
LDAPHOST.EXAMPLE.COM
-
WINHOST.EXAMPLE.COM.
You can install Identity Synchronization for Windows on the Solaris 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.
Instructions for installing and configuring Identity Synchronization for Windows are provided
in the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide.
When you finish configuring Identity Synchronization for Windows, continue to To Populate the LDAP Repository.
To Populate the LDAP Repository
After configuring an LDAP repository for PAM, you push user entries
to the LDAP store.
For example, you 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 use an ou=people container that
is subordinate to the base DN you provided to idsconfig.
You might have to make contextual changes to the base DN you are going to
use.
-
In the Directory Service Control Center Console, click the
Entry Management tab, and then the Browse tab. The various entity management
controls are displayed in the right pane.
-
Click New Entry to display the New Entry screen.
-
Type a value in the Entry Parent DN field to specify the location
to save the entity in Directory Server and click Next.
-
Associate your entity with an object class by choosing an
option from the Entry Type drop-down menu and press Next.
Based on the object class that you associated with your entity, a number
of different attributes are displayed.
-
Enter the appropriate values for the parameters and press
Next.
A summary of the entity is displayed.
-
Verify that the new user (George Washington) is displayed
in the console.
-
Click Finish.
PAM clients can now authenticate against (and change the password for)
this entry.
To Configure a Solaris System to Use PAM
After configuring the LDAP store, you must configure a Solaris system
and create a PAM client to test the viability of PAM-based authentication as follows.
-
Install and configure a test Solaris system.
-
Configure the PAM client.
-
Specify new rules for authentication and password management.
To illustrate this process, example instructions and guidelines are
provided in the next three sections.
Installing and Configuring a Solaris Test System
Install and configure a test Solaris system on an independent, stand-alone
machine.
Note –
To simplify this example, consider configuring a system that is
devoid of any naming service directives (such as NIS or NIS+).
Consider
using a Solaris 9 4/04 x86 based system, which contains patches required for
PAM and its associated subsystems.
Configuring the PAM Client
The following example instructions assume that you have installed and
configured the Solaris test system as described in the previous section.
You must configure a PAM client 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 OS ldapclient command,
which stores the client’s configuration information on the local host.
Note –
Make a backup 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.
The following screen illustrates an example ldapclient command:
Other guidelines include the following:
-
Use an IP address for this configuration instead of a DNS name, because DNS might not available when the PAM client
needs it.
-
Use a proxy credential set to prevent anonymous authenticators
from manipulating data in the LDAP store.
The system provides
a set of proxy credentials that 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
(the file you backed up earlier) with a copy of the contents in /etc/nsswitch.ldap. Consequently, most (or all) of the directives found in /etc/nsswitch.conf will include the LDAP directive, which means
that 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 might not be populated with the requisite host information
needed to supplant DNS, the /etc/nsswitch.conf file is
adjusted. In this example, this is the only change made to the post ldapclient command version of the /etc/nsswitch.conf file.
Edit the host’s declaration to read as follows:
hosts: files ldap dns
Do not use the following reconfigured value (using ldapclient):
hosts: ldap [NOTFOUND=return] files
This adjustment might not address your environment’s needs correctly
if you are running your DNS from the LDAP store. Only apply this change 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 correctly.
Specifying Rules for Authentication and Password
Management
Note –
The example instructions provided in this section assume that
you completed the tasks as described in Installing and Configuring a Solaris Test System.
When you configure a Solaris system to use PAM, change the /etc/pam.conf file to incorporate the new rules that you want it to use for authentication and password management. For an example, see Example /etc/pam.conf File.
Before making any changes to the /etc/pam.conf file,
make sure that you make a backup copy of the original /etc/pam.conf file.
Changes made to the /etc/nsswitch.conf and /etc/pam.conf files
can render your PAM client inaccessible, which means that your configuration
will deny everyone’s (including root) authentication access to the machine.
If you need to recover from a situation of this type, do the following:
-
Edit the pam.conf file in the current session. See Authentication and Password Management.
-
In a new terminal window, try connecting to the local host
using the rsh or ssh command and then
try logging in.
-
If you fail to authenticate, you can still correct the problem
using the open window that you used in the previous step.
-
If you are still unable to recover, restore the /etc/nsswitch.conf and /etc/pam.conf files to their original state.
Using the Solaris OS sys-unconfig command might not
restore your system because this command does not affect the /etc/nsswitch.conf and /etc/pam.conf files.
-
Repeat steps 1 and 2 until you achieve the expected system
behavior.
The changes you must make to /etc/pam.conf are minor, but important, and
are explained in the next two sections:
Authentication
For purposes of authentication, you must edit the /etc/pam.conf file
as follows:
-
Locate any entries in the original /etc/pam.conf file
that direct the system to use a rule requiring PAM_UNIX_AUTH,
and edit them to accept a binding directive and to pass the server_policy parameter to the PAM_UNIX_AUTH module.
The following output shows a diff between the original /etc/pam.conf file and the edited file.
-
Edit the file to add a new rule after the altered rule line.
The /etc/pam.conf file is processed from the top down so
line order is important.
The new rule requires the service to
include PAM_LDAP when determining whether 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
the login of a local user. A local user is a user who
is permitted by /etc/nsswitch.conf directives to examine
files (such as the root account) and is
listed in the /etc/passwd file. Local users are not necessarily
stored in the LDAP store.
Allowing the root user
to be listed in the LDAP store would simplify management of an important user
account that spans the topology. However, an equally powerful case could be
made 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, PAM must be configured
so it does not access the LDAP back-end store if the user information has
been saved in the local files. This situation can be addressed by specifying
the server_policy parameter for the PAM_UNIX_AUTH module
in the /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.
If the module cannot find a user either locally or in the LDAP store, the
system will provide an appropriate error message.
When you have finished configuring the Solaris test machine, continue
to To Verify That PAM Is Interoperating With the LDAP Store.
To Verify That PAM Is Interoperating With the LDAP
Store
You now test whether the newly configured Solaris system can operate
as a PAM client.
-
At the command line, create George default home directory, /pres/home/gwashington, on your test system.
The PAM client is working because gwashing is both
understood and displayed.
-
Configure the auto_home system on which
to mount that file system automatically. The following output shows that the
PAM LDAP client system that you configured can authenticate as gwashing.
In addition, this output demonstrates that a password can be changed and that
the new password will be accepted on a subsequent authentication request.
-
Check the LDAP store log for non-search operations. An audit
of the LDAP operations completed in support of the preceding login and password-change
test is displayed.
To Demonstrate That User Changes Flow to the Reciprocal
Environment
Both Windows and the LDAP store (if so configured) use a one-way hash
when storing passwords. This configuration prevents true replication of password
data between the two systems, but does not prevent the password synchronization.
For an environment that is participating in bidirectional password synchronization,
any existing user’s entry being tracked in both environments must be in one of the
following states:
-
Both Windows and the LDAP store contain current information.
No work needs to be done on either system because the entries are current.
-
Windows is current but the LDAP store is outdated or stale.
The LDAP store is in a state of waiting. Specifically, the system is
waiting for an opportunity to capture the current, correct password for the
LDAP store. In this case, properly configured Identity Synchronization for Windows software marks
the corresponding entry in the LDAP store as outdated or stale.
When
a system with Directory Server and Identity Synchronization for Windows gets a bind to 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 might eventually hash the value as part of
its password policy and clear the stale status.
This 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 to the LDAP store.
-
Windows is stale but the LDAP store is current.
This
state can occur under normal circumstances, but most frequently occurs due
to one of the following situations:
-
When the LDAP store possesses all the entries and Windows
is waiting to be populated by Directory Server entries
This situation
requires the most attention to get the system into a synchronized state because
existing entries in the LDAP store presumably have one-way, hashed passwords.
When Identity Synchronization for Windows tries to migrate data to Windows, there are no usable values
to push when propagating the user’s password. In this case, Windows
will request a password when a user logs in for the first time.
If
multiple users logging in to your Windows systems without an effective password
is not acceptable, you can set a password programmatically for each entry
in question. After Identity Synchronization for Windows reports that the system is synchronizing,
you can use LDAP operations to specify the generated passwords on the LDAP
store side or the Windows side of your environment.
To complete
this process, you must specify a must-change password policy after the user’s
next logon. This policy facilitates the transformation of an end user’s
password from an openly known value to a secret value.
-
When an end user changes his or her password on the LDAP store
side and Identity Synchronization for Windows is propagating the change through the system (either
actively or by scheduling the work)
In this situation, the information
on Windows remains stale for just a short time. The Identity Synchronization for Windows components
have captured all of the information needed to bring the Windows system into
a synchronized state. Identity Synchronization for Windows takes the time only to process the information,
then the entry will be synchronized.
-
Both Windows and the LDAP store are stale.
If
both systems are stale, you cannot ascertain which system contains the authoritative
information. You must decide where to place the true state of an entry into
one of the three, previously mentioned states. For example, moving the entry
from your LDAP store creates corresponds to the previous state.
Note –
This situation can lead to a very tedious process as you might
have to examine every user entry.
If you created a user called George Washington on
a Solaris system that operates as a PAM client, and then use the 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 explained in the following procedure.
To Verify Entries on Windows
-
From the Windows Start menu, go to Control Panel -> Administrative
Tools -> Active Directory User and Computers.
-
When the Active Directory User and Computers window is displayed,
go the Active Directory Users pane (on the left) and click Users.
-
Right-click the George Washington entry, and choose Properties.
When the George Washington Properties dialog box is displayed, look
at the Account options section. It shows that the User Must Change Password
at Next Logon check box is selected, which means that George Washington will
be required to change his password the next time that he logs in.
-
Log in as George Washington.
Windows is correctly
tracking the entry because the log-in attempt displays the Logon Message dialog
box stating, “Your password has expired and must be changed.”
-
Click OK to close the Logon Message dialog box and to display
the Change Password dialog box to provide a new password.
-
Type and confirm a new password, but do not provide
a value for the Old Password field.
This is first time the user
has logged in (since being created over protocol), so supplying an old password
value will cause an error message and Windows will ask you to enter the new
password again.
-
Click OK to save the new password and close the Change Password
dialog box.
If Windows accepts the new password, a message is displayed stating
that the new password has been accepted.
At this point, the George Washington entry has moved from where the
Windows entry is stale and the LDAP store is current to where Windows is current
and the LDAP store entry is stale.
George Washington's entry will
maintain this condition until the next time that it binds to the LDAP store.
At that time, the entry will move to where the entry is current on both Windows
and the LDAP store.
Configuring Systems to Prevent Eavesdropping
This appendix does not include procedure for configuring systems so
that communication between systems is always conducted securely to prevent
eavesdropping.
Some of the required configuration changes are addressed when you configure Identity Synchronization for Windows.
For example, starting with Windows 2000, the password policies require that
all password changes be made using secure methods. Consequently, simply configuring
the Windows system partially addresses the security requirement.
However, eavesdroppers can still 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 do so over TLS. You must configure PAM clients to trust the LDAP store and
ensure that idsconfig specifies TLS:pam_ldap:simple as
the only authentication method for the LDAP store.
The root accounts cannot use the passwd command
arbitrarily to change a user’s password on PAM client. You might consider
this restriction to be a limitation, depending on whether you trust the PAM
client administrators.
Introducing Windows NT Into the Configuration
While the term Windows refers to Windows platforms
using Active Directory for authentication, the system being discussed in this
appendix can use Windows NT in place of (or along with) newer variations of
Windows.
Be aware, however, that 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. When Identity Synchronization for Windows is configured with Windows NT, it expects password
changes to be captured at their source and at the time the change is made.
This capture requirement has ramifications when you initially start a system
that uses Identity Synchronization for Windows. Specifically, Identity Synchronization for Windows needs to see a password
change for any entry before the entry is actually synchronized.
Synchronization in Windows NT environment involves modifying 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 resulting in no stale passwords on these two systems.
However, because you created the passwords by deterministic means, these passwords
might be easy to guess.
You can limit potential security breaches if you use Windows NT password
policy to force all users to change their password at their next login. As
each user changes their password, the Identity Synchronization for Windows password DLL installed
on the Primary Domain Controller forwards 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 this file in a production environment.
Example A–1 Example /etc/pam.conf File
#
#ident "@(#)pam.conf 1.20 02/01/23 SMI"
#
# Copyright 1996-2006 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
|
Dieses Buch im PDF-Format herunterladen (2398 KB)