smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 9:27 pm.

Sub Menu

Article Data
Article Ref
2272-WTXV-8661
Written By
Thom O'Connor
Date Created
Mon, 13th Aug 2007
Updated By
Thom O'Connor
Date Modified
Fri, 7th Sep 2007
 
(Lost?)

   SASL authentication with an external LDAP directory

Question 

How do I perform SASL authentication with an external LDAP Directory (an LDAP server external to CommuniGate Pro)?

Answer 

SASL authentication can be used with external LDAP authentication. SASL with an external LDAP server requires that the LDAP server be able to either perform the necessary SASL calculations in tandem with CommuniGate Pro, or even easier, to simply return the PLAIN text password to CommuniGate Pro, and allow CGatePro to perform the SASL methods.

These techniques are documented in the Guide in External Authentication:
http://www.communigate.com/CommunigatePro/Helpers.html#AUTH

Using these methods will allow SIP, XMPP, and Pronto to work using SASL authentication methods with an external Directory.


SASL Overview:

It is helpful to understand why SASL authentication "challenge-response" mechanisms are used, and why these methods generally require access to the plain-text password. So first, a little background. SASL is defined in RFC 2222 and subsequent documents:

http://www.faqs.org/rfcs/rfc2222.html

One of the primary goals of SASL is to "insert a security layer" between the protocol (such as IMAP, POP, SIP, etc.) and the connection. As noted in the RFC:


To use this specification, a protocol includes a
command for identifying and authenticating a user
to a server and for optionally negotiating protection
of subsequent protocol interactions. If its use is
negotiated, a security layer is inserted between the
protocol and the connection.

In order to achieve this, SASL creates a method of providing a challenge/response mechanism in authentication that enables the usage of a unique per-session authentication mechanism which eliminates the need to pass the raw (plain text) password across the wire, between client and server. CommuniGate Pro implements SASL mechanisms such as CRAM-MD5, DIGEST-MD5, and Microsoft NTLM. The raw plain text password is used as a "shared secret" which itself never traverses the wire, though both sides (client & server) use this shared secret to calculate the required SASL responses.

In short, this results in an authentication architecture where the "plain text password" must be made available to each of the client application and the server application, in order to independently perform the necessary SASL challenge/response calculations. This article discusses one method of providing this plain-text password to CommuniGate Pro using an external LDAP Directory (such as OpenLDAP).

It may help you to simplify this concept to a simple inverse relationship:
  • A more secure on-disk password storage mechanism (CRYPT, MD5, SHA, SHA256) using one-way encryption results in a less-secure on-wire password transmission mechanism (PLAIN, LOGIN)
  • A less secure on-disk password storage mechanism (plain text or two-way encryption or obfuscation) results in a more-secure on-wire password transmission mechanism (CRAM-MD5, DIGEST-MD5, NTLM)

Please note: a new External Helper API command "READPLAIN" was added in CommuniGate Pro 5.1.12 and 5.2c1. This command is required to use external SASL authentication with Pronto and XIMSS.

LDAP Architecture Overview:

If using any external LDAP Directory, the following techniques are recommended:

a) Create a "special bind account" to binding to the LDAP server, and requesting the plain text password for the target account. In our example here, we will use a special bind account called "cgateproBind". This special bind account was created only for the purpose of retrieving this piece of information, and can be restricted from most other access rights.

b) Allow access to the password attribute for this special bind account.

c) As noted above, please confirm now that your LDAP directory is storing the password in plain text (or alternately, in a "two-way" encryption algorithm within which the LDAP server can return the plain text password, if properly requested to do so. Within standardized LDAP schema, the password for an account is usually stored in the attribute "userPassword".

Configuration:

Following are the instructions for configuring external LDAP SASL authentication with OpenLDAP:

1. OpenLDAP slapd.conf configuration

The OpenLDAP slapd.conf must be configured to allow retrieval of the plain text password. This can be accomplished through the addition of an access command like the following:


access to attrs=userPassword
by self write
by anonymous auth
by dn="uid=cgateprobind,dc=example,dc=com" read
by * none

(Please note: your OpenLDAP slapd.conf file may have many such access instructions. This document is not meant to provided an in-depth instructional of OpenLDAP security. Please reference the OpenLDAP.org site for recommended configuration.)


Your slapd process will likely need to be restarted for the new settings to take effect.

2. Add the special Bind account to OpenLDAP. For example, for use example use here, the following is the entire LDAP "LDIF" data required:

dn: dc=example,dc=com
dc: example
o: Example Corporation
objectclass: organization
objectclass: dcObject

dn: uid=cgateproBind,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Special BIND Account
sn: BIND
uid: cgateproBind
userPassword: password

dn: uid=test1,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Test User1
sn: User1
uid: test1
mail: test1@example.com
userPassword: pass1

3. Use the new authLDAPNew.pl authentication plugin from CommuniGate Systems (or other plugins based on the provided techniques). This plugin is provided on the main CommuniGate Systems website:

https://www.communigate.com/CGAUTH/authLDAPNew.pl

This external authentication script should be configured to match the server location and special bind (admin) account required for your LDAP directory. When configuring CommuniGate Pro for use of this script, be sure that these configuration options are used:

a) Put the authLDAPNew.pl script at this location on most operating systems:

        /var/CommuniGate/authLDAPNew.pl

