pam_env.conf can be used to define a standardized environment for users that is set whenever the pam_env module is called. With it, preset environment variables using the following syntax:

VARIABLE  [DEFAULT=value]  [OVERRIDE=value]

A typical example of how pam_env can be used is the adaptation of the DISPLAY variable, which is changed whenever a remote login takes place. This is shown in Example 2.6, “pam_env.conf”.

REMOTEHOST     DEFAULT=localhost OVERRIDE=@{PAM_RHOST}
DISPLAY        DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}

The first line sets the value of the REMOTEHOST variable to localhost, which is used whenever pam_env cannot determine any other value. The DISPLAY variable in turn contains the value of REMOTEHOST. Find more information in the comments in /etc/security/pam_env.conf.

The purpose of pam_mount is to mount user home directories during the login process, and to unmount them during logout in an environment where a central file server keeps all the home directories of users. With this method, it is not necessary to mount a complete /home directory where all the user home directories would be accessible. Instead, only the home directory of the user who is about to log in, is mounted.

After installing pam_mount, a template of pam_mount.conf.xml is available in /etc/security. The description of the various elements can be found in the manual page man 5 pam_mount.conf.

A basic configuration of this feature can be done with YaST. Select Network Settings+Windows Domain Membership+Expert Settings to add the file server; see Section “Configuring Clients” (Chapter 27, Samba, ↑Administration Guide).

System limits can be set on a user or group basis in limits.conf, which is read by the pam_limits module. The file allows you to set hard limits, which may not be exceeded at all, and soft limits, which may be exceeded temporarily. For more information about the syntax and the options, see the comments in /etc/security/limits.conf.

To configure a NIS master server for your network, proceed as follows:

To configure additional NIS slave servers in your network, proceed as follows:

The basic LDAP client configuration dialog (Figure 4.6, “YaST: LDAP Client Configuration”) opens during installation if you choose LDAP user management or when you select Network Services+LDAP Client in the YaST Control Center in the installed system.

Figure 4.6. YaST: LDAP Client Configuration¶

To modify data on the server as administrator, click Advanced Configuration. The following dialog is split into two tabs. See Figure 4.7, “YaST: Advanced Configuration”.

Figure 4.7. YaST: Advanced Configuration¶

Use Configure User Management Settings to edit entries on the LDAP server. Access to the configuration modules on the server is then granted according to the ACLs and ACIs stored on the server. Follow the procedures outlined in Section 4.4.2, “Configuring the YaST Group and User Administration Modules”.

Use the YaST LDAP client to adapt the YaST modules for user and group administration and to extend them as needed. Define templates with default values for the individual attributes to simplify the data registration. The presets created here are stored as LDAP objects in the LDAP directory. The registration of user data is still done with the regular YaST modules for user and group management. The registered data is stored as LDAP objects on the server.

Figure 4.8. YaST: Module Configuration¶

The dialog for module configuration (Figure 4.8, “YaST: Module Configuration”) allows the creation of new modules, selection and modification of existing configuration modules, and design and modification of templates for such modules.

Figure 4.9. YaST: Configuration of an Object Template¶

Connect the template to its module by setting the susedefaulttemplate attribute value of the module to the DN of the adapted template.

The default values for an attribute can be created from other attributes by using a variable instead of an absolute value. For example, when creating a new user, cn=%sn %givenName is created automatically from the attribute values for sn and givenName.

Once all modules and templates are configured correctly and ready to run, new groups and users can be registered in the usual way with YaST.

Once the LDAP server is fully configured and all desired entries have been made according to the pattern described in Section 4.8, “Manually Administering LDAP Data”, start the LDAP server as root by entering rcldap start. To stop the server manually, enter the command rcldap stop. Query the status of the running LDAP server with rcldap status.

Use the YaST runlevel editor, described in Section “Configuring System Services (Runlevel) with YaST” (Chapter 9, Booting and Configuring a Linux System, ↑Administration Guide), to have the server started and stopped automatically on system bootup and shutdown. It is also possible to create the corresponding links to the start and stop scripts with the insserv command from a command prompt as described in Section “Init Scripts” (Chapter 9, Booting and Configuring a Linux System, ↑Administration Guide).

Once your LDAP server is correctly configured (it features appropriate entries for suffix, directory, rootdn, rootpw and index), proceed to entering records. OpenLDAP offers the ldapadd command for this task. If possible, add the objects to the database in bundles (for practical reasons). LDAP is able to process the LDIF format (LDAP data interchange format) for this. An LDIF file is a simple text file that can contain an arbitrary number of attribute and value pairs. The LDIF file for creating a rough framework for the example in Figure 4.1, “Structure of an LDAP Directory” would look like the one in Example 4.2, “An LDIF File”.

	Encoding of LDIF Files
LDAP works with UTF-8 (Unicode). Umlauts must be encoded correctly. Otherwise, avoid umlauts and other special characters or use iconv to convert the input to UTF-8.

# The Organization
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: Example dc: example

