Re: Courier-IMAP -> OpenLDAP authentication problems

[Adam Pisoni <adam+oldap@p3mammoth.com>]

Thanks to Ken and the rest of you, I thought I had it working.  In reality I didn't.  It turns out that I got it working only as long as Courier used authpam, which is fine for real users, but won't work for the virtual users I intend to use.  When I remove all other auth modules from the authdaemonrc authmoduleslist except authldap, it doesn't talk to ldap at all.  I've upgraded to openldap 2.1.19-1 so I could add the allow bind_v2 (which I did).  Now I'm stumped.

Here's the pertinent data.

==>authdaemonrc
authmodulelist="authldap"


==>authldaprc
LDAP_SERVER             localhost   # I've tried localhost or my real hostname does localhost explicitly break?
LDAP_PORT               389
LDAP_BASEDN             dc=Kittredge, dc=com
LDAP_BINDDN             cn=Manager,dc=Kittredge,dc=com
LDAP_BINDPW             secret
LDAP_AUTHBIND   1	#tried 1 and 0, still not sure what this does

Is there any way to debug authdaemon?  Figure out whether its just NOT using authldap, or using authldap to no avail?  Is there supposed to be an actual authldap library somewhere, because I don't seem to have one.

I did see this in my log many minutes after I tried logging on.

May 23 00:05:21 localhost authdaemond.plain: authdaemon: modules="authldap", daemons=5
May 23 00:14:17 localhost ntpd[846]: time reset 0.259604 s
May 23 00:14:17 localhost ntpd[846]: synchronisation lost

I also don't know if this makes a dif, but I symlinked my /etc/ldap.conf to my /etc/openldap/ldap.conf


Thanks,
Adam

