Non-Root eDirectory Management
by Gary Childers
- The Challenge
- Separation of Administration
- Meeting Them Halfway
- Using sudo
- Editing the List of sudo Commands
- Hiding the sudo Mechanism
- Centralizing the Alias Specifications
- File and Directory Rights
- Custom Scripts
- Going Forward
Some organizations face a bit of a challenge when they are considering making the move to newer technologies. It is easy to merely assume that the “tech guys” (and gals) already know everything about every conceivable technology, but then reality has a way of intruding upon our assumptions.
One case in point: an organization may have utilized Novell’s excellent NetWare operating system for many years, leveraging its superior file and print services. The organization has many highly-skilled NetWare administrators who know not only how to manage the NetWare operating system, but more importantly, they know how to manage eDirectory, the heart and core of the organization’s computer identity and security system.
In the past, everyone was accustomed to thinking of “Novell” and “NetWare” almost as synonymous – the software company and its flagship product. But this is a brave new century, and we need to recognize that Novell is also a premier provider of the Linux operating system, with its SUSE Enterprise Linux Server, and SUSE Linux Enterprise Desktop; and that eDirectory can also run on multiple platforms, including Linux.
The challenge comes into play when organizations want to make the jump from the traditional to the new – they wish to migrate network services and applications from a NetWare operating system platform to a Linux (and hopefully, SUSE Linux) platform. Do they have to now completely re-train all of their IT staff for the new platform?
Most larger organizations do not have a single-vendor IT environment, but rather they already have implementations of multiple platforms across the organization – Windows, NetWare, and Linux/Unix. In such heterogeneous environments, they don’t expect to have one single “techhie genius” to administer all platforms, but typically have different IT teams each responsible for their area of expertise: the Windows admins, the NetWare admins, and the Linux admins.
In addition, larger organizations may further separate the responsibilities, so that one admin group takes care of the operating system platforms, and another group manages only the applications which operate on those platforms, such as: email, database, and directory services.
Such is often the case with Linux servers in the IT environment. The “Linux gurus” are responsible for the management of the server OS, and they prefer to give only limited access to those responsible for the applications which reside on the Linux server.
However, many organizations wish to deploy eDirectory, Novell’s world-class directory services, on the proven, stable Linux platform. They may be implementing Novell’s Identity Management, or an LDAP-based application, or other software which consumes the directory information stored in eDirectory.
In such a scenario, we might have a Linux platform admin group, which manages the server operating systems, and then an eDirectory group which manages the directory services. The eDirectory admins may not be experts in Linux (at least, not yet), so the Linux admins may understandably be concerned about giving them “cart blanche” access as the root user to the Linux servers. There are just too many opportunities to break something.
The problem arises because the default installation of eDirectory on the Linux platform really works best if you are installing as the root user. That’s simply the way it was designed. This comes as no surprise to those who come from a NetWare background, because installing the NetWare server OS and the eDirectory application were basically one and the same operation. But this comes as some consternation to the Linux admins, since from their viewpoint, they are responsible for the server OS platform, and they want to give you only enough access to be able to manage your application.
An eDirectory administrator may have complete access within the eDirectory tree, and yet have zero access to the underlying operating system. With NetWare this was never an issue: if you had access to the console, then you were in complete control of the operating system. Linux adds another layer of security, so that console access is restricted according to the individual (Linux) user account which is used to access the server console.
It is certainly possible to install eDirectory on Linux as a non-root user (see Installing eDirectory 8.8 SP2 as a Non-Root User), but this comes with some constraints, as well. Significantly, a non-root installation of eDirectory on Linux cannot use the default TCP port 524 for NCP communications, since Linux reserves TCP ports below 1024 for root access only. This can make it very difficult to integrate a non-root eDirectory implementation into the existing network infrastructure.
An alternate solution to this dilemma is to go ahead and install eDirectory onto the Linux server as the root user (or equivalent), and then to do the day-to-day management of the eDirectory server using a less privileged account. By default, this is not really feasible, but with some extra configuration, it can be accomplished quite well.
In secure environments, the Linux admins typically won’t give you total root access (as in, “here’s the root password, so go and have fun”), but they often may give the eDirectory installer what is called “sudo” access. This is easily accomplished by configuring the ‘sudoers’ file on the Linux server.
To elevate a normal Linux user to root privileges, we normally would execute “su” to open a new console shell with the (default) root ID, and then provide the root password. This would require the Linux admin to give us the root password, or to be physically there to type it in for us. But this type of access can also be given, let’s say, for the purpose of installing eDirectory, without having to do either. We could use “sudo”.
To configure the Linux server to elevate a user (or group of users) to root access, the Linux admin would only have to configure the sudoers file (/etc/sudoers) to include the following:
# Host Alias Specification Host_Alias THISHOST=sles-idm1 # User Alias Specification User_Alias EDIRADMINS=%ediradmins # Command Alias Specification Cmnd_Alias SUMINUS=/bin/su - # Runas alias specification Runas_Alias ASROOT=root # Permissions EDIRADMINS THISHOST = (ASROOT) SUMINUS
As every Linux admin knows, this file is not to be edited directly, but ‘visudo’ is used to edit the file, which performs some basic logic to more safely edit the file, and to guard against errors. The sections for Host_Alias, User_Alias, Cmnd_Alias and Permissions typically already exist by default, so the Linux admin needs only to enter the data under each appropriate section. This example assumes that there is an existing Linux group named “ediradmins” (the name can be whatever you choose), whose members require the elevated permissions.
Then to gain the elevated access, the user (a member of ediradmins) only has to type:
sudo su -
The user will be prompted for a password, but this time he enters his own password, not the actual root password. The sudo configuration allows him to “su” as root, without having to have the actual root password.
This would allow the non-root user to install eDirectory as root without any problems. This is fine for the installation, but as a long-term solution for the day-to-day management of the server, this approach is severely lacking, from a Linux security standpoint. You almost might as well give all the ediradmins users the root password, and let them simply “su” as root every time they login.
The problem comes from the fact that once eDirectory is installed as the root user, all of the eDirectory processes now run as root, and root has all of the file ownerships needed for the services to run. This (by design) makes it nearly impossible for the unprivileged user to manage the eDirectory application on the server.
Without elevated privileges, the normal user cannot run all the various eDirectory utilities from the Linux server console. For example, let’s run “ndsstat” and “ndsrepair” commands as both non-root and as root users:
joeuser@sles-idm1:~> ndsstat No instances of eDirectory Server are configured. joeuser@sles-idm1:~> ndsrepair -T No instances of eDirectory Server are configured.
But the same commands, run as root:
sles-idm1:~ # ndsstat  Instance at /etc/opt/novell/eDirectory/conf/nds.conf: sles-idm1.O=MAIN.EDIR1 Tree Name: EDIR1 Server Name: .CN=sles-idm1.O=MAIN.T=EDIR1. Binary Version: 20216.83 Root Most Entry Depth: 0 Product Version: eDirectory for Linux v8.8 SP3 [DS] sles-idm1:~ # ndsrepair -T  Instance at /etc/opt/novell/eDirectory/conf/nds.conf: sles-idm1.O=MAIN.EDIR1 Repair utility for Novell eDirectory 8.8 - 8.8 SP3 v20214.25 DS Version 20216.83 Tree name: EDIR1 Server name: .sles-idm1.MAIN Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 0 bytes. Building server list Please Wait... Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log" Please Wait... Collecting time synchronization and server status Time synchronization and server status information Start: Friday, December 05, 2008 06:07:25 Local Time ---------------------------+---------+---------+-----------+--------+------- DS Replica Time Time is Time Server name Version Depth Source in sync +/- ---------------------------+---------+---------+-----------+--------+------- Processing server: .sles-idm1.MAIN .sles-idm1.MAIN 20216.83 0 Non-NetWare Yes 0 Processing server: .sles-idm2.MAIN .sles-idm2.MAIN 20216.83 0 Non-NetWare Yes 0 ---------------------------+---------+---------+-----------+--------+------- Total errors: 0 NDSRepair process completed.
Yes, we could let the eDirectory admin run “sudo su -”, to essentially become root, and then run the “ndsstat” or “ndsrepair” commands. But as well as being cumbersome (we need to always login twice), it is also risky, since it gives the eDirectory admin all root permissions on the server, and thus is usually seen as an unacceptable security practice by the Linux admins. Someone who is not experienced with Linux could potentially (and inadvertently) do some serious damage to the server operating system, when logged in with root access.
So what we need is to limit the user’s elevated privileges specifically to the commands he or she needs to run to perform the administration of eDirectory, without “giving away the farm”, by letting them login (even with sudo) regularly as the root user.
This is where sudo comes to the rescue again. The “sudo su -” may have been fine for the initial installation of eDirectory, where we needed general root access for the installation, but it is not appropriate for the day-to-day administration of the eDirectory application. For this, we need to be a bit more granular in our assignments of sudo permissions.
To assign these granular permissions to the users, the Linux admin will need to know the complete list of commands (such as “ndsstat” and “ndsrepair”) which require root access, and are needed for the users to perform their administration of the eDirectory application.
This list becomes the basis for which the Linux admin will build out the list of Cmnd_Alias entries in the sudoers file. The easiest way to determine the list of executable commands is to list the contents of the binaries directories for the eDirectory application:
sles-idm1:~ # ls –l /opt/novell/eDirectory/bin/ total 7304 -rwxr-xr-x 1 root root 714 Jul 7 00:24 dsbk -rwxr-xr-x 1 root bin 615 Jul 16 17:22 dxcmd -rwxr-xr-x 1 root root 1213 Jul 7 00:24 edirutil -rwxr-xr-x 1 root sys 750562 Jul 1 08:28 ice -rwxr-xr-x 1 root bin 3100 Jul 16 17:22 idm-install-schema -rwxr-xr-x 1 root sys 128042 Jul 9 06:53 ldapadd -rwxr-xr-x 1 root sys 53734 Jul 25 03:57 ldapconfig -rwxr-xr-x 1 root sys 84981 Jul 9 06:53 ldapdelete -rwxr-xr-x 1 root sys 128042 Jul 9 06:53 ldapmodify -rwxr-xr-x 1 root sys 84378 Jul 9 06:53 ldapmodrdn -rwxr-xr-x 1 root sys 142506 Jul 9 06:53 ldapsearch -rwxr-xr-x 1 root sys 558148 Jul 6 08:47 ldif2dib -rwxr-xr-x 1 root sys 589026 Jul 25 03:57 ndsbackup -rwxr-xr-x 1 root sys 165769 Jul 25 03:57 ndscheck -rwxr-xr-x 1 root sys 262890 Jul 25 03:57 ndsconfig -rwxr-xr-x 1 root sys 2374434 Jul 25 03:57 ndsdibupg -rwxr-xr-x 1 root bin 35394 Jul 25 03:57 ndsimonitor -rwxr-xr-x 1 root sys 97623 Jul 9 06:53 ndsindex -rwxr-xr-x 1 root sys 27766 Jul 6 08:43 ndslogin -rwxr-xr-x 1 root sys 17014 Jul 25 03:57 ndsmanage -rwxr-xr-x 1 root sys 26193 Jul 25 03:57 ndsmerge -rwxr-xr-x 1 root sys 4481 May 26 2008 ndspath -rwxr-xr-x 1 root sys 58790 Jul 22 23:07 ndsrepair -rwxr-xr-x 1 root sys 18080 Jul 10 06:52 ndssch -rwxr-xr-x 1 root bin 18988 Jul 10 08:44 ndssnmp -rwxr-xr-x 1 root sys 100567 Jul 10 08:45 ndssnmpconfig -rwxr-xr-x 1 root sys 1322716 Jul 10 08:45 ndssnmpsa -rwxr-xr-x 1 root sys 29493 Jul 25 03:57 ndsstat -rwxr-xr-x 1 root sys 42842 Jul 25 03:57 ndstrace -r-xr-xr-x 1 root root 133051 Jul 9 11:52 nmasinst -rwxr-xr-x 1 root sys 29879 Jul 25 03:57 novell-getcore -rwxr-xr-x 1 root sys 14697 Jul 25 03:57 nss -rwxr-xr-x 1 root sys 28892 Jul 25 03:57 ssscfg sles-idm1:~ # ls –l /opt/novell/eDirectory/sbin/ total 516 -rwxr-xr-x 1 root sys 56881 Jun 26 06:45 nds-uninstall -rwxr-xr-x 1 root sys 435034 Jul 25 03:57 ndsd -rwxr-xr-x 1 root sys 24002 Jul 25 03:57 nldap
This gives the Linux admin the basis for filling out the needed “Cmnd Alias” section in the sudoers file:
# Command Alias Specification # Commands required for managing eDirectory 8.8: Cmnd_Alias EDIRCMDS=/opt/novell/eDirectory/bin/dsbk, \ /opt/novell/eDirectory/bin/dxcmd, \ /opt/novell/eDirectory/bin/edirutil, \ /opt/novell/eDirectory/bin/ice, \ /opt/novell/eDirectory/bin/idm-install-schema, \ /opt/novell/eDirectory/bin/ldif2dib, \ /opt/novell/eDirectory/bin/ndsbackup, \ /opt/novell/eDirectory/bin/ndscheck, \ /opt/novell/eDirectory/bin/ndsconfig, \ /opt/novell/eDirectory/bin/ndsdibupg, \ /opt/novell/eDirectory/bin/ndsimonitor, \ /opt/novell/eDirectory/bin/ndsindex, \ /opt/novell/eDirectory/bin/ndslogin, \ /opt/novell/eDirectory/bin/ndsmanage, \ /opt/novell/eDirectory/bin/ndsmerge, \ /opt/novell/eDirectory/bin/ndspath, \ /opt/novell/eDirectory/bin/ndsrepair, \ /opt/novell/eDirectory/bin/ndssch, \ /opt/novell/eDirectory/bin/ndssnmp, \ /opt/novell/eDirectory/bin/ndssnmpconfig, \ /opt/novell/eDirectory/bin/ndssnmpsa, \ /opt/novell/eDirectory/bin/ndsstat, \ /opt/novell/eDirectory/bin/ndstrace, \ /opt/novell/eDirectory/bin/nmasinst, \ /opt/novell/eDirectory/bin/novell-getcore, \ /opt/novell/eDirectory/bin/nss, \ /opt/novell/eDirectory/bin/ssscfg, \ /opt/novell/eDirectory/sbin/ndsd, \ /opt/novell/eDirectory/sbin/nldap # Permissions # EDIRADMINS may execute all eDirectory commands EDIRADMINS THISHOST = (ASROOT) NOPASSWD: EDIRCMDS
The “Command Alias” section lists all of the required commands (comma separated) as a single ‘Cmnd_Alias’ entry, for simplicity. Note the trailing backslash (\) on each line, denoting the continuation of the previous line (omitted on the last line). Also, if there are any other commands or custom scripts which the eDirectory admins might need to run with root privileges, this would be the place to add them.
The “Permissions” (or “User Privilege Specification”) section of the sudors file essentially specifies that any user in the ediradmins Linux group can execute the list of commands identified as “EDIRCMDS”, as executing them as root. The addition of the “NOPASSWD:” parameter means that they don’t have to enter their user password again to authenticate for the sudo command (they’ve already logged in once, haven’t they?).
Now, with this in place, the non-root user (as member of the ediradmins Linux group) can execute the eDirectory commands, and obtain the results as if he were running them as root. For example:
joeuser@sles-idm1:~> sudo ndsstat  Instance at /etc/opt/novell/eDirectory/conf/nds.conf: sles-idm1.O=MAIN.EDIR1 Tree Name: EDIR1 Server Name: .CN=sles-idm1.O=MAIN.T=EDIR1. Binary Version: 20216.83 Root Most Entry Depth: 0 Product Version: eDirectory for Linux v8.8 SP3 [DS]
Often, admin users can be a little irritated by having to type “sudo” in front of each command they are executing. It’s just a few extra characters to type, but it can be annoying to always have to remember to type them. “What?? No instances of eDirectory Server are configured?? Wait – oops, I forgot to type the ‘sudo’ – never mind, it works now.”
Plus, the need to always type “sudo” is sort of a constant subtle reminder for the eDirectory admins that they are using “borrowed” privileges, and they may not particularly enjoy that concept. However, whether for convenience or placating anyone’s sensitivities, there is a way to disguise the “sudo” aspect of this solution.
Just as the sudo command gives us command aliases so that we can run specific commands with root permissions, so the Linux shell will also allow us to alias specific commands. We do this all the time. For example, “ll” is a common alias for “ls -l”, a shorthand way of performing a long file listing, which saves us a mere three keystrokes.
If we don’t like to have to type “sudo” before each of the commands listed in the sudoers file, we can specify aliases for each of the commands in the user’s .bashrc file.
The .bashrc file resides in each user’s home directory, and the leading period “.” in the file name makes the file normally hidden in the Linux command shell and the GUI. To list this and other hidden files, you would have to type “ls -la” at the Linux console, to list all files. For example:
joeuser@sles-idm1:~> ls -la total 84 drwxr-xr-x 8 joeuser users 4096 2008-12-05 05:57 . drwxr-xr-x 4 root root 4096 2008-12-05 05:57 .. -rw------- 1 joeuser users 0 2008-12-05 05:57 .bash_history -rw-r--r-- 1 joeuser users 1177 2008-12-05 05:57 .bashrc drwxr-xr-x 2 joeuser users 4096 2008-12-05 05:57 bin drwx------ 2 joeuser users 4096 2008-12-05 05:57 Documents -rw-r--r-- 1 joeuser users 208 2008-12-05 05:57 .dvipsrc -rw-r--r-- 1 joeuser users 1637 2008-12-05 05:57 .emacs -rw-r--r-- 1 joeuser users 1332 2008-12-05 05:57 .exrc drwxr-xr-x 2 joeuser users 4096 2008-12-05 05:57 .fonts -rw-r--r-- 1 joeuser users 861 2008-12-05 05:57 .inputrc -rw-r--r-- 1 joeuser users 164 2008-12-05 05:57 .kermrc drwxr-xr-x 2 joeuser users 4096 2008-12-05 05:57 .mozilla -rw-r--r-- 1 joeuser users 6043 2008-12-05 05:57 .muttrc -rw-r--r-- 1 joeuser users 925 2008-12-05 05:57 .profile drwxr-xr-x 2 joeuser users 4096 2008-12-05 05:57 public_html -rw-r--r-- 1 joeuser users 311 2008-12-05 05:57 .urlview -rw-r--r-- 1 joeuser users 7913 2008-12-05 05:57 .xcoralrc drwxr-xr-x 2 joeuser users 4096 2008-12-05 05:57 .xemacs -rw-r--r-- 1 joeuser users 119 2008-12-05 05:57 .xtalkrc
The .bashrc file is a Linux startup file which is read during user login, and controls some part of the user environment, such as command aliases. To alias all of the commands in the sudoers command list, we would simply have to list them in the .bashrc file, such as this:
# .bashrc # User specific aliases and functions alias dsbk='sudo dsbk' alias dxcmd='sudo dxcmd' alias edirutil='sudo edirutil' alias ice='sudo ice' alias idm-install-schema='sudo idm-install-schema' alias ldif2dib='sudo ldif2dib' alias ndsbackup='sudo ndsbackup' alias ndscheck='sudo ndscheck' alias ndsconfig='sudo ndsconfig' alias ndsdibupg='sudo ndsdibupg' alias ndsimonitor='sudo ndsimonitor' alias ndsindex='sudo ndsindex' alias ndslogin='sudo ndslogin' alias ndsmanage='sudo ndsmanage' alias ndsmerge='sudo ndsmerge' alias ndspath='sudo ndspath' alias ndsrepair='sudo ndsrepair' alias ndssch='sudo ndssch' alias ndssnmp='sudo ndssnmp' alias ndssnmpconfig='sudo ndssnmpconfig' alias ndssnmpsa='sudo ndssnmpsa' alias ndsstat='sudo ndsstat' alias ndstrace='sudo ndstrace' alias nmasinst='sudo nmasinst' alias novell-getcore='sudo novell-getcore' alias nss='sudo nss' alias ssscfg='sudo ssscfg'
The .bashrc file works like a script. In other words, if you simply typed all of the above ‘alias’ commands at the linux console prompt, you would accomplish exactly the same thing as placing all of these commands in the .bashrc file.
The above strategy using the .bashrc file to assign aliases for the sudo commands works fine for a single eDirectory admin user, but it might get a little cumbersome to apply this to multiple users. So let’s take the next logical step. We could place all the same alias commands as above in a bash script file, such as this in /opt/novell/eDirectory/scripts/edircmnds.sh:
#!/bin/bash # edircmnds.sh # Aliases required for eDirectory administration using sudo # Usage: edircmnds.sh alias dsbk='sudo dsbk' alias dxcmd='sudo dxcmd' alias edirutil='sudo edirutil' alias ice='sudo ice' alias idm-install-schema='sudo idm-install-schema' alias ldif2dib='sudo ldif2dib' alias ndsbackup='sudo ndsbackup' alias ndscheck='sudo ndscheck' alias ndsconfig='sudo ndsconfig' alias ndsdibupg='sudo ndsdibupg' alias ndsimonitor='sudo ndsimonitor' alias ndsindex='sudo ndsindex' alias ndslogin='sudo ndslogin' alias ndsmanage='sudo ndsmanage' alias ndsmerge='sudo ndsmerge' alias ndspath='sudo ndspath' alias ndsrepair='sudo ndsrepair' alias ndssch='sudo ndssch' alias ndssnmp='sudo ndssnmp' alias ndssnmpconfig='sudo ndssnmpconfig' alias ndssnmpsa='sudo ndssnmpsa' alias ndsstat='sudo ndsstat' alias ndstrace='sudo ndstrace' alias nmasinst='sudo nmasinst' alias novell-getcore='sudo novell-getcore' alias nss='sudo nss' alias ssscfg='sudo ssscfg'
Then, to make this script easily accessible to all users, we could use ‘ln’ to create a symlink in /usr/bin for this script by executing:
ln –s /opt/novell/eDirectory/scripts/edircmnds.sh /usr/bin/edircmnds
Then the user would merely need to type ‘. /usr/bin/edircmnds’ or simply ‘. edircmnds’ to setup all the aliases. Better yet, we can put this command in the user’s .bashrc, and thus not require the user do anything to setup the aliases:
# .bashrc file . /usr/bin/edircmnds
Note the leading period and space (. ) before the command in all cases. This is required so that Linux will apply the ‘alias’ commands to the user’s interactive shell, instead of only in the script’s own non-interactive shell. The ‘/usr/bin’ directory is used, merely because normally all users have a search path to that directory. Root access would be required to create the links in /usr/bin.
This centralized strategy is helpful, especially when you might want to update the list of command aliases for multiple users, so that you don’t have to update several ‘.bashrc’ files. All users can refer to the central ‘edircmnds’ script located in /opt/novell/eDirectory/scripts (or wherever else you may choose to locate it).
Now our eDirectory admins, who are to the Linux operating system just normal, unprivileged users, may merely log into the Linux system with their own user accounts, and automatically have the aliases applied to their interactive shell, and now can run the necessary eDirectory management commands (as specified in the sudoers file), as if they were logged on as the root user.
The “sudo” solution, coupled with the “alias” solution, takes care of the problem of running all of the commands needed to manage eDirectory as a non-root user. However, there are other common eDirectory maintenance tasks which may require additional configuration for use with non-root users. For example, if I want to check for the presence of an eDirectory core file in the DIB directory, I would typically use the ‘ls’ command, such as:
ls –l /var/opt/novell/eDirectory/data/dib/core*
But this doesn’t really work for the normal user account, since by default, root is the owner of these files and directories, so the non-root user would get this response:
joeuser@sles-idm1:~> ls –l /var/opt/novell/eDirectory/data/dib/core* /bin/ls: /var/opt/novell/eDirectory/data/dib/core*: Permission denied
This is because the owner of the target directory /var/opt/novell/eDirectory/data/dib is (of course) root, and the directory permissions do not allow other users to perform the ‘ls’ command on this directory.
We can change this restriction by modifying both the group permissions on this particular directory, and by also changing the “mode” of the directory, to allow the group members to perform commands such as ‘ls’. This can be done in two steps. First, as the root user:
chgrp -R ediradmins /var/opt/novell/eDirectory/
This changes the group assignment for the /var/opt/novell/eDirectory folder (directory) so that the assigned group is now ‘ediradmins’ The ‘-R’ parameter makes the ‘chgrp’ command execute recursively, so that all files and directories below /var/opt/novell/eDirectory also receive the same group assignment. That was “step one”.
Secondly, to change the “mode” or permissions about what users can do on the files and directories, we use the ‘chmod’ command, as such:
chmod 754 /var/opt/novell/eDirectory/ chmod 754 /var/opt/novell/eDirectory/data/ chmod 754 /var/opt/novell/eDirectory/data/dib/
For this case, we really only need the third command to specifically list the contents of the eDirectory DIB directory, but I’ve included the two parent directories for good measure, in case we would want to list files there. I’ve refrained from using the ‘-R’ option, as previously, since that would change the permissions not only on the directories, but on every file under these directories as well.
In this example, we are using the numeric expression for permissions. For more information on chmod permissions, you can type ‘man chmod’ at the Linux console.
Once this is accomplished, then the non-root user who is a member of the ‘ediradmins’ group can successfully execute commands such as ‘ls’ on the eDirectory DIB directory, such as:
joeuser@sles-idm1:~> ls -lgo /var/opt/novell/eDirectory/data/dib/core -rw-r--r-- 1 0 2008-12-22 14:04 /var/opt/novell/eDirectory/data/dib/core.test
Depending on the type and level of eDirectory administration that is required, there will be other file permissions that we may need to set. For example:
chgrp -R ediradmins /etc/opt/novell/eDirectory/conf chmod 664 /etc/opt/novell/eDirectory/conf/*conf*
This would allow members of the ‘ediradmins’ group to read and edit the eDirectory configuration files.
Most Linux administrators rely upon various “home-grown” or custom scripts to assist them in managing both the Linux servers and the applications residing on the Linux platform. You may find that you also have a need to develop some custom scripts to assist in your own eDirectory management.
For example, if you decided to create a simple script that accomplishes precisely what we did in the previous example, to list any eDirectory core files, you might come up with something like this:
#!/bin/bash # listcore.sh # List any eDirectory core files in the DIB directory on the local server # Usage: listcore.sh DIBDIR=/var/opt/novell/eDirectory/data/dib ls -gko $DIBDIR/core*
You might, if you choose, place this script file ‘listcore.sh’ in /opt/novell/eDirectory/scripts, and then create a symbolic link in /usr/bin to the script by executing:
ln –s /opt/novell/eDirectory/scripts/listcore.sh /usr/bin/listcore
This would allow a user to merely type ‘listcore’ to perform a directory listing of any files in the /var/opt/novell/eDirectory/data/dib/ directory which started with “core”.
Another example might be a script to list the file size of the eDirectory database itself. For this, we might write a simple script such as:
#!/bin/bash # listdib.sh # List any eDirectory core files in the DIB directory on the local server # Usage: listdib.sh DIBDIR=/var/opt/novell/eDirectory/data/dib ls -gko $DIBDIR/nds.01
Similarly, we could create a symlink for this script by executing:
ln –s /opt/novell/eDirectory/scripts/listdib.sh /usr/bin/listdib
Then a user could merely type ‘listdib’ to list the current size of the eDirectory database.
The point of these script examples is that if you do utilize any such custom scripts, and these scripts need to run, as do some of the eDirectory commands, as the root user, then these scripts can be added to the ‘sudoers’ file as well, such as:
# Commands required for managing eDirectory 8.8: Cmnd_Alias EDIRCMDS=/opt/novell/eDirectory/bin/dsbk, \ /opt/novell/eDirectory/bin/dxcmd, \ . . . /opt/novell/eDirectory/sbin/nldap, \ /usr/bin/listcore, \ /usr/bin/listdib
It is perfectly fine to list the symlinks in the ‘sudoers’ file, since they merely point to the actual script files themselves.
This strategy is a useful alternative when there is a need to execute specific commands, and it is not convenient or practical to change all file permissions in all places where they may be needed. The commands can be scripted, and the scripts themselves added to the ‘sudoers’ command alias list, so that the scripts would now be run as the root user.
Just to recap my suggested solution for managing eDirectory as a non-root user on Linux:
- Have the Linux administrator configure the ‘sudoers’ file for eDirectory commands
- Create a script to alias those “sudo commands” so that users don’t need to type ‘sudo’
- Modify the file and directories rights appropriately for accessing eDirectory files
- Use custom scripts where desired, and also add them to the ‘sudoers’ file when needed
These few steps alone will allow non-root Linux users to effectively manage the eDirectory application running on a Linux server, without having to first become “Linux gurus”.
Undoubtedly, however, the eDirectory admins will at some point discover a new “permission denied” roadblock when trying to perform some type of administrative task, depending on the type and level of eDirectory administration which they are required to do. For these eventualities, we should understand that there may need to be some future additions to the commands in the ‘sudoers’ file, and some additional file permissions which need to be set.
With these strategies, the author wishes to help eDirectory admins to more easily make the transition to the Linux platform, and as well to foster greater peace of mind for Linux admins, who wish to maintain the security of their platforms when eDirectory is the primary application.