# The organizational unit development (devel)
dn: ou=devel,dc=example,dc=com
objectClass: organizationalUnit
ou: devel

# The organizational unit documentation (doc)
dn: ou=doc,dc=example,dc=com
objectClass: organizationalUnit
ou: doc

# The organizational unit internal IT (it)
dn: ou=it,dc=example,dc=com
objectClass: organizationalUnit
ou: it

Save the file with the .ldif suffix then pass it to the server with the following command:

ldapadd -x -D dn_of_the_administrator -W -f file.ldif

-x switches off the authentication with SASL in this case. -D declares the user that calls the operation. The valid DN of the administrator is entered here just like it has been configured in slapd.conf. In the current example, this is cn=Administrator,dc=example,dc=com. -W circumvents entering the password on the command line (in clear text) and activates a separate password prompt. The -f option passes the filename. See the details of running ldapadd in Example 4.3, “ldapadd with example.ldif”.

ldapadd -x -D cn=Administrator,dc=example,dc=com -W -f example.ldif 

Enter LDAP password: 
adding new entry "dc=example,dc=com" 
adding new entry "ou=devel,dc=example,dc=com" 
adding new entry "ou=doc,dc=example,dc=com" 
adding new entry "ou=it,dc=example,dc=com"

The user data of individuals can be prepared in separate LDIF files. Example 4.4, “LDIF Data for Tux” adds Tux to the new LDAP directory.

# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com
objectClass: inetOrgPerson
cn: Tux Linux
givenName: Tux
sn: Linux
mail: tux@example.com
uid: tux
telephoneNumber: +49 1234 567-8

An LDIF file can contain an arbitrary number of objects. It is possible to pass directory branches (entirely or in part) to the server in one go, as shown in the example of individual objects. If it is necessary to modify some data relatively often, a fine subdivision of single objects is recommended.

The tool ldapmodify is provided for modifying the data stock. The easiest way to do this is to modify the corresponding LDIF file and pass the modified file to the LDAP server. To change the telephone number of colleague Tux from +49 1234 567-8 to +49 1234 567-10, edit the LDIF file like in Example 4.5, “Modified LDIF File tux.ldif”.

# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com 
changetype: modify
replace: telephoneNumber 
telephoneNumber: +49 1234 567-10

Import the modified file into the LDAP directory with the following command:

ldapmodify -x -D cn=Administrator,dc=example,dc=com -W -f tux.ldif

Alternatively, pass the attributes to change directly to ldapmodify as follows:

For more information about ldapmodify and its syntax, see the ldapmodify man page.

OpenLDAP provides, with ldapsearch, a command line tool for searching data within an LDAP directory and reading data from it. This is a simple query:

ldapsearch -x -b dc=example,dc=com "(objectClass=*)"

The -b option determines the search base (the section of the tree within which the search should be performed). In the current case, this is dc=example,dc=com. To perform a more finely-grained search in specific subsections of the LDAP directory (for example, only within the devel department), pass this section to ldapsearch with -b. -x requests activation of simple authentication. (objectClass=*) declares that all objects contained in the directory should be read. This command option can be used after the creation of a new directory tree to verify that all entries have been recorded correctly and the server responds as desired. For more information about the use of ldapsearch, see the ldapsearch(1) man page.

Delete unwanted entries with ldapdelete. The syntax is similar to that of the other commands. To delete, for example, the complete entry for Tux Linux, issue the following command:

ldapdelete -x -D cn=Administrator,dc=example,dc=com -W cn=Tux \
Linux,ou=devel,dc=example,dc=com

During domain join, the server and the client establish a secure relation. On the client, the following tasks need to be performed to join the existing LDAP and Kerberos SSO environment provided by the Window domain controller. The entire join process is handled by the YaST Domain Membership module, which can be run during installation or in the installed system:

During client boot, the winbind daemon is started and retrieves the initial Kerberos ticket for the machine account. winbindd automatically refreshes the machine's ticket to keep it valid. To keep track of the current account policies, winbindd periodically queries the domain controller.

The login managers of GNOME and KDE (GDM and KDM) have been extended to allow the handling of AD domain login. Users can choose to log in to the primary domain the machine has joined or to one of the trusted domains with which the domain controller of the primary domain has established a trust relationship.

User authentication is mediated by a number of PAM modules as described in Section 5.2, “Background Information for Linux AD Support”. The pam_winbind module used to authenticate clients against Active Directory or NT4 domains is fully aware of Windows error conditions that might prohibit a user's login. The Windows error codes are translated into appropriate user-readable error messages that PAM gives at login through any of the supported methods (GDM, KDM, console, and SSH):

During a successful authentication, pam_winbind acquires a ticket granting ticket (TGT) from the Kerberos server of Active Directory and stores it in the user's credential cache. It also renews the TGT in the background, requiring no user interaction.

SUSE Linux Enterprise Server supports local home directories for AD users. If configured through YaST as described in Section 5.3, “Configuring a Linux Client for Active Directory”, user homes are created at the first login of a Windows (AD) user into the Linux client. These home directories look and feel entirely the same as standard Linux user home directories and work independently of the AD domain controller. Using a local user home, it is possible to access a user's data on this machine (even when the AD server is disconnected) as long as the Linux client has been configured to perform offline authentication.

