Novell Open Enterprise Server Administrators Handbook SUSE Linux Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Novell Open Enterprise Server Administrators Handbook SUSE Linux Edition [Electronic resources] - نسخه متنی

Mike Latimer

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید






Logging in to Linux


After installing and booting a SLES server, you should be presented with either a text or graphical login prompt. Entering an appropriate username and password will give you access to the server. For an administrator, it is important to understand how access is granted and how local SLES user accounts are configured. It is also important to have this knowledge prior to implementing OES components such as Linux User Management (LUM). The following section will briefly discuss local user accounts and how the local authentication process works.

Local Account Files


On a SLES9 server, local user accounts are defined in the /etc/passwd file as shown in Figure 3.1. Every user defined in this file must have certain attributes that are used by the server for determining such things as user permissions and login name. The format of /etc/passwd is one user account entry per line.

Figure 3.1. An example of the /etc/passwd file.

Each line within the passwd file is made up of five fields, separated by colons. These fields provide the necessary attributes for user accounts to be considered valid by the operating system. The purpose of each field is documented in Chapter 6.) Users and groups can also be added to the system using several command-line utilities. A few of these utilities are listed in Table 3.4.

Table 3.4. Local User and Group Utilities

UTILITY DESCRIPTION
useradd Create a new local user account
userdel Delete local user account
passwd Set or change user password
usermod Modify a local user account (including password expiration intervals)
grpadd Add a local group
grpdel Delete local group
pwconv Convert to secure shadow accounts
pwunconv Convert from shadow accounts to normal password accounts

The Root Administrator Account


Within Linux, the superuser or administrator account is known as root. This account has all rights over everything found on a Linux server. It is important to realize that these rights cannot be locked out or restricted in any way. Given the vast amount of power root has, a secure and confidential password must be used for this account. It is also important to avoid using the root account just for the sake of accessibility. When you are logged in as root, malicious scripts or programs can potentially be deadly to your Linux environment if they are run accidentally. Be sure to avoid these issues by logging in as a regular user and only using root privileges when necessary. (See the "Switching Identities" section later in this chapter for more information on that topic.) The UID for root is always 0 (zero). This is hard-coded into many aspects of Linux and should not be manually adjusted. Also, when integrating local Linux accounts into OES through LUM, the root account should not be included. Local user account access to the server as the root user is critical for many troubleshooting steps.

NOTE

The UID for root is always 0. UID numbers from 1 to 999 are reserved for special daemon or system user accounts. Normal SLES user account UID numbers begin at 1000.

The Login Process


There are actually many methods by which a user can authenticate or log in to a Linux server. The tables in the preceding section describe how local user accounts are stored in the system, but having a local user account is only one step in the login process.Chapter 8, "Users and Network Security." LUM is actually quite complex, and understanding the authentication process of a local login should help you get prepared for implementing LUM. In SLES, Pluggable-Authentication Modules (PAM) are used to provide user authentication to all PAM-enabled services. PAM-enabled services include local logins, secure shell access, and most other services requiring authentication. PAM configuration of these services is performed using service-specific configuration files found in /etc/pam.d. In this directory, each service relying on PAM to enforce authentication has a configuration file. The default login configuration file used for local logins is shown in Figure 3.2.

Figure 3.2. Contents of /etc/pam.d/login.

PAM configuration divides the authentication process across four distinct module types. The explanations for these module types can be found in Table 3.5.

Table 3.5. PAM Module Types
MODULE TYPE DESCRIPTION
Auth Used to establish the user's validity through checking passwords or other credentials.
Account Used to ensure a valid user account exists and is allowed access. This stage will not allow expired, disabled, or otherwise invalid accounts to proceed.
Password Used to set the authentication token (password) of the user.
Session Used to create a session for the authenticated user.

Each module type takes one of four control flags as a parameter used to indicate how that specific module is to be handled. These control flags are explained in Table 3.6.

Table 3.6. PAM Control Flags
CONTROL FLAG DESCRIPTION
Required All module checks are required to complete successfully. If a module fails, all other modules are processed. All failures are then returned to the authentication process.
Requisite Similar to required, but with a requisite control flag, execution halts at the first failure. The corresponding error code is immediately returned to the authentication process.
Sufficient After a sufficient module is successfully processed, the module type is considered to have been successfully processed and execution skips to the next module type.
Optional Optional modules are not required to be successfully completed in order for the login to be successful.

The last two fields of the PAM configuration file for any service are used to denote external authentication modules and any parameters those modules may require. Many different modules can be used for each portion of the authentication stages. These modules range from providing LDAP lookup for user accounts to checking passwords for certain security requirements. In the case of a login process based on the configuration file in Figure 3.2, the authentication process would have to successfully pass all requirements for each specified module in order to generate a fully authenticated connection. In other words, the pam_unix2.so module would ensure that the user's account exists and is allowed access. The pam_securetty.so module then determines if the user is allowed to log in from the current terminal. The pam_nologin.so module is used to check for the existence of an /etc/nologin file, which would prevent non-root users from logging in. This process continues until all modules have been processed. If the PAM modules are successfully processed, the user is authenticated and provided with a shell prompt. Otherwise, the user is denied access.

NOTE

For more information on PAM configuration, including possible authentication modules and their options, please refer to the PAM documentation found in /usr/share/doc/packages/pam.

Switching Identities


When you have logged in to a Linux environment using your local account, you may find that you have insufficient privileges to accomplish a specific task. In order to execute certain commands, or have rights to view specific files, it is sometimes required to change your identity to that of the root user. To do this, you must use the su command. The su or "substitute user" command is used to temporarily substitute your identity with that of another user. When run as a normal user and executed with no parameters, the su command will prompt for root's password. After the password has been entered, the current session will be given root-level access. (To return to your normal permissions, use exit.) The su command can also be used to switch to the identity of another, non-root user. To perform this action, specify the desired user name as a parameter to su, as shown in Figure 3.3.

Figure 3.3. An example of using the su command.

It is important to realize that the su command does not otherwise modify the current environment. In other words, executing su will not change the current directory, or the currently configured environment variables. When switching to another user's identity, it is often desirable to also assume that user's environment. This requires switching identities and also executing a normal login process for the new user. In order to temporarily switch users and complete a login cycle as that user, the su command must be executed using a "-" command-line parameter, as shown in Figure 3.4.

Figure 3.4. Example of the su - command.



/ 150