LUM-enabling pure-ftpd: Quick and Easy

 

On OES Linux, depending on the version of OES and the Install / Configuration options used, pure-ftpd may not already be LUM enabled, and in some cases there may not be an option in YaST to accomplish that.  However, this is very easy to accomplish.  Other documents have been published on this subject, but sometimes take more difficult routes.  For those already familiar with pure-ftpd in a Suse Linux environment, there are actually only a couple of simple steps needed.  However, for those not yet familiar with pure-ftpd or Linux, many additional points will be discussed here.

 

It may be best to first discuss what is meant by "LUM-enabling" a service, especially in regard to pure-ftpd, because this can mean various things.  Most people think of a "LUM-enabled" service as one which find users and authenticate them using eDirectory.  However, there is more than one way to accomplish that.  In the very strictest sense, the true method of LUM-enabling a service is for the pam configuration for that service to contain entries for pam_nam.so.  This module (pam_nam.so) hooks into NAM (Novell Account Management).

 

Similar results can be accomplished by using pam_ldap.so instead.  This can successfully lead to the same end result (finding and authenticating users in eDirectory).  However, a service using pam_ldap.so is not, in the strictest sense, "LUM-enabled," even if the end result is the essentially the same.

 

Pure-ftpd has some knowledge of ldap already, but uses different ldap libraries than pam_nam.so uses.  Because of this, some early problems existed between pure-ftpd and pam_nam.  The known problems were resolved in OES 2 SP2.  Therefore, when LUM-enabling pure-ftpd, the method to use will depend upon your OES version and support pack.

 

 

 

1.  The OES (Linux) server has been successfully installed, and is part of a functioning tree.  It is at least at the level of OES 1 SP2.  As part of this, nam (namcd, nam.conf, etc) are configured and functioning properly.

 

2.  LUM-enabled users exist in the tree, and it is our goal that they be able to log into OES through pure-ftpd.

 

3.  If this is OES 1, this document assumes the pure-ftpd package has been installed already.  If this is a newer version of OES, steps below will take care of this, if it is not already installed.

 

 

 

At the server where pure-ftpd will be running, give the following command:

where "username" is replaced with the name of the LUM-enabled user which you will be testing.  This user should exist in eDirectory but should not exist as a "local user" in the traditional Linux files (i.e. /etc/passwd).  This "id" command should return the same information about the user and his group(s), as retrieved from eDirectory (user object, linux profile tab).  If the user is not found by "id", then there is a problem with LUM or with that user object, which should be addressed before expecting the user to successfully log in through pure-ftpd.

 

 

The first step that is needed (aside from the prerequisites mentions above) is to tell Yast's OES configuration to install "Novell FTP".  Specifically:

 

1.  As root, run yast2 (graphical version of YaST).

2.  In the left frame, select Open Enterprise Server.

3.  In the right frame, select OES Install and Configuration.

4.  On the Software Selection screen, under "OES Services" check "Novell FTP".

5.  After this installs the FTP components, it will bring you to a OES Configuration screen.  To verify FTP is considered a LUM service, find the "Linux User Management" section.  Underneath it, it will say "reconfigure is disabled."   Click the word "disabled" and it will change to "enabled" and a summary will come up.  FTP should say "yes."  If it does not, click the heading "Linux User Management," login as admin.  At the new screen, simply click "next." Then on the subsequent screen, check the box for FTP.  For troubleshooting purposes (i.e. to do comparisons with another authentication method), it is often helpful to also check "su".

6.  Click Next, Accept, and/or Finish as needed to continue through the installation.

 

NOTE:  In step 4, if "Novell FTP" is already checked, the LUM confiuration should still be verified by highlighting "Novell Linux User Managenment" in the left-hand frame, then clicking "accept".  Then proceed with step 5.

 

 Specific information about OES 2 SP2 and SP3:

 

Typically no more LUM-enabling steps are mandatory on OES 2 SP2 or SP3.  However, if you wish to verify what was setup by YaST, the primary important change will be to the pam file for pure-ftpd, /etc/pam.d/pure-ftpd.  It will contain the following (only showing the uncommented lines):

 

auth       required     pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       required     pam_nam.so
account    required     pam_nam.so
password   required     pam_nam.so
session    required     pam_loginuid.so
session    optional     pam_nam.so

 