Users in a corporate environment must have the ability to become roaming users (for example, to switch networks or even work disconnected for some time). To enable users to log in to a disconnected machine, extensive caching was integrated into the winbind daemon. The winbind daemon enforces password policies even in the offline state. It tracks the number of failed login attempts and reacts according to the policies configured in Active Directory. Offline support is disabled by default and must be explicitly enabled in the YaST Domain Membership module.

When the domain controller has become unavailable, the user can still access network resources (other than the AD server itself) with valid Kerberos tickets that have been acquired before losing the connection (as in Windows). Password changes cannot be processed unless the domain controller is online. While disconnected from the AD server, a user cannot access any data stored on this server. When a workstation has become disconnected from the network entirely and connects to the corporate network again later, SUSE Linux Enterprise Server acquires a new Kerberos ticket as soon as the user has locked and unlocked the desktop (for example, using a desktop screen saver).

To authenticate a GNOME client machine against an AD server, proceed as follows:

To authenticate a KDE client machine against an AD server, proceed as follows:

If configured to do so, SUSE Linux Enterprise Server creates a user home directory on the local machine on the first login of each AD authenticated user. This allows you to benefit from the AD support of SUSE Linux Enterprise Server while still having a fully functional Linux machine at your disposal.

As well as logging into the AD client machine using a graphical front-end, you can log in using the text-based console login or even remotely using SSH.

To log in to your AD client from a console, enter DOMAIN\user at the login: prompt and provide the password.

To remotely log in to your AD client machine using SSH, proceed as follows:

Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your username. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows you, it generates a random session key for further use between your client and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains the following information—all encrypted with a session key only the authentication server and the ticket-granting server know:

This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user password. Now that the client has received this response, you are prompted for your password. This password is converted into the key that can decrypt the package sent by the authentication server. The package is “unwrapped” and password and key are erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire, your workstation can prove your identity.

To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:

All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives it all the information needed about the client requesting its service, to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.

Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server does not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received is ignored.

Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends an authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.

Tickets are designed to be used for one server at a time. This implies that you have to get a new ticket each time you request another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the “ticket-granting service”. The ticket-granting service is a service (like any other service mentioned before) and uses the same access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it contacts the ticket-granting server. This request consists of the following components:

Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:

The new ticket has a lifetime, which is either the remaining lifetime of the ticket-granting ticket or the default for the service. The lesser of both values is assigned. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user.

Windows 2000 contains a Microsoft implementation of Kerberos 5. SUSE® Linux Enterprise Server uses the MIT implementation of Kerberos 5, find useful information and guidance in the MIT documentation at Section 6.5, “For More Information”.

Any Kerberos environment must meet the following requirements to be fully functional:

The following figure depicts a simple example network with just the minimum components needed to build a Kerberos infrastructure. Depending on the size and topology of your deployment, your setup may vary.

Figure 6.1. Kerberos Network Topology¶

	Configuring Subnet Routing
For a setup similar to the one in Figure 6.1, “Kerberos Network Topology”, configure routing between the two subnets (192.168.1.0/24 and 192.168.2.0/24). Refer to Section “Configuring Routing” (Chapter 21, Basic Networking, ↑Administration Guide) for more information on configuring routing with YaST.

The domain of a Kerberos installation is called a realm and is identified by a name, such as EXAMPLE.COM or simply ACCOUNTING. Kerberos is case-sensitive, so example.com is actually a different realm than EXAMPLE.COM. Use the case you prefer. It is common practice, however, to use uppercase realm names.

It is also a good idea to use your DNS domain name (or a subdomain, such as ACCOUNTING.EXAMPLE.COM). As shown below, your life as an administrator can be much easier if you configure your Kerberos clients to locate the KDC and other Kerberos services via DNS. To do so, it is helpful if your realm name is a subdomain of your DNS domain name.

Unlike the DNS name space, Kerberos is not hierarchical. You cannot set up a realm named EXAMPLE.COM, have two “subrealms” named DEVELOPMENT and ACCOUNTING underneath it, and expect the two subordinate realms to somehow inherit principals from EXAMPLE.COM. Instead, you would have three separate realms for which you would have to configure crossrealm authentication for users from one realm to interact with servers or other users from another realm.

For the sake of simplicity, let us assume you are setting up just one realm for your entire organization. For the remainder of this section, the realm name EXAMPLE.COM is used in all examples.

The first thing required to use Kerberos is a machine that acts as the key distribution center, or KDC for short. This machine holds the entire Kerberos user database with passwords and all information.

The KDC is the most important part of your security infrastructure—if someone breaks into it, all user accounts and all of your infrastructure protected by Kerberos is compromised. An attacker with access to the Kerberos database can impersonate any principal in the database. Tighten security for this machine as much as possible:

