smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 6:33 am.

Sub Menu

Category Details
Category Name
Category Created
Mon, 13th Aug 2007
Last Article Update
Fri, 19th Oct 2007
Category Actions


LDAP Authentication against an Active Directory server 

External LDAP Authentication with CommuniGate Pro requires an authentication plugin. There is more information on this topic, as well as sample authentication plugins, here:

The latest such plugin, and the one we'd recommend for its improved functionality (supports multiple LDAP servers and better character handling), is this one:

Active Directory:
Please note, we are not necessarily Active Directory experts. More more info, you may need to reference the Microsoft Support Site.
However, it appears that Active Directory stores its user accounts in this LDAP tree, by default:

For our purposes here, we will use the example domain "", and an active directory server named ""

One good technique when working these things out is to first test LDAP functionality using an ldapsearch client or browser. We will use the OpenLDAP command line tool "ldapsearch" here:

Using ldapsearch, here is one apparently successful method of querying Active Directory via LDAP:
 # ldapsearch -x -H ldap:// -D "" -W -b "cn=users,dc=example,dc=com"
Enter LDAP Password: *******

# extended LDIF
# LDAPv3
# base <cn=users,dc=example,dc=com> with scope sub
# filter: cn=test1
# requesting: ALL
# Test1, Users,
dn: CN=Test1,CN=Users,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The above represents a successful "bind" against the LDAP server using the "bindDN", and a successful retrieval of the "test1" account data. This type of bind and data retrieval is useful, though not immediately applicable to this particular example, as it uses a special bind account (such as Administrator). Often, for security purposes as well as overall simplfication, we would prefer to bind as the actual user who is trying to authenticate - this is how the script works in most cases.

Therefore, if using any of the authLDAP scripts for external authentication, one would likely configure it like the following, for integration with Active Directory:
address=>'',                      # the address or IP of LDAP server
timeout=>5, # timeout in seconds, 20 by default
adminDN=>'', # the DN for admin bind
searchBase=>'cn=users,dc=example,dc=com', # search base for NEW and SASL commands
bindDN=>'cn=<user>,cn=users,dc=example,dc=com', # the account DN for direct bind for VRFY command

Please note: the "adminDN" and "adminPassword" entries are not used for a standard "bind as user" authentication mechanism, therefore you can choose to leave this entries blank for this method of authentication. If using an external authentication "READPLAIN" authentication method - which is required to use external LDAP authentication with Pronto or for any SASL challenge-response mechanisms (such as CRAM-MD5, DIGEST-MD5, or NTLM), then the "adminDN" and "adminPassword" fields must be used in order to perform a "bind as special account", which is allowed to retrieve a plain-text password. There is more information on this technique here:

View Full Article Add Comment

Linux NFS file caching bug, prior to kernel 2.6.13 

Linux STABLE kernel version 2.6.13 (released August 28, 2005) fixed an NFS "file size caching" bug that some linux cluster sites (on an NFS Shared File System only) experienced. As described in more detail at the end of this message, the problem previously encountered is related only to Linux on NFS in a clustered environment.

This bug was identified during the SPECmail world-record setting tests, and CommuniGate Systems worked with some of the developers who work on the NFS client portion of the Linux kernel in order to resolve this problem. CommuniGate Systems does have a simple application test for checking for this particular problem - please contact CommuniGate Support if you feel you need this application.

There are a number of patches in 2.6.13 related to NFS, so we're not quite sure which one fixed the bug:

The linux 2.6.13 kernel is available here:

Anecdotally, there were reports from some customers that 2.6.14 also fixed some other potential NFS trouble spots.

Also, some Linux vendors incorporated these NFS patches into previous kernel versions, in order to proceed more cautiously in their kernel releases for their supported Linux versions. For example, RedHat has apparently backported the 2.6.12/2.6.13/2.6.14 NFS kernel patches into the RedHat ES 4.5 release, although it technically lists as "2.6.9-55.0.9.EL". For RedHat ES/AS 4.5 may be the only stable release in the RedHat 4 branch - any kernel earlier than this may likely still contain the NFS Linux kernel bugs and therefore may cause file corruption issues within the cluster.
View Full Article Add Comment

SASL authentication with an external LDAP directory 

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:

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:

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".


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 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
userPassword: pass1

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

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 script at this location on most operating systems:


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

   [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:

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:
> 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.

> 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.

View Full Article Add Comment