Since pam_ldap is in use with these older support packs, it is also important that the /etc/ldap.conf be set up correctly.  Even if other services which use pam_nam are interacting with eDir correctly, pure-ftpd could fail because it is relying on pam_ldap instead.  It is not recommended that you set up the LDAP client in YaST, because that does more than is typically desired on a OES system.  Typically there are just 2 settings that need to be checked in /etc/ldap.conf :

 

- The "host" line should point either to 127.0.0.1 (if this OES system is an ldap server -- most are) or to another ldap server in your tree.

 

- The "base" line should show the level or your tree where user searches should begin.   The default for the "base" line is just an example.  Do not let this example deceive.  The "dc=" example is not appropriate for a Novell tree.  The base for Novell will typically be a o= or ou=.   For example:

 

base ou=city,o=company

 

Note the use of commas instead of dots between containers, in ldap format.

 

NOTE:  Use of the LDAP settings directly within /etc/pure-ftpd/pure-ftpd.conf, or /etc/pure-ftpd/pureftpd-ldap.conf, is neither necessary nor recommended.  Our approach is for pure-ftpd to use ldap via pam, not directly.

 

 

 

There is not an option in Yast to Enable "Novell FTP".    First, make sure the pure-ftpd package is installed.

 

Next, /etc/pam.d/pure-ftpd must be set manually.  It typically would be set as follows:

 

#%PAM-1.0

auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed

auth required pam_shells.so

auth required pam_ldap.so

account required pam_ldap.so

password required pam_ldap.so

session required pam_loginuid.so

session optional pam_ldap.so

 

Alternatively, to support both LUM and local users, the following can be tried (although this has not undergone extensive security testing):

 

Lastly, the LDAP client must be configured correctly.  See the LDAP.CONF instructions in the section immediately above, titled "Specific to OES 2 and OES 2 SP1" for the minimum steps.

 

 

 

Every environment may have slightly different needs, and the "default" configuration for pure-ftpd is rarely going to be what is needed.  The first thing to do is to read through the configuration file, /etc/pure-ftpd/pure-ftpd.conf .  While reviewing it there will likely be several changes needed.  A few of the common ones will be listed below, but it is very strongly recommended that you carefully read through the entire conf file and be familiar with the available parameters and what the existing settings do.  Most administrators will NOT get the results they want without carefully reviewing and modifying this file.

 

Just a few suggestions about areas to focus on:

 

This is set to "yes" in the default .conf file.  This will cause all users to be "jailed" in their home directory as if it were a root directory.  If this is not desired, change it to "no".

 

This is set to "10" in the default file.  Most production systems will need a higher number.  If it needs to be higher than 50, then the PassivePortRange (later in the file) should also be expanded.  Pure-ftpd requires that 2 passive ports be possible for every connection.  So, for example, if 80 simultaneous FTP sessions are needed, then the PassivePortRange should cover 160 ports.

 

This is set to "3" in the default file.  If there is an individual client which will require many sessions open at once, boost this number.  Or if it is intended that a web browser such as MS Internet Explorer be used as an FTP client, boost it as well.  MSIE can rapidly attempt multiple connections and may get denied if this setting has not been boosted.  Other web browsers may have similar habits.

 

This is set to "yes" by default.  Change it to "no" in order to support regular user logins (including LUM-enabled eDir accounts).

 

The size (width) of this range must be at least double the MaxClientsNumber, as noted above.

 

This setting is not usually used unless the following combination is in use:  (1) The FTP Server is behind a NAT device (so it is known by a public address which is not bound directly at the FTP server system) and (2)  FTP sesssions using TLS/SSL encryption will be used.  The combination of those 2 technologies will require that the "ForcePassiveIP" parameter be set to the public address which represents this FTP server.  This must not be set to 0.0.0.0

 

This is usually remarked out (not in effect).  This means that pure-ftpd will listen on port 21 on all available IP addresses on this server.  If you wish to listen on only 1 particular IP address, set that here.

 

This is set to "yes" in the default file.  It is usually required to set this to "no" if users will be uploading files to NSS volumes.  See KB 7000662 for more information.

 

This is set to "yes" in the default file.  If the anonymous account will need to upload files, change it to "no".

 

This is set to "yes" by default.  If users will need to rename files, change it to "no".

 

This is remarked out by default.  Do not attempt to put this into effect unless you have created an appropriate certificate.  For instructions on this, see /usr/share/doc/packages/pure-ftpd/README.TLS.  Find the section which begins, "To create a self-signed certificate".

 

remote_server (available on OES 2 SP2 and above)

This is set to "no" in the default file.  If users will need to access Novell NCP volumes on other NCP servers in the tree, set this to "yes".

 