At 11:53 AM -0700 5/20/03, Ken Sorensen wrote:
>Hi Adam,
>   Sorry to leave you hanging. I am writing this email off
>list 'cause it's way off topic. I think your problem is with
>Courier-IMAP compatible user mail directories. In order for
>Courier to work, there must be a Maildir in the users home
>directory, or if you are using virtual users, there must be
>the Courier-IMAP user directory structure available for email
>manipulation. To make this simple, I will use a generic user:
>
>In directory:
>/home/ken/ (my ~ directory)
>    --Maildir/
>	--cur/
>	--new/
>	--tmp/
>
>If the Maildir directory structure is not available, Courier will
>not work. Use 'maildirmake' to create it for all /~user's. If the
>directory structure exists and the permissions reflect the users
>permissions, check the processes to verify Courier is started with
>LDAP.
>
>]$ ps aux
>
>Go to the courier configuration directory, look in the courier/etc
>directory for a file named 'authdaemonrc' and verify the entry:
>
>authmodulelist='authldap authpam authmysql authpgsql authcram
>authuserdb'
>
>Make sure authldap and authpam are in the entries. BTW: I set
>Courier up with authmysql, very cool. 'authuserdb' is for a
>hash database (Pre LDAP) as a replacement for /etc/passwd lookups.
>The imapd.cnf and pop3.cnf files should be set up with your information
>used to create your SSL Certificate. Important note; if you use
>localhost or 127.0.0.1 when self-signing a Cert., your SSL Cert.
>will not work.
>
>Inside my 'authldaprc' file I used:
>LDAP_MAIL	mail
>LDAP_FILTER	(objectClass=inetLocalMailRecipient)
>LDAP_GLOB_UID	95 #My LDAP user accounts are all virtual
>LDAP_GLOB_GID	95 #No shell access. '95' is the uid/gid
>		   #of the courier user in /etc/passwd and
>		   #/etc/group
>LDAP_FULLNAME	gecos
>LDAP_HOMEDIR	homeDirectory
>LDAP_CRYPTPW	userPassword
>
>The entries on the right matched entries in the ldap schema
>inetLocalMailRecipient. Also do you notice how similar to the
>info in the /etc/passwd file this info is? I mapped the above
>configurations as an /etc/passwd entry:
>
>mail:userPassword:uid(95):gid(95):gecos:homeDirectory:/bin/false
>
>I'm assuming you have your LDAP_SERVER,LDAP_BASEDN,LDAP_BINDDN, and
>LDAP_BINDPW set in 'authldaprc' to reflect your server setup. Test
>the ldap query with ldapsearch:
>
>ldapsearch -H ldap://(LDAP_SERVER) -x -b "(LDAP_BASEDN)" -LLL \
>	-D "(LDAP_BINDDN) -w (Enter your LDAP_BINDPW from \
>	the command line. you could also use -W (LDAP_BINDPW)) \
>	"(&(LDAP_FILTER)(LDAP_MAIL=login))" "*"
>(Substitute LDAP_* with your specific authldaprc entries)
>
>The most important thing to verify in the output is your users
>password (LDAP_CRYPTPW). If not, you have a ACL issue in OpenLDAP.
>The OpenLDAP tools use /etc/openldap/ldap.conf for their binding
>configuration. Tools related to pam_ldap like 'finger' use
>/etc/ldap.conf for theirs. Although the preferences of these files
>are similar, it is suggested you configure and keep these files
>separate. Also, LDAP V2 is an old protocol that has been replaced
>with LDAP V3. OpenLDAP 2.0.## uses both V2 and V3 protocol's in
>a kind of a patchy way. The OpenLDAP group strongly suggests to
>migrate to OpenLDAP 2.1.17 or above. Later versions of OpenLDAP
>use LDAP V3 protocol exclusively. OpenLDAP 2.1.x has retro code to
>accommodate V2 with an entry in the /etc/openldap/slapd.conf file:
>
>allow bind_v2
>
>I heard it's still a hack, but if you need LDAP V2 for legacy
>Apps., what can you do?
>
>All of my users have been created with the PADL migration tools in
>/usr/share/openldap/migration/. The users LDIF files use these
>object classes. I wanted to use very common and terse schema's.
>
>objectClass: inetLocalMailRecipient
>objectClass: person
>objectClass: inetOrgPerson
>objectClass: posixAccount
>objectClass: shadowAccount
>objectClass: top
>objectClass: kerberosSecurityObject
>
>The migration tools take the /etc/password entries and convert
>them into a ldif file. I did modify these tools to stop them
>from entering the data directly and removing the /tmp/nis.***
>file when the scripts complete so I could modify it, and add
>the entries myself (slapadd). If you use these tools, reset
>your LDAP db directory (/var/lib/ldap/) and data files back
>to the ldap user and group or you will not be able to read the
>data from the ldap daemon which runs as the ldap user and group.
>If you are using X-Windows, you could also check you LDAP
>configuration with a GUI tool called 'gq'. Great tool for
>becoming familiar with ldap internals and data. It's usually
>in the default install of RH. Speaking of great tools, if you
>use your LDAP server heavily, there is a tool that caches the
>library calls to the getpasswd functions. It's called Named Server
>Caching Daemon (nscd). Every authentication will query the source
>( /etc/passwd, LDAP ) and every successive request will be
>answered by nscd. Keeps from pounding your server with the same
>requests related to users, groups and hosts. The performance
>increase is by order of magnitude. I also set up PAM to use LDAP
>using 'authconfig', as another great time saver tool (see below
>for more info about authconfig).
>
>If all has gone as expected (It never does, doesn't it?), you
>should be able to check the Courier-IMAP POP3/IMAP daemons with
>a telnet connection:
>
>>telnet (HOSTNAME) 110
>>telnet (HOSTNAME) 143
>
>First check a /etc/passwd based email account, if ok, then check a LDAP
>email password account. Always verifying there is a ~/Maildir directory
>structure in both accounts with the proper permissions. BTW: I think
>the shell utility 'finger' will test your pam_ldap configuration for
>both an /etc/passwd and LDAP user.
>
>Also, I wouldn't totally rely on LDAP for authentication of everything.
>PAM is also important to keep as an authentication method. For example,
>if you have admins with shell accounts, you want them  to authenticate
>using /etc/passwd. With those accounts you might want to have several
>thousand mail accounts that do not have shell access. You want the
>system to authenticate users in /etc/passwd to start, then use LDAP.
>On of the hardest thing for me to grasp, was I could use PAM to check
>/etc/passwd, then check a LDAP server(s), then other sources to
>authenticate.
>I didn't need to directly query the LDAP server with my service.
>For example:
>
>Courier->PAM->/etc/passwd
>Courier->PAM->LDAP server located anywhere
>Courier->PAM->MySQL (no kidding)
>Courier->PAM->Kerberos
>Courier->PAM->Samba
>(I could use any or all of these configurations in my PAM
>authentication)
>
>Or I could go directly:
>Courier->LDAP
>
>Basically, the daemon makes a request to the PAM interface, then PAM
>makes the request to something in the backend and gives you the info.
>
>What I really liked about using PAM, was the ability to use Procmail
>to do local delivery of incoming messages without any direct LDAP
>interaction, or modification to Procmail. I have set up Spamassassin
>within my /etc/procmailrc to filter email. Our server does about
>6-8k messages a day for about 15k users. About 75% of it is SPAM.
>Spamassassin catches about 99% of it. I would be out of the email
>business without it. There is a program to modify the PAM configuration
>files (/etc/pam.d/) to use LDAP called 'authconfig'. That app mainly
>modifies the system-auth file in the PAM directory to include LDAP
>(or Kerberos if desired). Also it modifies '/etc/nsswitch.conf' to
>allow ldap for user, group and host related lookups from I believe
>getpwent(), gethostent() library calls (remember nscd). Do yourself
>a favor and modify the pam config file:
>
>]$ vi /etc/pam.d/system-auth
>
>Add the entry:
>
>account sufficient /lib/secure/pam_localuser.so
>
>above the 'account .... pam_ldap.so' entry, so /etc/passwd accounts will
>authenticate and return without querying the LDAP server. In case the
>LDAP server goes offline, you can remotely ssh to the server using an
>/etc/passwd account and administer repairs.
>
>Finally, you need to configure a MDA to deliver local mail from MTA to
>the MUA. Procmail is used with the default RH Sendmail -> UW-IMAP
>daemon.
>The problem with this configuration is Procmail puts new mail in a
>staging area (/var/spool/mail/~login), then the UW-IMAP/POP3 daemon
>moves the mail to the ~user's mail directory. Courier expects to find
>the new messages in the ./Maildir/new/ directory and manipulates the
>message based on the localmail action. Procmail doesn't work with sym
>link's so you cannot symlink /var/spool/mail/~login to ./Maildir/new
>unless you recompile procmail and remove that security check. An
>alternative is to modify the /etc/procmailrc entries to deliver your
>incoming email to your ./Maildir/new directory. For example:
>
>> more /etc/procmailrc
>DROPPRIVS=yes
>SHELL=/bin/sh
>DUMMY=`test -d $HOME || /bin/mkdir $HOME` # We'll make sure homedir
>exists
>MAILDIR="$HOME/Maildir"
># Check that the user has a Maildir/
># We'll make sure Maildir exists
>DUMMY=`test -d $MAILDIR || /usr/bin/maildirmake $HOME/Maildir/`
>MAILDIR="$HOME/Maildir"
>DEFAULT="$MAILDIR/new"         	# Deliver incoming messages to
>LOGFILE="/tmp/procmaillog/$LOGNAME"  	# Procmail delivery logfile
>BULKMAIL=$MAILDIR/bulkmail		# SPAM holding directory
>DUMMY=`test -d $BULKMAIL || /bin/mkdir $BULKMAIL`
>
>:0fw
>        | /usr/bin/spamc -f
>
>:0h
>        LOG=| formail -xX-Spam-Status: |  sed -e '2,$d' -e 's/^.*$/Spam:
>& /'
>
>:0
>        * ^X-Spam-Status: Yes
>        {
># Keep only the last 100 SPAM marked messages based on date.
># Throttle the amount of incoming messages allowed in the MTA agent
># to avoid a run-condition.
>                :0ic: msg.lock
>                | cd $MAILDIR/bulkmail && rm -f `ls -t msg.* | sed -e
>1,100d`
>
>                :0:
>                $MAILDIR/bulkmail
>        }
>
>This configuration uses Spamassassin with the Spamassassin background
>daemon (spamc) to remove SPAM. Procmail is intuitive enough to deliver
>a message in the Maildir format if the new message spool is a directory
>or in mbox format (single file with all messages) if the spool is a
>file.
>
>I use Sendmail (V8.12.x) with this configuration as a MTA. I also use
>LDAP for the aliases portion of Sendmail. My users are unique by a
>number assigned by a database as a permanent id. No one likes to be
>referred as W0202916, but I use that ID as the uid of the specific
>user and alias a more human name(s) to the account. I use the dn
>capabilities of the ou=Aliases to maintain unique email addresses
>in human form and the ou=People to maintain unique UID's. I have
>modified my LDIF file to include both as a 'mail' entry so either
>format can receive email and login to read messages. Here is the
>/etc/mail/sendmail.mc modifications I use:
>
>FEATURE(ldap_routing)dnl
>LDAPROUTE_DOMAIN(`www.example.com')dnl
>define(`confLDAP_DEFAULT_SPEC', `-h 127.0.0.1 -b o=YourORG,c=US')dnl
>define(`ALIAS_FILE', `ldap:-k (&(objectClass=nisMailAlias)(cn=%0)) \
>	-v rfc822MailMember')dnl
>
>Search for the below entry and comment it out by appending a
>'dnl' to the front of it.
>dnl define(`ALIAS_FILE', `/etc/aliases')dnl
>
>Rebuild the sendmail.cf file by issuing:
>m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf (or wherever your
>sendmail.cf file is located). Restart sendmail...
>
>You may notice I use localhost above. SSL doesn't work with localhost.
>So my tradeoff is to allow the OpenLDAP to query info on localhost
>that is not allowed for other queries defined in my ACL of slapd.conf.
>Unfortunately, not as a SSL connection. I believe Sendmail can be
>configured with a BIND_DN, but I just used anonymous from localhost.
>
>Wow, this has been a long message. My brain dump here is about 5 months
>of work to acquire the info and become intimate with the details. One
>thing that really bothered me was I couldn't find a place to find a
>HOW-TO that brought all of these pieces together without researching
>every piece in detail and allot of confusion and bumbling around to find
>the correct configuration. I have bypassed many of the intimate details
>to keep this message from being a book <grin>. I hope this helps you
>chart your way through the configuration of it all. If I got something
>wrong, or wrote it confusing, sorry.
>
>Hope this helps,
>Ken
>
>
>
>
>--
>_________________________________
>Ken Sorensen <ken@e-sorensen.com>