Since eDirectory 8.8 was released Novell/NetIQ has provided the option to have multiple eDirectory instances on a single system, and to have these running either as 'root' or as a non-root user. There are benefits to both, but generally speaking it is a proven and best practice to run services as non-root users. For a few reasons I'll cover, this has not been the norm with eDirectory, but some recent changes could help improve that significantly. This tool builds on those, essentially documentation, changes, in order to make the increased security open to anybody with a minimal amount of worry or concern. First, let's talk about the various eDirectory installation options, instance types, and other software depending on these.
One major, and common, point of confusion about eDirectory installs and instances is that their root or non-root nature is directly linked, one with another. For example, one may believe that it is impossible to have a non-root instance of eDirectory unless there is a non-root installation of eDirectory, which is completely untrue. If this seems confusing, let's take a step back to what "instance" and "install" mean in Linux terms.
eDirectory is normally installed via RPMs, and that installation requires 'root' privileges because the RPM database files are owned, and writable, only by 'root'. This is common with almost all software on Linux, and is probably the best way to deploy software on an enterprise distribution like SUSE Linux Enterprise Server (SLES) because it means the files cannot be modified by non-root users (assuming they are setup to only be modified by 'root', which is the norm). This root installation of eDirectory puts files into the filesystem per the Filesystem Hierarchy Standard (FHS), meaning that that executable things from third-parties go under /opt/novell/eDirectory while variable data files go under /var/opt/novell/eDirectory (by default), and configuration files are under /etc/opt/novell/eDirectory (by default). This is simple enough, and something that can be observed with many types of software on Linux.
Contrast this root installation with a non-root installation, which is simply a "tarball" (tar-based archive) that can be extracted anywhere in the filesystem and is self-contained. This is kind of neat because it reduces the installation to a single command to extract the tarball, and then anybody with filesystem space on the server (in their home directory, for example) has the potential to setup an eDirectory instance. Have a Linux workstation which doesn't actually support the RPM-based installation (CentOS, for example, is not officially supported)? No problem, extract this non-root install and get going quickly. This other installation option is not used often, and since it does not have the ties to the RPM database it is not detected by other software that may rely on eDirectory (auditing, Identity Manager (IDM), etc.), but it works just like eDirectory always does.
These contrasting installation options are not to be confused with eDirectory instance options, which are completely independent of the installation options. It is possible to have a root-based instance from either the root (RPM) install, or the non-root (tarball) install; both are valid, though I cannot imagine why you would do the latter. Similarly, it is possible to have a non-root instance running from either the root (RPM) or non-root (tarball) install, and this is the primary focus of today's conversion tool. The reason you may want to do this is primarily because of security; a process running as 'root' has as much control over the system as possible and is seldom restricted in any way. Exceptions to root's phenomenal cosmic power exist in the form of AppArmor and SELinux, both which require explicit configuration for a given service, and as a result are used less than perhaps they should be; even if they are configured, these technologies can easily be configured incorrectly, either preventing proper service function (by detecting a false positive), or allowing improper function (false negative). With any root-running service, then, there is the possibility of a bug (let's be honest.... all software has bugs) and some bugs can allow an outsider to manipulate a service into acting in a way it, per the administrator, should not. Whether it is via buffer (memory) overflow, some sort of code injection (SQL injection is common and popular, but not applicable to non-SQL databases), a service running as 'root' may be able to allow compromise of the entire system, not just its own internals. As a result, the optimal practice is to run everything as a non-root user, specifically a dedicated, non-root, service account.
To provide a comparison with other services, an example with which we are likely familiar is Apache's httpd web service. You may be aware that you can install the 'apache2' package on a SLES system and it will be installed as root, meaning it has an installation similar to eDirectory's. The RPM controls where files go, their ownership, permissions, and provides a convenient way to verify the integrity of files, as well as provide updates in a safe way (not losing configuration data whenever possible). On the other hand, if you look at most of the 'httpd' processes running, they are running as another user, usually 'wwwrun' (the actual service account is trivially configurable). As a result, compromise of one of these processes means that only files owned or writable by those processes can be compromised, assuming sufficient access is gained over the processes themselves. If all of the httpd processes ran as 'root', then the potential for system takeover is very great. This all goes back to the concepts of Least Privilege and Defense in Depth, which if practiced will make our world a better place.
Back to eDirectory, and leaving the non-root installation behind (not as common, not as interesting to me most of the time) we have our root (RPM) installation of eDirectory and the possibility of root or non-root instances. Chances are that you have instances running as 'root' currently. Thankfully, eDirectory has had relatively few security vulnerabilities over the years, but it is worthwhile to aspire to better practices whenever possible, assuming the drawback of those better practices are outweighed by the benefits. I believe, today, that the benefits of a non-root instance always outweigh the drawbacks. Let's review the drawbacks briefly:
Non-root users have less access to low TCP/UDP ports - This may not be something of which you are aware, but it is true. A non-root user cannot, normally, bind low ports (less than 1024) for listening, including the ones eDirectory uses for NCP, LDAP, and LDAPS (524, 389, and 636, respectively) by default. As a result, clients which default to these ports must be told to use alternates. Users using those clients may need to know the alternates. Some poorly-written software may not even allow changing ports (LDAP/LDAPS-using software can be really, really terrible sometimes) and while that is a sign of a very immature application, it's the reality for some. Thankfully, this is all easily overcome via some simple port forwarding on the host. This works by redirecting any traffic received on (for example) TCP 524 to TCP 1524, where eDirectory's non-root instance may be listening by default. This is seamless to the client and service, and handled entirely via the host's firewall.
Supportability from Novell/NetIQ - Until recently there has been the possible question about supportability of non-root instances, with or without root installations. Sure they work, but will they be supported? The recent change at Novell/NetIQ has been the publication of a TID documenting how to make this change, and verification that the steps are supported per engineering. As a result, we now know what before we may have felt should be the case, that non-root instances in root (RPM) installations are supported. This is a great change because it means that the vendor understands the security benefits and supports customers in their endeavors to improve by following best practices. TID# 7016537, perhaps along with others about how to enable non-root instance startup, is the one mentioned above. Similarly, TID# 3048495 exists with a rudimentary (and probably slightly-flawed) method of auto-starting non-root instances at system startup, which is also supported. I would not personally recommend this TID because of incompleteness, but more on that later.
Installation permissions - Whenever a root (RPM) installation is installed, updated, patched, or tweaked in a way that is not instance-specific, the 'root' user must be involved. This has not changed recently, but the Linux distribution provides ways around actually giving out the 'root' password, and has for decades, with tools like 'sudo' or NetIQ's Privileged User Manager (PUM). An administrator ('ab') can be given access to run certain commands as another user (root, or otherwise) and the result is that service administration can be granted without full system administration. If this is too much trouble, then the root installation at least provides better, supported, patch scripts with the media download so a system administrator can apply patches without needing much in the way of help from others or being an experienced eDirectory service administrator. In larger organizations this separation of duties is common anyway, as the system admins will monitor the system overall, including patch management, in order to maintain Service Level Agreements (SLA) and other aspects of the system (including security).
Auto-startup/shutdown is something that, as mentioned above, is supported and mentioned in a TID. Better than that, though, is the ability to trivially set it up without creating your own init script (as the TID would have you do currently) using other Cool Solutions like the ndsd-multi option from a few years ago: Doing some recent testing, it has worked well for current eDirectory versions, including an upcoming beta (9.0), so with hardly any effort multiple, non-root instances can be setup very quickly and easily, supporting both system startup and shutdown. Note: this options does not yet support systemd on SLES 12 or RHEL 7, but that's still relatively new. https://www.netiq.com/communities/cool-solutions/cool_tools/ndsd-multi-way-start-multiple-edirectory-instances-simultaneously-linux/ The setup process for ndsd-multi is simply to download/extract it to /etc/init.d and then make it executable and enabled as a service (chmod x /etc/init.d/ndsd-multi && /sbin/chkconfig ndsd-multi on). After that, add the absolute path of the nds.conf file for your eDirectory instance (root or non-root) to /etc/opt/novell/eDirectory/conf/ndsd-multi.conf and disable the old 'ndsd' instance to prevent both from trying to do the same thing. One instance's conf file should be present per line in the ndsd-multi.conf file, so if you have multiple instances on a single system keep that in mind. ndsd-multi starts the instance with the user that owns the nds.conf file, so be sure ownership of that file is correct (it should be anyway for other reasons).
With all of these drawbacks overcome, there are obvious benefits around a dedicated service account too:
System admins, you can now (if you coordinate with your service admins to properly perform updates/upgrades) keep the 'root' password locked down fully, and not just the password, but the 'root' account (via things like 'sudo'). Service admins no longer need access to it, as they can start/stop/configure/tweak their instances without root privileges, further limiting the ways that full 'root' access of a system can be compromised accidentally. A little support of services is required (forward ports, help with maintenance) from time to time, but the tradeoff is huge in favor of system security which everybody should appreciate.
Also because this deals primarily (though not exclusively) with the root (RPM) installation of eDirectory, other software that ties in with eDirectory works well, including auditing (via the older Novell Audit Platform Agent (PA)) and the Identity Manager (IDM) engine. Outside tools that work with eDirectory likely do not know any difference as most things that cared about hard-coded ports should have been caught and fixed about a decade ago when 8.8 was first released.
One thing still stands in the way of this conversion, and that's actually doing it. The TID to show the steps will probably get you there as long as you do not make any mistakes. I could probably create a video showing the steps, but everybody would still need to run steps themselves, which seems silly. In order to setup systems properly I need to do the steps myself, so why not just do them once in a script and then share for everybody? Of course that is the most-logical option, so this Cool Tool is that script.
To run it, download to your eDirectory server and make it executable (chmod x /path/to/ndsd-convert-to-nonroot). I assume everybody will do this in a properly-built test environment before trying in production. Verifying everything will work after the conversion is smart; while I tried to account for every common (and several uncommon) variable, your environment is your own and it may not appreciate tighter security for some reason. If things go wrong you can go back pretty easily as the script is just automating tasks of moving/copying files and modifying ownership/permissions where appropriate.
Next, download the ndsd-multi script cited above. Copy/Move it to /etc/init.d in extracted (non-compressed) form. You should make it executable and enabled as a service as well, but if you forget then this script will do that for you.
Finally, run the ndsd-convert-to-nonroot command (as root) and answer prompts. The script will ask several things such as which user should run the new instance (e.g. edirsvc, which it can create for you if it does not already exist), which ports you want LDAP and LDAPS to use going forward (e.g. 1389 and 1636, respectively), and which NCP port should be used going forward (e.g. 1524).
If you have ndsd-multi in place then the script will also configure your new non-root instance to automatically start/shutdown via that service, and disable the old ndsd service to prevent multiple attempts to start eDirectory at once.
If you are on SLES then this script will also offer to reconfigure your firewall for you in order to allow services configured for the original ports to continue working.
Until a big prompt near the end where it indicates big changes are imminent, you can hit Ctrl c at any time and have very little to do to revert (maybe change ports back, again at runtime). Once the conversion happens the steps to revert are a little longer, but still are basically moving DIB/data files back and setting the root user to load the instance.
Throughout the script's execution it will ask for two types of things: either yes/no questions (answer with either 'y' or 'n') or some sort of short string (eDirectory service account name, new ports, path for the DIB directory).
That should be it. Once done the data files are (preferably, but your choice) moved to a location that the service user should own, the old 'ndsd' script is disabled, the new 'ndsd-multi' script is setup to run the new instance, NICI files are copied to the non-root user, the service is running its first time (also a prompt), and the firewall is configured to make things easier for clients accessing either old or new ports.
I have tested this quite a bit with eDirectory 8.8 SP8, and a little with eDirectory 9.0 (beta). I'll update it once I have SLES 12 working (systemd changes things) fully, and probably provide some changes as more comes from the beta program on how to make this fully functional.