DefaultHomeDirectory  (available on OES 2 SP3 and above, or OES 2 SP2 with current online updates)

This is remarked out in the default file.  If pure-ftpd should ignore users' individual home directories and instead be placed in a common location, un-remark the line and specify the path.  Used by itself, this should represent a local path, such as /home/ftp or /media/nss/VOL1. (Note:  this setting does not effect the anonymous user.)

 

disable_ascii   (available in OES 2 SP3 and above)

If this OES FTP server is replacing a NetWare FTP server, and ascii file line delimiters should be handled as they were on NetWare (rather than how Linux traditionally handles them), then set this to yes.  Default is no.

 

 

 

1.  For deeper configuration information than what is provided in the .conf file, there are several sources.

 

For FTP options that come from the general linux pure-ftpd package, see the man page for pure-ftpd.  If can be a little confusing to compare options in the conf file to command line settings discussed in the man page.  The best approach is to see what the option in the conf file is, then locate that item in the "Alternative Style" section near the top of the pure-ftpd man page.  Once you find the long style options which corresponds to it (usually an exact match, but not always), it will give you the corresponding short option.  Then look deeper in to the man page for the explanation of that short option.

 

2.  For OES-specific options that Novell has added for remote server functionality, accessing NCP volumes, disabling linux-style ascii manipulation (to mimic NetWare), etc., see the OES online documentation.

 

3.  There is additional documentation located in /usr/share/doc/packages/pure-ftpd, on any Suse system where pure-ftpd has been installed.

 

1.  If you make a change to a LUM user but that change doesn't seem to be reflected in current behavior, use the following command to flush the nam cache:

 

namconfig cache_refresh

 

 

 2.  To fully test whether a eDirectory user is really functioning correctly (which it must be, before pure-ftpd can hope to use it), it is often useful to "su" to that user and perform some file system tests, in a terminal window of the server itself.  The potential hurdle here, however, is that "su" is not always a LUM-enabled service.  If "id username" works but "su username" does not, it may be desirable to check on this.

 

This can be done in YaST (GUI version), Open Enterprise Server, OES Install and Configuration.  Under "OES Services" click to highlight "Novell Linux User Management (LUM)".  Don't change it's check mark to another symbol, just highlight that line. Click "Accept".

 

Wait for the list of various services to populate and display the reconfigure status.  This will likely take around 20 seconds.  Then under "Linux User Management" click on the word "disabled" in "Reconfigure is disabled".  That will change to "enabled".

 

Now click on "Linux User Management" (the heading).  Enter the admin password when prompted (and click OK). This brings up the first LUM configuration screen.  Typically nothing here needs to be changed.  Normally at least the first 3 lines are populated.  In some cases, the second the third lines are not configured, so it's recommended in those cases to enter:

 

-the "Unix Config Context."  This is the location of the "Unix Config" object in eDirectory.  There is typically only 1 per tree, and it is usually in the same context as the admin user.

 

-the "Unix Workstation Context.  This is the location of the Unix Workstation object for this particular OES Server, and is usually in the same context as the normal NCP server object of this machine.

 

Then click NEXT.

 

Now a LUM configuration screen will come up which shows which services to LUM-enable.  Sometimes nothing needs to be changed here.  However, for troubleshooting purposes, a minimum of "ftp" and "su" should be checked.  If there are other services shown which need to be able to authenticate against eDirectory, check those boxes as well.  Click NEXT.

 

This returns to the Novell OES configuration screen.  Click NEXT.  This will rewrite LUM configuration settings.  Once it says "Installation Completed" click FINISH.   A screen may come up for "Novell Customer Center Configuration" at this point.  Click "Configure Later", and then "NEXT".

 

Now, with su being LUM-enabled, the authentication and file system access of the user can be checked independently of FTP.  This will help determine if some problems are in FTP itself or at lower layers.

 

For example, to test authentication of the LUM user, start as any non-root user, and enter:

su username

This should prompt for a password (unless you are acting as root, who is not required to give one).