b) Configure [Settings->General->Helpers] to enable "External Authentication" using this script.

c) Configure the relevant Accounts (or Account Defaults) to use External Authentication:

[Users->Account Defaults]
CommuniGate Password = Disabled
External Password = Enabled

or
   [Users->Domains->(Select Domain)->Account Defaults]
CommuniGate Password = Disabled
External Password = Enabled

That should be it. Please test your setup by logging in using SIP, XMPP, or Pronto using XIMSS. For debugging purposes, please set this plugin to a Log Level of "All Info", if necessary [Settings->General->Helpers].

Note: In order to use with Pronto and XIMSS with the READPLAIN method, CommuniGate Pro 5.1.12 (5.1.12e or later) or 5.2 (5.2c1g or later) is required. A pre-release of these builds may be found on the distribution site here:
  ftp://ftp.communigate.com/pub/stuff/Linux/CGatePro-Linux-5.1-12e.i386.rpm
  ftp://ftp.communigate.com/pub/stuff/Linux/CGatePro-Linux-5.1-12e.x86_64.rpm
  ftp.communigate.com/pub/stuff/Solaris/CGatePro-Solaris-Sparc-5112e.tar.gz
  ftp.communigate.com/pub/stuff/Solaris/CGatePro-Solaris-Intel-5112e.tar.gz
 

Additional Technical Background of SASL methods and protocols that require it

SIP & XMPP must provide secure authentication mechanisms - this is part of these RFC-defined protocols. This was implemented specifically to prevent plain text passwords being passed across untrusted networks (i.e., the Internet).

SIP uses "HTTP Digest" authentication:
http://www.faqs.org/rfcs/rfc3261.html
> 26.2.3 HTTP Authentication
> SIP provides a challenge capability, based on HTTP authentication,
> that relies on the 401 and 407 response codes as well as header
> fields for carrying challenges and credentials. Without significant
> modification, the reuse of the HTTP Digest authentication scheme in
> SIP allows for replay protection and one-way authentication.

XMPP uses DIGEST-MD5:
http://www.ietf.org/rfc/rfc3920.txt
> 14.7. Mandatory-to-Implement Technologies
> At a minimum, all implementations MUST support the following mechanisms:
> for authentication: the SASL [DIGEST-MD5] mechanism

SASL challenge/response authentication mechanisms (CRAM-MD5, DIGEST-MD5, HTTP Digest, NTLM) can only work if both the client and server have access to a "shared secret". That shared secret is the plain text password. If the server only stores the hashed password (CRYPT, SHA, SSHA, MD5, etc.) then these mechanisms cannot be used.

XIMSS supports both challenge/response and plain text authentication mechanisms. To allow plain text login via Pronto, I believe you need to disable the CRAM-MD5 "Login Method" for those domains [Users->Domain Defaults] or [Users->Domains->(Select Domain)->Domain Settings]. Doing this disables SSL in Pronto however, if I remember correctly.

So, to put it (overly) simply - it comes down to a basic choice:
 * More secure on disk, less secure on the wire (PLAIN, LOGIN)
 * Less secure on disk, more secure on the wire (CRAM-MD5, DIGEST-MD5, HTTP Digest, NTLM)

As the wire (the net) is generally a far more nefarious place, we would recommend SASL challenge/response authentication is used.

How Useful Was This Article?      (Rating: 92%    Votes: 13)  

Select a Rating

Article Comments 

There are currently no comments.