To use Kerberos successfully, make sure that all system clocks within your organization are synchronized within a certain range. This is important because Kerberos protects against replayed credentials. An attacker might be able to observe Kerberos credentials on the network and reuse them to attack the server. Kerberos employs several defenses to prevent this. One of them is that it puts time stamps into its tickets. A server receiving a ticket with a time stamp that differs from the current time rejects the ticket.

Kerberos allows a certain leeway when comparing time stamps. However, computer clocks can be very inaccurate in keeping time—it is not unheard of for PC clocks to lose or gain half an hour over the course of a week. For this reason, configure all hosts on the network to synchronize their clocks with a central time source.

A simple way to do so is by installing an NTP time server on one machine and having all clients synchronize their clocks with this server. Do this either by running an NTP daemon in client mode on all these machines or by running ntpdate once a day from all clients (this solution probably works for a small number of clients only). The KDC itself needs to be synchronized to the common time source as well. Because running an NTP daemon on this machine would be a security risk, it is probably a good idea to do this by running ntpdate via a cron entry. To configure your machine as an NTP client, proceed as outlined in Section “Configuring an NTP Client with YaST” (Chapter 23, Time Synchronization with NTP, ↑Administration Guide).

A different way to secure the time service and still use the NTP daemon is to attach a hardware reference clock to a dedicated NTP server as well as an additional hardware reference clock to the KDC.

It is also possible to adjust the maximum deviation Kerberos allows when checking time stamps. This value (called clock skew) can be set in the krb5.conf as described in Section 6.4.6.2.3, “Adjusting the Clock Skew”.

This section covers the initial configuration and installation of the KDC, including the creation of an administrative principal. This procedure consists of several steps:

kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  
Re-enter KDC database master key to verify:  

kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

kadmin.local

kadmin> ank geeko

geeko@EXAMPLE.COM's Password: 
Verifying password: 

Once the supporting infrastructure is in place (DNS, NTP) and the KDC has been properly configured and started, configure the client machines. You can either use YaST to configure a Kerberos client or use one of the two manual approaches described below.

6.4.6.1. Configuring a Kerberos Client with YaST¶

Rather than manually editing all relevant configuration files when configuring a Kerberos client, let YaST do the job for you. You can either perform the client configuration during the installation of your machine or in the installed system as follows:

1. Log in as root and select Network Services+Kerberos Client (Figure 6.2, “YaST: Basic Configuration of a Kerberos Client”).

2. Select Use Kerberos.

3. To configure a DNS-based Kerberos client, proceed as follows:

   1. DNS-Based Static Kerberos Client

      	Using DNS Support
      The Use DNS option cannot be selected if the DNS server does not provide such data.

   2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH support, time synchronization, and extended PAM configurations.

4. To configure a static Kerberos client, proceed as follows:

   1. Set Default Domain, Default Realm, and KDC Server Address to the values that match your setup.

   2. Click Advanced Settings to configure details on ticket-related issues, OpenSSH support, time synchronization, and extended PAM configurations.

Figure 6.2. YaST: Basic Configuration of a Kerberos Client¶

To configure ticket-related options in the Advanced Settings dialog (Figure 6.3, “YaST: Advanced Configuration of a Kerberos Client”), choose from the following options:

• Specify the Default Ticket Lifetime and the Default Renewable Lifetime in days, hours, or minutes (using the units of measurement d, h, and m, with no blank space between the value and the unit).

• To forward your complete identity (to use your tickets on other hosts), select Forwardable.

• Enable the transfer of certain tickets by selecting Proxiable.

• Enable Kerberos authentication support for your OpenSSH client by selecting the corresponding check box. The client then uses Kerberos tickets to authenticate with the SSH server.

• Exclude a range of user accounts from using Kerberos authentication by providing a value for the Minimum UID that a user of this feature must have. For instance, you may want to exclude the system administrator (root).

• Use Clock Skew to set a value for the allowable difference between the time stamps and your host's system time.

• To keep the system time in sync with an NTP server, you can also set up the host as an NTP client by selecting NTP Configuration, which opens the YaST NTP client dialog that is described in Section “Configuring an NTP Client with YaST” (Chapter 23, Time Synchronization with NTP, ↑Administration Guide). After finishing the configuration, YaST performs all the necessary changes and the Kerberos client is ready to use.

Figure 6.3. YaST: Advanced Configuration of a Kerberos Client¶

For more information about the configuration of Expert PAM Settings and PAM Services tabs, see the official documentation referenced in Section 6.5, “For More Information” and the manual page man 5 krb5.conf, which is part of the krb5-doc package.

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
        www.foobar.com = EXAMPLE.COM

_kerberos.www.foobar.com.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

To be able to add and remove principals from the Kerberos database without accessing the KDC's console directly, tell the Kerberos administration server which principals are allowed to do what by editing /var/lib/kerberos/krb5kdc/kadm5.acl. The ACL (access control list) file allows you to specify privileges with a precise degree of control. For details, refer to the manual page with man 8 kadmind.

For now, just grant yourself the privilege to administer the database by putting the following line into the file:

