Labeled NFS/Demo/Manual/Post-Install

From SELinux Wiki

Revision as of 14:16, 11 December 2008 by CraigGrube (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Following are additional post-install configuration steps that can be performed to better integrate the clients and server in a way that more closely resembles what might be seen in an enterprise environment.

Contents

[edit] Automounting User Home Directories

Autofs/Autmount is used to automatically mounts user's home directories.

   # yum install autofs

[edit] Edit /etc/auto.master

Add the following to the /etc/auto.master file:

/home /etc/auto.home

[edit] Edit /etc/auto.home

The file /etc/auto.home should have the following line in it.

  • An administrator may want to adjust some of the NFS parameters
*    -fstype=nfs4,sec=krb5,security_label,soft,intr,rsize=8192,wsize=8192,nosuid,tcp nfs.example.com:/home:&

[edit] Enable Kerberos Authentication and LDAP User Information on the Client

At the command line, run the authentication configuration tools on the client machine authconfig-tui:

client# authconfig-tui

It presents a number of terminal selection boxes. The first one is Authentication Configuration

Under Authentication:

  • Select Use Kerberos
    • This enables logins via Kerberos.
    • this can change a number of files, the PAM configuration is the main one.
  • Leave selected or select Use Shadow Passwords and Local authorization is sufficient
    • This allows local passwords to work as well.

Under User Information:

  • Select Use LDAP

Select Next

It now presents LDAP Settings. This should have the correct configuration information from previously configuring the LDAP server. But if it is blank or just to double check:

  • Use TLS should be selected.
  • Server: should be the LDAP server
    • e.g. ldap://sefos.example.com
  • Base DN: should be the base DN
    • e.g. dc=example,dc=com

Select Next

It now presents Kerberos Settings. Again, this should have the correct configuration information from previously configuring the Kerberos server. But if it is blank or just to double check:

  • Realm: should be the local realm
    • e.g. EXAMPLE.COM
  • KDC: should be the name of the Kerberos KDC
    • e.g. sefos.example.com (the port number, 88, may be appended)
  • Admin Server: should be the Kerberos Admin server
    • e.g. sefos.example.com (the same as the KDC in this example; the port number, 749, may be appended)
  • leave unselected Use DNS to resolve hosts to realms
  • leave unselected Use DNS to locate KDCs for realms


[edit] Adding Users

After following the previous instructions, the network's Kerberos, NFS, and LDAP services are ready to be used by a client machine. But the user information necessary to make everything work has not been added yet. For most enterprises, the existing user provisioning system will need to be modified in some fashion to perform the following steps when adding a user. With the exception of some of the LDAP loading, what follows is mostly manual instructions for adding the user information for a single user. In a production system, these steps should be scripted and integrated into an enterprise's provisioning system to simplify user changes.

[edit] Kerberos Principles

The first step is to create a Kerberos principal for a new user. For this example, newuser is used.

  • This command needs to be done by a principal that has write access to the Kerberos data.
root@sefos/etc kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM:
kadmin:  addprinc newuser
NOTICE: no policy specified for newuser@EXAMPLE.COM; assigning "default"
Enter password for principal "newuser@EXAMPLE.COM":
Re-enter password for principal "newuser@EXAMPLE.COM":
Principal "newuser@EXAMPLE.COM" created.
kadmin:  listprincs
K/M@EXAMPLE.COM
host/seclient.example.com@EXAMPLE.COM
host/sefos.example.com@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin/sefos.example.com@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
ldap/sefos.example.com@EXAMPLE.COM
newuser@EXAMPLE.COM
nfs/seclient.example.com@EXAMPLE.COM
nfs/seclient.example.com@EXAMPLE.COM
nfs/sefos.example.com@EXAMPLE.COM
root/admin@EXAMPLE.COM

Note: The listprincs results have been truncated here. 'listprincs' was just run to check that 'newuser' was created.

[edit] Creating Home Directories

NFS home directories can be handled in a number of different ways. This is just one way to do it. In this example, the NFS server's /mnt/export/home directory is bound to the local /home directory.

From the command line or placed in /etc/rc.d/rc.local for automatic binding at boot time:

[root@sefos \]# mount -n --bind /home /mnt/export/home

Each new user is then created on the NFS server. An explicit Group ID number (GID) and User ID number (UID) can also be given with the commands below, although it is not necessary. Unique numbers are generated automatically.

[root@sefos /] groupadd newuser
[root@sefos /] useradd -m -s /sbin/nologin -g newuser newuser
  • The GUI 'system-config-users' can also be used.
  • By default on F9, a unique group with the same name as the user (e.g. a 'newuser' group) is created when a user is created.
  • The UID and GID values that are set in LDAP later do not have to match the values generated here. The NFS files will be mapped between the two.
  • '-m' creates a new /home/ directory for the user and copies the skeleton files (/etc/skel/) into it.
    • The files created within a new user's home account can be set up to be what is administratively required and a different skeleton directory can be specified as well.
    • Since the home/ directory is bound to /mnt/export/home/, the NFS user's home/ directory and default skeleton files are automatically created.

[edit] LDAP User Information

The next step is to add user information into the LDAP directory service. For most Enterprise systems this likely will be scripted. The OpenLDAP package has a number of schemas in place to handle user information that this example will build from. The package migrationtools is a good place to get started.

[edit] Migrationtools

Migrationtools is a set of Perl scripts that convert a number of different standard network information databases into a format that can be added into a LDAP directory service.

  [root@sefos /] yum install migrationtools
  • Installs scripts into /usr/share/migrationtools

It should be noted that migrationtools has scripts for transferring everything at once, migrate_all_online.pl and migrate_all_offline.pl. Since this example is just interested in the user information (user, group, home directory, etc...), these scripts are not used. To just grab the pertinent user information and place it into the LDAP directory service, the scripts /usr/share/migrationtools/migrate_passwd.pl and /usr/share/migrationtools/migrate_group.pl are run to generate user information for the LDAP directory. 'migrate_password.pl' will pull user information out of a unix /etc/passwd file and put it into a LDAP ldif formatted output file. 'migrate_group.pl' will pull group information out of a unix /etc/group file and put it in a LDAP ldif formatted output file. This assumes there is an existing unix system with user's and group's that should be in the LDAP directory service.

To make life easier, there is a configuration script, /usr/share/migrationtools/migrate_common.ph that holds two pieces of information that should change. Change the default domain and base in this file to the desired values for the current domain.

# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "example.com";

# Default base
$DEFAULT_BASE = "dc=example,dc=com";

[edit] Group information

Next create the list of groups to migrate to LDAP.

[root@sefos ~] /usr/share/migrationtools/migrate_group.pl  /etc/group  group.ldif

The file group.ldif holds a list of ldif formatted group definitions that look similar to:

dn: cn=newuser,ou=Group,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: newuser
userPassword: {crypt}x
gidNumber: 501

For the example, this individual record is pulled out and placed in a separate file, 'newusergroup.ldif'.

  • The userPassword value is not needed here, so it is excised.
  • The gidNumber should be unique within the network user information.
    • For this example, this means unique within the LDAP directory server.
    • The GID is changed to be a higher value so that it is less likely to conflict with F9 defaults which use GIDs starting at 0 for system accounts and GIDs starting at 500 for user accounts.


The new file 'newusergroup.ldif' now looks like:

dn: cn=newuser,ou=Group,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: newuser
gidNumber: 902

Add it to the LDAP directory services on the server:

# chcon system_u:object_r:slapd_db_t:s0 /tmp/newusergroup.ldif
# ldapadd -ZZ -f newusergroup.ldif

[edit] User Information

Next the ldif file for the user information is created and added to the LDAP directory. Pull out user info from the /etc/passwd file.

[root@sefos~] /usr/share/migrationtools/migrate_passwd.pl /etc/passwd users.ldif

The file users.ldif holds ldif formatted information that is similar to:

dn: uid=newuser,ou=People,dc=example,dc=com
uid: newuser
cn: newuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}!!
shadowLastChange: 14071
shadowMax: 99999
shadowWarning: 7
loginShell: /sbin/nologin
uidNumber: 502
gidNumber: 502
homeDirectory: /home/newuser

This as also parsed down to the values we need for this example and placed within a separate file, 'newuserinfo.ldif'.

  • 'objectClass: shadowAccount', userPassword, shadowLastChange, shadowMax, and shadowWarning are all excised as they are not pertinent to the network user information in this example.
  • loginShell is changed to a useful login shell.
  • The group ID (GID) is changed to match the newuser group that was just created.
  • The user ID (UID) is changed to a value unique within the network's user information (i.e. in this case, unique within the LDAP directory).
    • The UID is set above the F9 default 500+ UID values to try to avoid conflicting numbers.
dn: uid=newuser,ou=People,dc=example,dc=com
uid: newuser
cn: newuser
objectClass: account
objectClass: posixAccount
objectClass: top
loginShell: /bin/tcsh
uidNumber: 902
gidNumber: 902
homeDirectory: /home/newuser

Add the new information to the LDAP directory services. On the server:

# chcon system_u:object_r:slapd_db_t:s0 /tmp/newuserinfo.ldif
# ldapadd -ZZ -f newusergroup.ldif

[edit] Testing

Everything should be set properly to allowing logging in. To test, simply go to the GDM login display on the client machine and login using the 'newuser' user name and the the password created for that user's Kerberos credentials.

Personal tools