From SELinux Wiki
|Revision as of 21:36, 10 December 2008 (edit)
CraigGrube (Talk | contribs)
(→on the Client)
← Previous diff
|Revision as of 21:40, 10 December 2008 (edit) (undo)
CraigGrube (Talk | contribs)
(→Authentication Service, Client Side)
Next diff →
|Line 59:||Line 59:|
|== Authentication Service, Client Side ==||== Authentication Service, Client Side ==|
|-||authentication-tui ||+||authentication-tui and checking a box|
|to turn on Kerberos authentication. But below that, what was||to turn on Kerberos authentication. But below that, what was|
|actually happening was changes within the /etc/pam.d/system-auth||actually happening was changes within the /etc/pam.d/system-auth|
|file. This is part of the authentication system on the machines,||file. This is part of the authentication system on the machines,|
|-||the ||+||the Authentication Module (PAM). This file was changed so|
|that system authentication would additionally use the pam_krb5.so||that system authentication would additionally use the pam_krb5.so|
|library which authenticates a user-name using the Kerberos services.||library which authenticates a user-name using the Kerberos services.|
Revision as of 21:40, 10 December 2008
The network users are mapped between the Kerberos, NFS, and LDAP server and the network hosts (i.e. Kerberos, NFS and LDAP clients) using several different sub-systems. The key to connecting them all is the user-name, the string of text that uniquely identifies an individual on the network. This string is shared across the hosts and between the three servers. The use of user-name can further be broken down between identity authentication and identity mapping services.
The two 'Basic Steps' sections below show the basic authentication and identity mapping steps taken when a user logs on to a client machine. The sections following offer a more detailed explanation of what is going on how the machines were configured to do it.
Simplified Authentication Steps for User Login
on the Client
- PAM is used to authenticate users, which is configured to use Kerberos.
- Kerberos credentials are associated with a username, which require the correct password to be accessed.
on the Server
- Kerberos server responds to client requests to check the user's password and return credentials.
Note: The password is not sent across the network. It is checked locally on the client using response from the Kerberos server.
Simplified User Mapping Steps
on the Client
- Examine /etc/idmapd.conf to find how where to do user translations
- indicates nsswitch
- Examine /etc/nsswitch.conf to find out what to use for translations
- indicates LDAP for user info and auto-mounting
- User enters user-name, look up user-name on LDAP server
- returns UID, GID, shell, home directory path
- Mount users NFS home directory using the LDAP values for path, UID, GID, etc...
- Login user.
on the NFS Server
- NFS server maps user-name and group names to local UID and GID values (i.e. LDAP values are not used).
Identity Authentication Service
The authentication service is provided mainly by the Kerberos server. The realm structure can be more complicated, but in this example, the network user-name matches the Kerberos principal of user-name@REALM (e.g. newuser@EXAMPLE.COM).
Authentication Service, Server Side
The identity of the user-name is authenticated by the Kerberos server interacting with the host machines and the NFS and LDAP servers. Principals are added and deleted on the Kerberos server and it is responsible for checking that a user-name is in fact that user. It then hands out credentials for that user that can in turn be checked by the host machines and the other servers.
Authentication Service, Client Side
Host can be configured using authentication-tui and checking a box to turn on Kerberos authentication. But below that, what was actually happening was changes within the /etc/pam.d/system-auth file. This is part of the authentication system on the machines, the Plug-able Authentication Module (PAM). This file was changed so that system authentication would additionally use the pam_krb5.so library which authenticates a user-name using the Kerberos services.
Identity Mapping Services
The identity information is provided by the NFS and LDAP servers and is mapped using a user-name. LDAP provides the user information necessary for the client hosts to instantiate a user. NFS provides the users' personal files. It provides the files within their home directories.
The user-name is used to look up that user-name within the LDAP directory. The LDAP server maps that user-name to the information needed by the host machines to instantiate that user locally. In this example the main information stored is:
- User ID (a unique number identifying the user)
- Groups to which the user-name is a member.
- User's shell
- Path to the user's home directory
- Group information
- Group-name to Group ID (unique group number)
NFS Server User Mapping
The server in this example uses independent User IDs (UIDs) and Group IDs (GIDs). These are associated with user-names and group names on its local system and do not use LDAP provided numerical values for UID/GID. When a client connects to the NFS server, the user-name and group-name values are mapped to the local file system's UID and GIDs.
Host Machine Identity Mapping
The host machines are configured in several different ways in order to map user Identity. One of the first sources is the /etc/idmapd.conf file's Translation section:
[Translation] Method = nsswitch
The client configuration for this file was shown in one of the NFS install instruction sections, but since 'nsswitch' is the current default for F9, it probably did not need to be changed.
/etc/rc.d/nsswitch.conf is the file that configures nsswitch. Nsswitch is the Name Service Switch configuration for the host. This configuration file sets the options available, and their order, when using the GNU C library API's (e.g. libc.so.6) to lookup user information. In this example, the user did not have to touch this file by hand. The GUI authconfig-tui was run and the LDAP user information was selected. This updated the nsswitch.conf file to indicate that LDAP is to be used for user information on that host. The pertinent changes to include LDAP were to the following nsswitch subsystems:
- passwod (user,shell,UID,GIDs)
- group (group-name<->GID)