Policy-based Linux Desktop Environment
Novell Cool Solutions: Feature
By Adrian Malaguti
Digg This -
Posted: 10 Sep 2004
- KDE Desktop Profiles
- Document Objectives
- Lab Software
- How it works
- How to improve it
- eDirectory and LDAP Authentication
- Client Configuration
- NFS Server
Provide a guide about how to apply restrictive policies to a Linux desktop, manage Linux users from eDirectory, authenticate thru LDAP and store user's data and profiles in a remote NFS Server for centralized management.
Today's customers need to set up a centralized and restricted desktop environment for their users to improve user productivity and reduce help desk calls.
Desktop environments are a combination of local operating system features (Win9x, Win2k, XP local policies) and a desktop management tool like ZENworks for Desktops, which allows, among other things, assigning a profile or desktop policy based on user identity and group membership.
Now, the question is, how can we achieve a similar environment in a Linux Desktop environment? Although tools are being developed to achieve these tasks, I will try to show how you can use a KDE application, Kiosk Admin Tool.
From the server side, we use SUSE Linux Enterprise Server, configured as NFS Server and running eDirectory 8.7.3.
From the client side, we use Novell Linux Desktop (NLD, beta version of July 27, 2004), with the KDE environment which comes included with Novell Linux Desktop.
The Kiosk Admin Tool allows you to define desktop policies for KDE, environment restrictions and menu definitions. Each policy can be applied per user or per group.
In the basic setup, all the files Kiosktool creates are stored locally on the machine you are working with. Later I'll try to explain how to have all these policies centralized using NFS Server to store these files and LDAP to retrieve user information such as group membership.
Kiosktool has a GUI which allows to create and configure policies and make the user/group assignments. (See Figure 1 and Figure 2)
It's divided in the following sections, which allows you to setup or lock down/disable functionalities.
- Desktop Icons
- Desktop Background
- Screen Saver
- KDE Menu
- Network Proxy
- Menu Actions
Creation of a KIOSK policy.
Different components to setup
Lock down check boxes and Setup button
Clicking on the setup button starts a testing environment where you can apply your setup and save it, without modifying your current environment.
When finished with your profile setup, you have to assign it to your users or groups clicking on the Manage Users button.
Policies configuration, by default, is stored in /var/lib/kde-profiles; this content can be shared from an NFS Server.
User/Group assignments are stored in the file: /etc/kde-user-profiles; this file should be managed centrally, and distributed to each client machine. One possibility is to have a script doing this job, copy from an NFS server to local /etc, and have it run by cron.
The next images show how to assign a CallCenter profile to a CallCenter group. User jdoe is member of the CallCenter group (it's not his primary group). After the profile assignment to CallCenter group, executing kiosktool-kdedirs for user jdoe shows the path to CallCenter profile.
kiosktool-kdedirs shows which profile is used for user jdoe, member of CallCenter group. This info is obtained from /etc/kde-user-profile
Profile assignments are stored in /etc/kde-user-profile.
Logged in as user jdoe, profile CallCenter was applied (Window Decorations, Colors and Run Command removed from menu).
/home and /var/lib/kde-profiles are mounted from a NFS Server.
Authentication is done using LDAP, jdoe and groups are defined in eDirectory.
If the KDE version is lower than 3.2.3, a special variable, KDEDIRS, must be used to indicate the directory where policies are stored for the logged in user (by default /var/lib/kde-profiles).
In such a case, the line "export KDEDIRS=$(kiosktool-kdedirs)" should be added to the script file /opt/kde3/bin/startkde.
This is true in general, but it does not apply to the KDE 3.2.1 from SUSE9.1/SLES9/NLD, since SUSE backported the profile stuff to it.
Anyway, I added the export KDEDIRS line to /opt/kde3/bin/startkde.
Well, now we have a policy-based desktop, so it's time to go further and try to set up multiple machines with this environment. The best way to do this is to have some info centralized, including: users and groups, kiosk profiles files, and a kde-user-profile file:
- A central repository of users/groups --> eDirectory and LDAP Authentication.
- Shared directories for policies and profiles --> NFS Server with /home and /var/lib/kde-profiles exported.
- Common file kde-user-profiles in all clients --> Script run by cron to copy file kde-user-profiles periodically from NFS Server to client /etc/.
A Linux machine is capable of user authentication using LDAP, we can use eDirectory to store our Linux users and group information and pass this info to Linux clients, for this lab I was working on a SUSE Linux Enterprise Server box in which I installed eDirectory 8.7.3.
Once we have eDirectory running, we need to extend the schema to get new classes and attributes for Linux users.
To extend the schema we can use the tool ndssch; the file provided to extend the schema for Linux users is located in /usr/lib/nds-schema/rfc2307-usergroup.sch.
The next image shows how to use ndssch to extend the schema with rfc2307-usergroup.sch.
After the schema extension we will have three new classes: posixAccount, shadow Account and posixGroup.
For every user we want to provide authentication from a Linux client, we need to extend this user object with the auxiliary class posixAccount. Same for groups, for example, if primary group of user Jdoe is "linuxuser", we will create a group called "linuxuser" and extend it with auxiliary class posixGroup.
The next group of images show the full process for creation of a user and a group for Linux authentication. It's comprised of the following steps:
- Creation of an eDir group called linuxuser
- Extension of this group with auxiliary class posixGroup, gid number=5000
- Creation of an eDir user called jdoe
- Extension of this user with auxiliary class posixAccount, uid=3000, GID=5000 (linuxuser)
- Add loginShell attribute to jdoe properties, complete with "/bin/bash"
- Creation of another eDir group called CallCenter
- Extension of group CallCenter with auxiliary class posixGroup, gid number=5100
- Add jdoe as member of CallCenter group
- Configure clients for LDAP Authentication (see Client Configuration)
- Test jdoe login, TTY and X, verify home directory creation, file/dir ownership
Extending group linuxuser with aux. class posixGroup
Defining posixGroup information for group linuxuser
New user jdoe
Extending user jdoe with aux. class posixAccount
Defining posixAccount information for user jdoe
Adding loginShell attribute to user jdoe
Setting /bin/bash as login shell for user jdoe
Defining new group CallCenter as posixGroup
Adding user jdoe as member of CallCenter
jdoe login to NLD_Client, first login, home directory is created automatically.
File/Dir ownership is granted to jdoe.linuxuser.
ID information for jdoe shows uid number, primary & secondary group assignment.
Graphical login to Novell Linux Desktop (X)
Home Directory was created transparently.
Configure Novell Linux Desktop (NLD) to authenticate using LDAP. The easiest way is using YaST->Network Services->LDAP Client.
Check your LDAP Server configuration, pay attention to TLS/SSL, LDAP proxy user and ports in use, and setup your client (edit /etc/ldap.conf) accordingly to the LDAP server setup.
This is a client /etc/ldap.conf configured for TLS support.
Add an entry in /etc/pam.d/login for session module pam_mkhomedir.so, this module enable automatic home dir creation during user login:
session optional pam_mkhomedir skel=/etc/skel umask=0022
For XDM (Graphical login) sessions edit /etc/pam.d/xdm.
The next image shows what happens when a new user logins on a client machine configured with LDAP Authentication and pam_mkhomedir module. The user was created with uid=3000, gid=5000. He's member of linuxuser group, and this group was created previously in eDirectory and extended as a posixGroup object. The image also shows the ownership of files created by this user. This user does not exist in /etc/passwd nor /etc/shadow; same for linuxusergroup and /etc/group.
It's a very good idea to have /home located centrally in each client, exporting it from an NFS server with all user home directories.
We will use SUSE Linux Enterprise Server (SLES) 8 as NFS server to provide shared file system across the network. It has to be configured as a LDAP client to share the same user identities as other Linux clients. We can configure LDAP authentication using YaST; but after finishing setup, the ldap.conf provided by YaST is not so useful for our configuration because it has incomplete configuration for NDS authentication. The best way is to use the ldap.conf from one of our Novell Linux Desktop clients (configured previously) and copy it to the server into /etc/openldap/ldap.conf.
We need two NFS mount points, first one for /home (store user's data), second one for /var/lib/kde-profiles (store Kiosktool profiles).
Server side nfs file /etc/exports
Client side nfs mount points
no_root_squash is needed to allow the creation of home directories in the server from remote clients during user login.
edit /etc/fstab, add the following line (it's just one alternative...)
server_address:/home /home nfs defaults 0 2
server_address:/DesktopConfig/kde-profiles /var/lib/kde-profiles nfs defaults 0 3
To enable these services to be run on the proper runlevel.
server_address:/DesktopConfig/kde-profiles /var/lib/kde-profiles nfs defaults 0 3
The next images show what happens during a user login without a home directory and how it is created in the NFS Server.
For this example we will use the user named "bcornel"
From the server, logged as root, there is no home directory for "bcornel"
Logged as root in the client machine, we have /home mounted with NFS from the server.
User bcornel logins to client machine and his home directory is created.
Logged as root in the server, we have the recently-created home directory of user bcornel.
bcornel's home directory will be available on whatever machine bcornel uses for login, if the machine has been set up with LDAP authentication and /home mounted from the NFS server.
We have successfully accomplished:
- User authentication to eDirectory using LDAP based mechanism.
- Provisioning of linux user attribute, such as uid, gid, additional group memberships, home, login shell, etc.
- Store of linux users's home directories, $HOME, into a central server using NFS.
- Store of kiosktool profiles into a central server using NFS.
With all these things up and running, we can start to administer our Linux users from eDirectory, and we don't need to keep updating each client's local files (/etc/passwd, /etc/group, /etc/shadow). Also we can provide a very well-restricted desktop environment, based on user or group policies, allowing users to be more productive and also reducing calls to the help desk.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com