geeko/admin              *

Replace the username geeko with your own. Restart kadmind for the change to take effect.

You should now be able to perform Kerberos administration tasks remotely using the kadmin tool. First, obtain a ticket for your admin role and use that ticket when connecting to the kadmin server:

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

Using the getprivs command, verify which privileges you have. The list shown above is the full set of privileges.

As an example, modify the principal geeko:

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:

kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc joe
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

This changes the maximum ticket life time to eight hours. For more information about the kadmin command and the options available, see the krb5-doc package or refer to the man8 kadmin manual page.

So far, only user credentials have been discussed. However, Kerberos-compatible services usually need to authenticate themselves to the client user, too. Therefore, special service principals must be present in the Kerberos database for each service offered in the realm. For example, if ldap.example.com offers an LDAP service, you need a service principal, ldap/ldap.example.com@EXAMPLE.COM, to authenticate this service to all clients.

The naming convention for service principals is service/hostname@REALM, where hostname is the host's fully qualified hostname.

Valid service descriptors are:

Service principals are similar to user principals, but have significant differences. The main difference between a user principal and a service principal is that the key of the former is protected by a password—when a user obtains a ticket-granting ticket from the KDC, he needs to type his password so Kerberos can decrypt the ticket. It would be quite inconvenient for the system administrator if he had to obtain new tickets for the SSH daemon every eight hours or so.

Instead, the key required to decrypt the initial ticket for the service principal is extracted by the administrator from the KDC only once and stored in a local file called the keytab. Services such as the SSH daemon read this key and use it to obtain new tickets automatically, when needed. The default keytab file resides in /etc/krb5.keytab.

To create a host service principal for jupiter.example.com enter the following commands during your kadmin session:

kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

Instead of setting a password for the new principal, the -randkey flag tells kadmin to generate a random key. This is used here because no user interaction is wanted for this principal. It is a server account for the machine.

Finally, extract the key and store it in the local keytab file /etc/krb5.keytab. This file is owned by the superuser, so you must be root to execute the next command in the kadmin shell:

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

When completed, make sure that you destroy the admin ticket obtained with kinit above with kdestroy.

SUSE® Linux Enterprise Server comes with a PAM module named pam_krb5, which supports Kerberos login and password update. This module can be used by applications such as console login, su, and graphical login applications like KDM (where the user presents a password and would like the authenticating application to obtain an initial Kerberos ticket on his behalf). To configure PAM support for Kerberos, use the following command:

pam-config --add --krb5

The above command adds the pam_krb5 module to the existing PAM configuration files and makes sure it is called in the right order. To make precise adjustments to the way in which pam_krb5 is used, edit the file /etc/krb5.conf and add default applications to pam. For details, refer to the manual page with man 5 pam_krb5.

The pam_krb5 module was specifically not designed for network services that accept Kerberos tickets as part of user authentication. This is an entirely different matter, and is discussed below.

OpenSSH supports Kerberos authentication in both protocol version 1 and 2. In version 1, there are special protocol messages to transmit Kerberos tickets. Version 2 does not use Kerberos directly anymore, but relies on GSSAPI, the General Security Services API. This is a programming interface that is not specific to Kerberos—it was designed to hide the peculiarities of the underlying authentication system, be it Kerberos, a public-key authentication system like SPKM, or others. However, the included GSSAPI library only supports Kerberos.

To use sshd with Kerberos authentication, edit /etc/ssh/sshd_config and set the following options:

# These are for protocol version 1 
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Then restart your SSH daemon using rcsshd restart.

To use Kerberos authentication with protocol version 2, enable it on the client side as well. Do this either in the systemwide configuration file /etc/ssh/ssh_config or on a per-user level by editing ~/.ssh/config. In both cases, add the option GSSAPIAuthentication yes.

You should now be able to connect using Kerberos authentication. Use klist to verify that you have a valid ticket, then connect to the SSH server. To force SSH protocol version 1, specify the -1 option on the command line.

	Additional Information
The file /usr/share/doc/packages/openssh/README.kerberos discusses the interaction of OpenSSH and Kerberos in more detail.

	Additional Directives for Protocol Version 2
Since SLES 11 SP3, the GSSAPIKeyExchange is supported. This directive specifies how host keys are exchanged. For further information see manual page sshd_config(5).

When using Kerberos, one way to distribute the user information (such as user ID, groups, and home directory) in your local network is to use LDAP. This requires a strong authentication mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos for LDAP communication, too.

OpenLDAP implements most authentication flavors through SASL, the simple authentication session layer. SASL is basically a network protocol designed for authentication. The SASL implementation is cyrus-sasl, which supports a number of different authentication flavors. Kerberos authentication is performed through GSSAPI (General Security Services API). By default, the SASL plug-in for GSSAPI is not installed. Install the cyrus-sasl-gssapi with YaST.

To enable Kerberos to bind to the OpenLDAP server, create a principal ldap/ldap.example.com and add that to the keytab.

