Jon Hardman
Sofware Engineer II
Identity Manager Resource Kit

Table of Contents

• Overview

• Prerequisites

• Installation and Configuration

• SUSE Linux

• eDirectory (for stand-alone configuration)

• Installation:

• eDirectory Configuration:

• Configure saslauthd to use ldap authentication

• Configure postfix to use saslauthd

• Test saslauthd and postfix

• Configure IDM to use your postfix mta service

• Conclusion

Overview

Many times when deploying Novell's Identity Manager Solution, the IDM administrator want to have an email server available for things such as events from IDM driver policies, password change notifications, or workflow events from the IDM user application. In many cases, however, whether the issue is political or technical, a company's IS&T may not allow 'access' to the Enterprise mail server(s) by an outside entity. Ideally, a secure mail relay should be available on the IDM server which allows authorized IDM UserApplication 'users' to send email when required. This document describes how to install and configure the postfix smtpd mta agent as a secure email relay with cyrus-sasl-saslauthd using ldap authentication against eDirectory for smtp_auth.

Operating System tested:
     SUSE Linux Enterprise Server 10 SP1 (SLES10SP1)
eDirectory versions tested:
     eDirectory 8.8.2 for Linux
Identity Manager versions tested:
     IDM 3.5.1 for Linux
Postfix versions tested:
     postfix-2.2.9-10.18
Cyrus-sasl-saslauthd versions tested:
     cyrus-sasl-2.1.21-18.4
     cyrus-sasl-saslauthd-2.1.21-18.4

Prerequisites

SUSE Linux Enterprise Server 10 SP1 x86 architecture
postfix, cyrus-sasl, cyrus-sasl-saslauthd packages installed

eDirectory 8.8.2 installation files (archive or iso)
Novell Identity Manager 3.5.1 DVD

This article assumes a working knowledge of eDirectory and IDM. It also assumes that you have and existing IDM deployment that will be using the postfix mta service. If you with to configure a 'stand-alone' postfix configuration that will not be doing ldap authentication against
your IDM 'Identity Vault', you will have to install eDirectory on the system separately.

Installation and Configuration

SUSE Linux

1. Install SLES 10 SP1 x86. For software pattern installation, be sure that cyrus-sasl, cyrus-sasl-saslauthd, and postfix are selected within the 'Server Base System' install pattern.

eDirectory (for stand-alone configuration)

Installation:

1. Download eDirectory 8.8.2 iso from download.novell.com

• “su” to root ('su' in console, enter root password)

• Mount the eDirectory installation .iso as /media/cdrom ('mount -t iso9660 -o loop eDir_882.iso /media/cdrom')

• “cd” into /media/cdrom (this may also be “/media/cdrom/eDirectory/setup”, depending on the eDirectory version) ('cd /media/cdrom')

• execute './nds-install'. Select options 1 and 2 for full eDirectory installation.

eDirectory installation is now complete. You can now configure your eDirectory tree using the eDirectory utility 'ndsconfig'.

eDirectory Configuration:

1. First, you must set your system PATH for the nds binaries/libraries by issuing command '. /opt/novell/eDirectory/bin/./ndspath' in the console. (Note that the command starts with dot-space)