(If you don't want to deal with any user other than root and the test eDir user, then use this trick:  First su from root to the eDir user (without password) and then su again from the eDir user to the same eDir user, which will require the password and perform the authentication.)

 

Upon giving the password, login will either succeed or fail.  If it fails here, there is still a LUM problem and that must be solved before FTP can be expected to work.

 

Once you have su-ed to an eDir user, you can also test file system access as that user.  This is especially important for NSS volume access, as NSS volumes have their own access controls, beyond the posix permissions used by other Linux file systems.  If your eDir user account cannot access certain paths or files from a terminal, it will not be able to access them from FTP, either.  File system rights may need to be checked, which (in the case of NSS) would mean Novell Trustee rights.

 

 

3.  You may have users which are already LUM enabled, but which aren't associated with this particular workstation.  Make sure to make the proper associations in the users' LUM configurations if you want them to access the OES FTP Server.

 

 

4.  If ftp users are going to interact with NSS volumes, it is recommended to enable hard links on those volumes.  For further details, instructions, or options, see KB 7000662.

 

 

5.  Some aspects of the pure-ftpd configuration may or may not be set appropriately for some user's needs.   It is strongly recommended to review the entire contents of the /etc/pure-ftpd/pure-ftpd.conf file, to be familiar with the settings available. The man page for pure-ftpd may be helpful if even more information is needed.  (Side note:  The YaST "FTP Server" configuration tool will *not* give access to all options available to OES's customized pure-ftpd, so it is recommended to deal directly with the configuration file, rather than use the YaST tool.)

 

To give some examples of why this can be important:  The pure-ftpd.conf file typically contains various restrictions, limiting what FTP users can do on a file system, even if the full right file system permissions / trustee rights have been given to the users in question.  For example, the "KeepAllFiles" and the "NoRename" settings can prevent users from deleting or renaming files (respectively), even if they have file system permission to do so. 

 

If changes are made to the pure-ftpd.conf file, they can be put into effect by restarting pure-ftpd, with:

 

rcpure-ftpd restart

 

 

6.  If pure-ftpd is not launching upon boot, you can enable that with the command:

chkconfig pure-ftpd 35

 

 

7.  With older versions of OES and LUM, user names might be considered case sensitive, so some logins might fail if the submitted name does match that stored in eDirectory. If you don't want to worry about case sensitivity, make sure to be using novell-lum-2.2.0.14-3 or higher.

 

This can be checked with "rpm -q novell-lum".  The newer versions of novell-lum will default to not being case sensitive; but can further be controlled in the nam.conf file with: case sensitive=no/yes

 

If you need to restart namcd to put this change into effect, use:

rcnamcd restart 

 

 

8.  For those who are using pam_ldap (typically only OES 2 SP1 or lower):  The instructions in the LDAP section above are typically adequate on an OES system where LUM/NAM has been enabled (as was stated in the prerequisite section above).  However, if LUM/NAM was not enabled (i.e. if this system is relying on *only* LDAP for eDir access) or if extra customizations have been made, it is possible that something in the configuration may not be adequate for LDAP authentication against eDirectory.  One area of concern is whether LDAP anonymous bind is in use, and/or whether LDAP has sufficient access.

 

a.  If LUM/NAM was enabled, then the [public] entity in the tree will already have the additional rights it needs to get the job done.  In this situation, if defaults are still in place, nothing more should be needed.  [Public] will be used for anonymous binds unless someone has altered the server's LDAP Group configuration in eDirectory.

 

b.  If LUM/NAM was enabled, and you've chosen a proxy user for your Novell LDAP server, to be used for anonymous bind functions instead of [public], the proxy user has certain requirements.  It must have a null password, it must have enough rights.  To check if a proxy user has been set, see the properties of the LDAP group object of your server.  If a proxy user is configured there, go to the tree root object, right-click on the object and select "Trustees of this Object."  Give the proxy user browse entry rights, plus read and compare to the following attributes:

 

CN
Description
O
OU
Object Class
dc
gecos
gidNumber
homeDirectory
loginShell
memberUid
uidNumber
uniqueID

 

c.  If LUM/NAM was *not* enabled, then similarly you must manually give either [public] or a configured proxy user the rights listed above (in 'b').

 

d.  Alternatively, if you do not wish anonymous bind to have enough rights for this, then instead of using anonymous bind, you could chose to set LDAP client side to bind as a special user.  This would be done in /etc/ldap.conf, with the binddn and bindpw settings.  This is also called a "proxy user" although it is a slightly different kind of proxy user than that discussed in 'b' and 'c' above.  In 'b' and 'c', that proxy user is used behind the scenes at the LDAP server to perform the work of anonymous binds.  In /etc/ldap.conf, specifying a proxy user means that anonymous bind will be completely bypassed.  The client will bind directly as the specified user.  The rights requirements of this proxy user are the same as discussed in 'b' above, but the password requirement is different.  This proxy user *must* have a password, or the system will reject it and fall back to anonymous bind anyway.