By default, the LDAP server slapd runs as user and group ldap, while the keytab file is readable by root only. Therefore, either change the LDAP configuration so the server runs as root or make the keytab file readable by the group ldap. The latter is done automatically by the OpenLDAP start script (/etc/init.d/ldap) if the keytab file has been specified in the OPENLDAP_KRB5_KEYTAB variable in /etc/sysconfig/openldap and the OPENLDAP_CHOWN_DIRS variable is set to yes, which is the default setting. If OPENLDAP_KRB5_KEYTAB is left empty, the default keytab under /etc/krb5.keytab is used and you must adjust the privileges yourself as described below.

To run slapd as root, edit /etc/sysconfig/openldap. Disable the OPENLDAP_USER and OPENLDAP_GROUP variables by putting a comment character in front of them.

To make the keytab file readable by group LDAP, execute

chgrp ldap /etc/krb5.keytab
chmod 640 /etc/krb5.keytab

A third (and maybe the best) solution is to tell OpenLDAP to use a special keytab file. To do this, start kadmin, and enter the following command after you have added the principal ldap/ldap.example.com:

ktadd -k /etc/openldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM

Then in the shell run:

chown ldap.ldap /etc/openldap/ldap.keytab 
chmod 600 /etc/openldap/ldap.keytab

To tell OpenLDAP to use a different keytab file, change the following variable in /etc/sysconfig/openldap:

OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"

Finally, restart the LDAP server using rcldap restart.

ldapsearch -b ou=people,dc=example,dc=com '(uid=geeko)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# geeko, people, example.com
dn: uid=geeko,ou=people,dc=example,dc=com
uid: geeko
cn: Olaf Kirch
[...]

dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: uid=(.*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=example,dc=com

At the moment, not all applications requiring privileges make use of PolicyKit. Find the most important policies available on SUSE® Linux Enterprise Server below, sorted into the categories where they are used.

Every time a PolicyKit-enabled process carries out a privileged operation, PolicyKit is asked whether this process is entitled to do so. PolicyKit answers according to the policy defined for this process. The answers can be yes, no, or authentication needed. By default, a policy contains implicit privileges, which automatically apply to all users. It is also possible to specify explicit privileges which apply to a specific user.

Each application supporting PolicyKit comes with a default set of implicit policies defined by the application's developers. Those policies are the so-called “upstream defaults”. The privileges defined by the upstream defaults are not necessarily the ones that are activated by default on SUSE Linux Enterprise Server. SUSE Linux Enterprise Server comes with a predefined set of privileges that override the upstream defaults. The default policies for SUSE Linux Enterprise Server are defined in /etc/polkit-default-privs.standard and /etc/polkit-default-privs.restrictive. The .standard file defines privileges suitable for most desktop systems. The .restrictive set of privileges is designed for machines administrated centrally. It is active by default.

To switch between the two sets of default privileges, adjust the value of POLKIT_DEFAULT_PRIVS to either restrictive or standard in /etc/sysconfig/security. Then run the command set_polkit_default_privs as root.

Do not modify /etc/polkit-default-privs.standard nor /etc/polkit-default-privs.restrictive. In order to define your own custom set of privileges, use /etc/polkit-default-privs.local. For details, refer to Section 9.2.3.1, “Modifying Configuration Files for Implicit Privileges”.

	Using the Authorizations Tool
Authorizations is a graphical tool and therefore not installed when the respective GNOME or KDE desktop environment is not installed. In this case you need to install the package PolicyKit-gnome (GNOME) or libpolkit-qt0 (KDE) in order to use the tool.

Start the Authorizations tool from a desktop environment by pressing Alt+F2 and entering polkit-gnome-authorization or polkit-kde-authorization, respectively.

Figure 9.1. The Authorizations Main Window (GNOME)¶

The Authorizations window is divided into two panes: The left-hand pane shows all policies available in a tree view, while the right-hand pane displays details for the policy selected and offers means to change it.

The KDE and GNOME Authorizations dialogs are very similar. The most noticeable difference is the location where details about the chosen policy are displayed: the GNOME dialog displays them in a dedicated Actions section on the right-hand pane. It holds the following information:

The KDE dialog shows the identifier string directly in the tree view on the left-hand pane, together with a short description, which is also displayed at the top of the right-hand pane, together with the vendor link.

Alter any settings from the right-hand pane, as described below:

PolicyKit comes with two command line tools for changing implicit privileges and for assigning explicit privileges. Each existing policy has got a speaking, unique name with which it can be identified and which is used with the command line tools. List all available policies with the command polkit-action.

Adjusting privileges by modifying configuration files is useful when you want to deploy the same set of policies to different machines, for example to the computers of a specific team. It is possible to change implicit as well as explicit privileges by modifying configuration files.

<privilege_identifier>     <any session>:<inactive session>:<active session>

org.freedesktop.policykit.modify-defaults     auth_admin_keep_always

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">
<config version="0.1">
  <match action="org.freedesktop.packagekit.system-update">
    <match user="tux">
      <return result="yes"/>
    </match>
  </match>
  <match action="org.freedesktop.policykit.*">
    <match user="tux|wilber">
      <return result="no"/>
    </match>
  </match>
  <define_admin_auth group="administrators"/>
</config>

SUSE Linux Enterprise Server comes with a predefined set of privileges that is activated by default and thus overrides the upstream defaults. For details, refer to Section 9.1.3, “Default Privileges”.

Since the graphical PolicyKit tools and the command line tools always operate on the upstream defaults, SUSE Linux Enterprise Server includes an additional command-line tool, set_polkit_default_privs. It resets privileges to the values defined in /etc/polkit-default-privs.*. However, the command set_polkit_default_privs will only reset policies that are set to the upstream defaults.

In certain situations, the access permissions may be too restrictive. Therefore, Linux has additional settings that enable the temporary change of the current user and group identity for a specific action. For example, the passwd program normally requires root permissions to access /etc/passwd. This file contains some important information, like the home directories of users and user and group IDs. Thus, a normal user would not be able to change passwd, because it would be too dangerous to grant all users direct access to this file. A possible solution to this problem is the setuid mechanism. setuid (set user ID) is a special file attribute that instructs the system to execute programs marked accordingly under a specific user ID. Consider the passwd command:

-rwsr-xr-x  1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

You can see the s that denotes that the setuid bit is set for the user permission. By means of the setuid bit, all users starting the passwd command execute it as root.

The setuid bit applies to users. However, there is also an equivalent property for groups: the setgid bit. A program for which this bit was set runs under the group ID under which it was saved, no matter which user starts it. Therefore, in a directory with the setgid bit, all newly created files and subdirectories are assigned to the group to which the directory belongs. Consider the following example directory:

drwxrws--- 2 tux archive 48 Nov 19 17:12  backup

You can see the s that denotes that the setgid bit is set for the group permission. The owner of the directory and members of the group archive may access this directory. Users that are not members of this group are “mapped” to the respective group. The effective group ID of all written files will be archive. For example, a backup program that runs with the group ID archive is able to access this directory even without root privileges.

There is also the sticky bit. It makes a difference whether it belongs to an executable program or a directory. If it belongs to a program, a file marked in this way is loaded to RAM to avoid needing to get it from the hard disk each time it is used. This attribute is used rarely, because modern hard disks are fast enough. If this bit is assigned to a directory, it prevents users from deleting each other's files. Typical examples include the /tmp and /var/tmp directories:

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits” and Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits” illustrate the two cases of a minimum ACL and an extended ACL. The figures are structured in three blocks—the left block shows the type specifications of the ACL entries, the center block displays an example ACL, and the right block shows the respective permission bits according to the conventional permission concept (for example, as displayed by ls -l). In both cases, the owner class permissions are mapped to the ACL entry owner. Other class permissions are mapped to the respective ACL entry. However, the mapping of the group class permissions is different in the two cases.

Figure 10.1. Minimum ACL: ACL Entries Compared to Permission Bits¶

In the case of a minimum ACL—without mask—the group class permissions are mapped to the ACL entry owning group. This is shown in Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits”. In the case of an extended ACL—with mask—the group class permissions are mapped to the mask entry. This is shown in Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits”.

Figure 10.2. Extended ACL: ACL Entries Compared to Permission Bits¶

This mapping approach ensures the smooth interaction of applications, regardless of whether they have ACL support. The access permissions that were assigned by means of the permission bits represent the upper limit for all other “fine adjustments” made with an ACL. Changes made to the permission bits are reflected by the ACL and vice versa.

With getfacl and setfacl on the command line, you can access ACLs. The usage of these commands is demonstrated in the following example.

Before creating the directory, use the umask command to define which access permissions should be masked each time a file object is created. The command umask 027 sets the default permissions by giving the owner the full range of permissions (0), denying the group write access (2), and giving other users no permissions at all (7). umask actually masks the corresponding permission bits or turns them off. For details, consult the umask man page.

mkdir mydir creates the mydir directory with the default permissions as set by umask. Use ls -dl mydir to check whether all permissions were assigned correctly. The output for this example is:

drwxr-x--- ... tux project3 ... mydir

With getfacl mydir, check the initial state of the ACL. This gives information like:

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
group::r-x 
other::---

The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries owner, owning group, and other. In fact, in the case of this minimum ACL, the getfacl command does not produce any information you could not have obtained with ls.

Modify the ACL to assign read, write, and execute permissions to an additional user geeko and an additional group mascots with:

setfacl -m user:geeko:rwx,group:mascots:rwx mydir

The option -m prompts setfacl to modify the existing ACL. The following argument indicates the ACL entries to modify (multiple entries are separated by commas). The final part specifies the name of the directory to which these modifications should be applied. Use the getfacl command to take a look at the resulting ACL.

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
user:geeko:rwx 
group::r-x
group:mascots:rwx 
mask::rwx 
other::---

In addition to the entries initiated for the user geeko and the group mascots, a mask entry has been generated. This mask entry is set automatically so that all permissions are effective. setfacl automatically adapts existing mask entries to the settings modified, unless you deactivate this feature with -n. mask defines the maximum effective access permissions for all entries in the group class. This includes named user, named group, and owning group. The group class permission bits displayed by ls -dl mydir now correspond to the mask entry.

drwxrwx---+ ... tux project3 ... mydir

The first column of the output contains an additional + to indicate that there is an extended ACL for this item.

According to the output of the ls command, the permissions for the mask entry include write access. Traditionally, such permission bits would mean that the owning group (here project3) also has write access to the directory mydir. However, the effective access permissions for the owning group correspond to the overlapping portion of the permissions defined for the owning group and for the mask—which is r-x in our example (see Table 10.2, “Masking Access Permissions”). As far as the effective permissions of the owning group in this example are concerned, nothing has changed even after the addition of the ACL entries.

Edit the mask entry with setfacl or chmod. For example, use chmod g-w mydir. ls -dl mydir then shows:

drwxr-x---+ ... tux project3 ... mydir

getfacl mydir provides the following output:

# file: mydir 
# owner: tux 
# group: project3 
user::rwx 
user:geeko:rwx          # effective: r-x
group::r-x 
group:mascots:rwx       # effective: r-x 
mask::r-x 
other::---

After executing the chmod command to remove the write permission from the group class bits, the output of the ls command is sufficient to see that the mask bits must have changed accordingly: write permission is again limited to the owner of mydir. The output of the getfacl confirms this. This output includes a comment for all those entries in which the effective permission bits do not correspond to the original permissions, because they are filtered according to the mask entry. The original permissions can be restored at any time with chmod g+w mydir.

Directories can have a default ACL, which is a special kind of ACL defining the access permissions that objects in the directory inherit when they are created. A default ACL affects both subdirectories and files.

A check algorithm is applied before any process or application is granted access to an ACL-protected file system object. As a basic rule, the ACL entries are examined in the following sequence: owner, named user, owning group or named group, and other. The access is handled in accordance with the entry that best suits the process. Permissions do not accumulate.

Things are more complicated if a process belongs to more than one group and would potentially suit several group entries. An entry is randomly selected from the suitable entries with the required permissions. It is irrelevant which of the entries triggers the final result “access granted”. Likewise, if none of the suitable group entries contain the required permissions, a randomly selected entry triggers the final result “access denied”.

	Password Input
Make sure to memorize the password for your encrypted partitions well. Without that password, you cannot access or restore the encrypted data.

The YaST expert dialog for partitioning offers the options needed for creating an encrypted partition. To create a new encrypted partition proceed as follows:

During the boot process, the operating system asks for the password before mounting any encrypted partition which is set to be auto-mounted in /etc/fstab. Such a partition is then available to all users once it has been mounted.

To skip mounting the encrypted partition during start-up, click Enter when prompted for the password. Then decline the offer to enter the password again. In this case, the encrypted file system is not mounted and the operating system continues booting, blocking access to your data.

When you need to mount an encrypted partition which is not mounted during the boot process, open your favorite file manager and click on the partition entry in the pane listing common places on your file system. You will be prompted for a password and the partition will be mounted.

When you are installing your system on a machine where partitions already exist, you can also decide to encrypt an existing partition during installation. In this case follow the description in Section 11.1.2, “Creating an Encrypted Partition on a Running System” and be aware that this action destroys all data on the existing partition.

	Activating Encryption on a Running System
It is also possible to create encrypted partitions on a running system. However, encrypting an existing partition destroys all data on it, and requires resizing and restructuring of existing partitions.

On a running system, select System+Partitioner in the YaST Control Center. Click Yes to proceed. In the Expert Partitioner, select the partition to encrypt and click Edit. The rest of the procedure is the same as described in Section 11.1.1, “Creating an Encrypted Partition during Installation”.

Instead of using a partition, it is possible to create an encrypted file, which can hold other files or folders containing confidential data. Such container files are created from the YaST Expert Partitioner dialog. Select Crypt Files+Add Crypt File and enter the full path to the file and its size. If YaST should create the container file, activate the check box Create Loop File. Accept or change the proposed formatting settings and the file system type. Specify the mount point and make sure that Encrypt Device is checked.

Click Next, enter your password for decrypting the file, and confirm with Finish.

The advantage of encrypted container files over encrypted partitions is that they can be added without repartitioning the hard disk. They are mounted with the help of a loop device and behave just like normal partitions.

YaST treats removable media (like external hard disks or USB flash drives) the same as any other hard disk. Container files or partitions on such media can be encrypted as described above. Do not, however, enable mounting at boot time, because removable media are usually only connected while the system is running.

If you encrypted your removable device with YaST, the KDE and GNOME desktops automatically recognize the encrypted partition and prompt for the password when the device is detected. If you plug in a FAT formatted removable device while running KDE or GNOME, the desktop user entering the password automatically becomes the owner of the device and can read and write files. For devices with a file system other than FAT, change the ownership explicitly for users other than root to enable these users to read or write files on the device.