• Now configure your eDirectory tree from the command line using ndsconfig; i.e. 'ndsconfig new -t MYTREE -a cn=admin.o=novell -n o=novell -S myserver -i -e -D /var/opt/novell/instance0 -d /var/opt/novell/instance0/data/dib -w password --config-file /var/opt/novell/nds0.conf' (The '-i' option ignores duplicate tree lookup, '-e' enables ldap clear-text password. If you want to keep the default secure ldaps connection setting, omit the '-e' switch and use either SSL to TLS to connect via ldap.

1. You may also just use 'ndsconfig new -i' and enter options from the command line when prompted. The '-i' option will skip the duplicate tree name lookup which will fail if slp is not running. You may omit this option if you start the slpuasa service with '/etc/init.d/slpuasa start'

• Once eDirectory configuration is complete, you can verify ndsd is up and running with 'ndsstat'.

Configure saslauthd to use ldap authentication

Set up saslauthd to authenticate against our ldap server:

1. Enable postfix and saslauthd to start at boot

1. “yast2 runlevel”

• 'enable' postfix and saslauthd (default will start them in runlevels 3 and 5)

• Finish

• From your favorite editor, edit /etc/sysconfig/saslauthd

1. First, back up the original file (cp /etc/sysconfig/saslauthd /etc/sysconfig/saslauthd.bak)

• edit the file (vi /etc/sysconfig/saslauthd

1. change the 'mechanisms' line to read “SASLAUTHD_AUTHMECH=ldap”

• add entry ' CONFIG_FILE=”/etc/saslauthd.conf” '

• write changes and quit

• edit the /etc/saslauthd.conf file (vi /etc/saslauthd.conf)

1. Unlike other, less secure ldap servers, eDirectory requires TLS by default. No problem.

1. add entry 'ldap_servers: ldaps://your.ldap.server:636/'

• this entry is the ldap server you wish saslauthd to do ldap authentication against. This could be your IDM 'Identity Vault' or another, stand-alone ldap server. If desired, clear-text will also work with 'ldap://your.ldap.server/' (port number optional)

• add entry 'ldap_search_base: dc=example,dc=com'

1. This is the ldap context where the users should exist for the ldap bind operation. An example might be 'o=novell' or 'ou=users,o=novell'. Omit this entry if you would like saslauthd to search the entire tree from the root.

• Restart saslauthd (/etc/init.d/saslauthd restart)

• Verify that saslauthd is using ldap with “ps -ef | grep saslauthd”. You should see entries that look like “/usr/sbin/saslauthd -a ldap”.

Configure postfix to use saslauthd

Now, enable postfix to use saslauthd

1. Edit /etc/postfix/main.cf

1. change the line smtpd_sasl_auth_enable to read 'smtpd_sasl_auth_enable = yes'

• edit the line 'smtpd_recipient_restrictions=' to include 'permit_sasl_authenticated'

1. with the default settings it would look like this: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

• add the following lines:
  
  1. smtpd_sasl_security_options = noanonymous
  
  
• smtpd_sasl_local_domain =

• broken_sasl_auth_clients = yes

• save changes to postfix main.cf

• restart postfix (/etc/init.d/postfix restart)

Test saslauthd and postfix

1. to test saslauthd, use testsaslauthd

1. “testsaslauthd -u username -p password”

• if it's working, you should see a similar message

1. 0: OK "Success."

• to verify postfix is expecting smtp_auth:

1. Verify that postfix is running and has authentication enabled by telneting to port 25 on the mail server (telnet mail.example.edu 25).

• You should see something like:
  

  
  	Trying 10.0.0.17...
    	Connected to mail.
    	Escape character is '^]'.
    	220 mail.example.edu ESMTP Postfix

• Once connected, type ehlo localhost
  

  
  	250-mail.example.edu
    	250-PIPELINING
    	250-SIZE 31457280
    	250-VRFY
    	250-ETRN
    	250-AUTH NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5
    	250-AUTH=NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5
    	250 8BITMIME

• The “AUTH” lines contain “LOGIN” which shows that postfix will require a login before forwarding mail (this will also be the authentication 'type' if you are using a mail client)

Configure IDM to use your postfix mta service

Now, configure your IDM deployment to use the postfix mta as it's mail relay

1. Log into your IDM deployment via iManager

• Select 'Workflow Administration' => Email Server Options

1. Enter your postfix server's ip address or host name

• Enter the 'from' address for emails sent by IDM or the UserApplication Portal

• Check the “Authenticate to server using credentials:” checkbox

1. Enter the user (rdn) of a user that exists in the 'ldap_search_base:' configured in the saslauthd.conf file (an example might be 'admin')

• Enter the user's password.

• Hit the “OK” button to apply your changes
  IDM should now be able to send emails thru your postfix server.
  
  If you would like to 'see' email being processed by the postfix mta, you can
  'tail -f /var/log/mail.info'

Conclusion

You should now have a fairly secure postfix mta that your IDM deployment (or regular mail clients, for that matter) may now use to relay email messages.