http://selinuxproject.org/w/?title=Labeled_NFS/Demo/Manual/Post-Install&limit=100&action=history&feed=atomLabeled NFS/Demo/Manual/Post-Install - Revision history2024-03-29T07:33:31ZRevision history for this page on the wikiMediaWiki 1.23.13http://selinuxproject.org/w/?title=Labeled_NFS/Demo/Manual/Post-Install&diff=345&oldid=prevCraigGrube: New page: 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 ent...2008-12-11T14:16:13Z<p>New page: 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 ent...</p>
<p><b>New page</b></p><div>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.<br />
<br />
= Automounting User Home Directories =<br />
<br />
Autofs/Autmount is used to automatically mounts user's home directories.<br />
<pre><br />
# yum install autofs<br />
</pre><br />
<br />
== Edit /etc/auto.master ==<br />
<br />
Add the following to the /etc/auto.master file:<br />
<br />
<pre><br />
/home /etc/auto.home<br />
</pre><br />
<br />
== Edit /etc/auto.home ==<br />
<br />
The file /etc/auto.home should have the following line in it.<br />
* An administrator may want to adjust some of the NFS parameters<br />
<pre><br />
* -fstype=nfs4,sec=krb5,security_label,soft,intr,rsize=8192,wsize=8192,nosuid,tcp nfs.example.com:/home:&<br />
</pre><br />
<br />
= Enable Kerberos Authentication and LDAP User Information on the Client =<br />
<br />
At the command line, run the authentication configuration tools on<br />
the client machine '''authconfig-tui''':<br />
<br />
<pre><br />
client# authconfig-tui<br />
</pre><br />
<br />
It presents a number of terminal selection boxes. The first one is<br />
'''Authentication Configuration'''<br />
<br />
Under '''Authentication''':<br />
* Select '''Use Kerberos'''<br />
** This enables logins via Kerberos.<br />
** this can change a number of files, the PAM configuration is the main one.<br />
* Leave selected or select '''Use Shadow Passwords''' and '''Local authorization is sufficient'''<br />
** This allows local passwords to work as well.<br />
<br />
Under '''User Information''':<br />
* Select '''Use LDAP'''<br />
<br />
Select '''Next'''<br />
<br />
It now presents '''LDAP Settings'''. This should have the correct<br />
configuration information from previously configuring the LDAP<br />
server. But if it is blank or just to double check:<br />
* '''Use TLS''' should be selected.<br />
* '''Server:''' should be the LDAP server<br />
** e.g. ldap://sefos.example.com<br />
* '''Base DN:''' should be the base DN<br />
** e.g. dc=example,dc=com<br />
<br />
Select '''Next'''<br />
<br />
It now presents '''Kerberos Settings'''. Again, this should have<br />
the correct configuration information from previously configuring<br />
the Kerberos server. But if it is blank or just to double check:<br />
* '''Realm:''' should be the local realm<br />
** e.g. EXAMPLE.COM<br />
* '''KDC:''' should be the name of the Kerberos KDC<br />
** e.g. sefos.example.com (the port number, 88, may be appended)<br />
* '''Admin Server:''' should be the Kerberos Admin server<br />
** e.g. sefos.example.com (the same as the KDC in this example; the port number, 749, may be appended)<br />
* leave unselected '''Use DNS to resolve hosts to realms'''<br />
* leave unselected '''Use DNS to locate KDCs for realms'''<br />
<br />
<br />
= Adding Users =<br />
<br />
After following the previous instructions, the network's Kerberos,<br />
NFS, and LDAP services are ready to be used by a client machine.<br />
But the user information necessary to make everything work has not<br />
been added yet. For most enterprises, the existing user<br />
provisioning system will need to be modified in some fashion to<br />
perform the following steps when adding a user. With the exception<br />
of some of the LDAP loading, what follows is mostly manual<br />
instructions for adding the user information for a single user. In<br />
a production system, these steps should be scripted and integrated<br />
into an enterprise's provisioning system to simplify user changes.<br />
<br />
== Kerberos Principles ==<br />
<br />
The first step is to create a Kerberos principal for a new user. For this example, '''newuser''' is used. <br />
* This command needs to be done by a principal that has write access to the Kerberos data.<br />
<br />
<pre><br />
root@sefos/etc kadmin<br />
Authenticating as principal root/admin@EXAMPLE.COM with password.<br />
Password for root/admin@EXAMPLE.COM:<br />
kadmin: addprinc newuser<br />
NOTICE: no policy specified for newuser@EXAMPLE.COM; assigning "default"<br />
Enter password for principal "newuser@EXAMPLE.COM":<br />
Re-enter password for principal "newuser@EXAMPLE.COM":<br />
Principal "newuser@EXAMPLE.COM" created.<br />
kadmin: listprincs<br />
K/M@EXAMPLE.COM<br />
host/seclient.example.com@EXAMPLE.COM<br />
host/sefos.example.com@EXAMPLE.COM<br />
kadmin/admin@EXAMPLE.COM<br />
kadmin/changepw@EXAMPLE.COM<br />
kadmin/history@EXAMPLE.COM<br />
kadmin/sefos.example.com@EXAMPLE.COM<br />
krbtgt/EXAMPLE.COM@EXAMPLE.COM<br />
ldap/sefos.example.com@EXAMPLE.COM<br />
newuser@EXAMPLE.COM<br />
nfs/seclient.example.com@EXAMPLE.COM<br />
nfs/seclient.example.com@EXAMPLE.COM<br />
nfs/sefos.example.com@EXAMPLE.COM<br />
root/admin@EXAMPLE.COM<br />
</pre><br />
<br />
'''Note''': The listprincs results have been truncated here.<br />
'listprincs' was just run to check that 'newuser' was created.<br />
<br />
== Creating Home Directories ==<br />
<br />
NFS home directories can be handled in a number of different ways.<br />
This is just one way to do it. In this example, the NFS server's<br />
/mnt/export/home directory is bound to the local /home directory.<br />
<br />
From the command line or placed in /etc/rc.d/rc.local for automatic<br />
binding at boot time:<br />
<pre><br />
[root@sefos \]# mount -n --bind /home /mnt/export/home<br />
</pre><br />
<br />
Each new user is then created on the NFS server. An explicit Group<br />
ID number (GID) and User ID number (UID) can also be given with the<br />
commands below, although it is not necessary. Unique numbers are<br />
generated automatically.<br />
<br />
<pre><br />
[root@sefos /] groupadd newuser<br />
[root@sefos /] useradd -m -s /sbin/nologin -g newuser newuser<br />
</pre><br />
<br />
* The GUI 'system-config-users' can also be used.<br />
* 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.<br />
* 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.<br />
* '-m' creates a new /home/ directory for the user and copies the skeleton files (/etc/skel/) into it.<br />
** 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.<br />
** Since the home/ directory is bound to /mnt/export/home/, the NFS user's home/ directory and default skeleton files are automatically created.<br />
<br />
== LDAP User Information ==<br />
<br />
The next step is to add user information into the LDAP directory<br />
service. For most Enterprise systems this likely will be scripted.<br />
The OpenLDAP package has a number of schemas in place to handle user<br />
information that this example will build from. The package<br />
migrationtools is a good place to get started.<br />
<br />
=== Migrationtools ===<br />
<br />
Migrationtools is a set of '''Perl''' scripts that convert a number<br />
of different standard network information databases into a format<br />
that can be added into a LDAP directory service.<br />
<pre><br />
[root@sefos /] yum install migrationtools<br />
</pre><br />
* Installs scripts into /usr/share/migrationtools<br />
<br />
It should be noted that migrationtools has scripts for transferring<br />
everything at once, migrate_all_online.pl and<br />
migrate_all_offline.pl. Since this example is just interested in<br />
the user information (user, group, home directory, etc...), these<br />
scripts are not used. To just grab the pertinent user information<br />
and place it into the LDAP directory service, the scripts<br />
/usr/share/migrationtools/migrate_passwd.pl and<br />
/usr/share/migrationtools/migrate_group.pl are run to generate user<br />
information for the LDAP directory. 'migrate_password.pl' will pull<br />
user information out of a unix /etc/passwd file and put it into a<br />
LDAP ldif formatted output file. 'migrate_group.pl' will pull group<br />
information out of a unix /etc/group file and put it in a LDAP ldif<br />
formatted output file. This assumes there is an existing unix<br />
system with user's and group's that should be in the LDAP directory<br />
service.<br />
<br />
To make life easier, there is a configuration script,<br />
/usr/share/migrationtools/migrate_common.ph that holds two pieces of<br />
information that should change. Change the default domain and base<br />
in this file to the desired values for the current domain.<br />
<br />
<pre><br />
# Default DNS domain<br />
$DEFAULT_MAIL_DOMAIN = "example.com";<br />
<br />
# Default base<br />
$DEFAULT_BASE = "dc=example,dc=com";<br />
</pre><br />
<br />
=== Group information ===<br />
<br />
Next create the list of groups to migrate to LDAP.<br />
<br />
<pre><br />
[root@sefos ~] /usr/share/migrationtools/migrate_group.pl /etc/group group.ldif<br />
</pre><br />
<br />
The file group.ldif holds a list of ldif formatted group<br />
definitions that look similar to:<br />
<br />
<pre><br />
dn: cn=newuser,ou=Group,dc=example,dc=com<br />
objectClass: posixGroup<br />
objectClass: top<br />
cn: newuser<br />
userPassword: {crypt}x<br />
gidNumber: 501<br />
</pre><br />
<br />
For the example, this individual record is pulled out and placed in<br />
a separate file, 'newusergroup.ldif'. <br />
* The '''userPassword''' value is not needed here, so it is excised.<br />
* The '''gidNumber''' should be unique within the network user information.<br />
** For this example, this means unique within the LDAP directory server.<br />
** 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.<br />
<br />
<br />
The new file 'newusergroup.ldif' now looks like:<br />
<br />
<pre><br />
dn: cn=newuser,ou=Group,dc=example,dc=com<br />
objectClass: posixGroup<br />
objectClass: top<br />
cn: newuser<br />
gidNumber: 902<br />
</pre><br />
<br />
Add it to the LDAP directory services on the server:<br />
<br />
<pre><br />
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newusergroup.ldif<br />
# ldapadd -ZZ -f newusergroup.ldif<br />
</pre><br />
<br />
=== User Information ===<br />
<br />
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.<br />
<br />
<pre><br />
[root@sefos~] /usr/share/migrationtools/migrate_passwd.pl /etc/passwd users.ldif<br />
</pre><br />
<br />
The file users.ldif holds ldif formatted information that is similar to:<br />
<br />
<pre><br />
dn: uid=newuser,ou=People,dc=example,dc=com<br />
uid: newuser<br />
cn: newuser<br />
objectClass: account<br />
objectClass: posixAccount<br />
objectClass: top<br />
objectClass: shadowAccount<br />
userPassword: {crypt}!!<br />
shadowLastChange: 14071<br />
shadowMax: 99999<br />
shadowWarning: 7<br />
loginShell: /sbin/nologin<br />
uidNumber: 502<br />
gidNumber: 502<br />
homeDirectory: /home/newuser<br />
</pre><br />
<br />
This as also parsed down to the values we need for this example and placed within a separate file, 'newuserinfo.ldif'.<br />
* 'objectClass: shadowAccount', userPassword, shadowLastChange, shadowMax, and shadowWarning are all excised as they are not pertinent to the network user information in this example.<br />
* loginShell is changed to a useful login shell.<br />
* The group ID (GID) is changed to match the newuser group that was just created.<br />
* 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).<br />
** The UID is set above the F9 default 500+ UID values to try to avoid conflicting numbers.<br />
<br />
<pre><br />
dn: uid=newuser,ou=People,dc=example,dc=com<br />
uid: newuser<br />
cn: newuser<br />
objectClass: account<br />
objectClass: posixAccount<br />
objectClass: top<br />
loginShell: /bin/tcsh<br />
uidNumber: 902<br />
gidNumber: 902<br />
homeDirectory: /home/newuser<br />
</pre><br />
<br />
Add the new information to the LDAP directory services. On the server:<br />
<br />
<pre><br />
# chcon system_u:object_r:slapd_db_t:s0 /tmp/newuserinfo.ldif<br />
# ldapadd -ZZ -f newusergroup.ldif<br />
</pre><br />
<br />
= Testing =<br />
<br />
Everything should be set properly to allowing logging in. To test,<br />
simply go to the GDM login display on the client machine and login<br />
using the 'newuser' user name and the the password created for that<br />
user's Kerberos credentials.</div>CraigGrube