How Do I Configure ActiveDirectory And LDAP With My AeroFS Appliance?

AeroFS can delegate account management to your existing ActiveDirectory or LDAP server. In both cases, the AeroFS Appliance uses LDAP to talk to the account directory. Account management, including LDAP parameters, is configured through the AeroFS web admin interface under Identity Settings.

Basic Configuration

The following values make up the basic LDAP configuration:

  • Server Host: the hostname or IP of your account server. This address must be resolvable by the Private Cloud Appliance.
  • Server Port: the port to connect to. Default LDAP ports are 389 for ldap, and 636 for ldaps.
  • Base DN: this will be the root of the search tree. Generally you would like to point this at the most specific node in your LDAP store that will include all the users that should have access to AeroFS. If you aren't sure where to point this, see below for some search techniques.
  • Bind user name: to search for a user's email, AeroFS requires access to an account with the ability to run a search. In almost all cases, this should be an account with limited access that you create especially for the AeroFS Private Cloud Appliance. Don't use an unlimited administrator account here. Usually this is given in LDAP format ("CN=Directory Agent,DC=example,DC=com"), but ActiveDirectory will accept other formats ("\\DOMAIN\Directory Agent") etc. See below for hints on testing this.
  • Password: the password for the bind account given above.
  • Security: we strongly recommend you enable StartTLS or SSL. Selecting plaintext will result in a warning, and should be avoided for best network security.

Advanced User Configuration

Here you can configure specifics of your LDAP schema. Most users will not need to modify this section. See below for some hints on easily testing your deployment.

  • Search scope: by restricting this search to the immediate children only, or ignoring the base DN, you can prune undesired matches from the LDAP result set. Normally this is set to "Search the object specified by Base DN and its entire subtree".
  • User class: the object class that all users should belong to. This should be restrictive enough to disallow accounts that may have been allocated for software packages, devices, etc. This becomes part of the LDAP query in the authentication path.
  • First name attribute: the attribute that stores the users' first name. Normally this should be "givenName".
  • Last name attribute: the attribute that stores the users' last name. Normally this should be "lastName".
  • Email attribute: the attribute in the user record that holds the primary email address. This attribute should hold the email address that users will provide to AeroFS as their login information.
  • Additr certificate: if you are using TLS or SSL and your LDAP server does not have a publicly-signed certificate, you may need to set certificate information here. The certificate lets the AeroFS Private Cloud Appliance verify that it connected to the intended server and not an impostor. You should provide the certificate in PEM form (Base64-encoded DER). See below for more information on getting this value from the server.

Advanced Group Configuration

If you choose to enable LDAP Group Syncing on your appliance, more configuration options specific to Groups will appear below the checkbox. You may need to change these default values if you use custom LDAP Object Classes.

  • Search Scope: similar to User Search Scope, except this scope is used when looking for groups to sync between LDAP and AeroFS. Normally this is set to "Search the object specified by Base DN and its entire subtree".
  • Base DN: this will be the root of the search tree when AeroFS searches for groups to sync. Generally you should point this at the most specific node in your LDAP store that will include all the groups that you would like to have in AeroFS.
  • Object Classes:the object classes that AeroFS will recognize as groups and sync from LDAP. Normally there are several different object classes which function as groups, please list them all here in a comma-separated list.
  • Static Member Attributes: attributes on LDAP group nodes which hold group members' Distinguished Names (DNs) as values. Normally a groupOfNames object would have "member" as a static member attribute.
  • Dynamic Member Attributes: attributes on LDAP group nodes which hold LDAP search URLs as values; any group or user returned by these search URLs will be regarded as a member of the group. Normally a groupOfURLs object would have "memberUrl" as a dynamic member attribute.
  • Unique Member/Unique Identifier Attributes:the Unique Member attribute is an attribute of LDAP group nodes while the Unique Identifier Attribute is an attribute of possible group members. The values for the Unique Member attribute should uniquely specify users that are members of the group by matching the value of their Unique Identifier Attribute. An example would be the posixGroup object having "memberUid" as a Unique Member attribute, matching values of "uidNumber" on the group's members.
  • Group Name Attribute: the attribute which holds the name of the LDAP group as you want it to appear in AeroFS.
  • Daily Syncing Time: what time each day you want AeroFS to sync groups with your LDAP endpoint. You can also sync immediately from the Groups administration interface on the Web admin interface.

Testing LDAP connectivity

Any LDAP utility can be used to test and verify your LDAP connection information. The following examples use `ldapsearch`, freely available for OSX and Linux platforms. On Windows, try the ldp tool direct from Microsoft.

Basic connection tests

First, a basic connectivity test. This will validate our values for host, port, bind user name, and bind password.

In the following examples, the bind user name is "CN=Directory Manager"

For LDAP with TLS, our preferred configuration:

ldapsearch -ZZ -h ldap.example.com -p 389 -D 'CN=Directory Manager' -W

For LDAPS:

ldapsearch -H ldaps://ldap.example.com:636/ -D 'CN=Directory Manager' -W

For simple LDAP (last resort, not recommended in production):

ldapsearch -x -h ldap.example.com -p 389 -D 'CN=Directory Manager' -W

When the basic connectivity command succeeds, you can continue. If it fails with authentication error, you should check the permissions and value for the bind DN and the bind password.

If the LDAPS or TLS case fails, you may test the simple LDAP version just to validate the bind information. We strongly recommend you set up a secure LDAP channel using one of the transport-layer security modes.

You may require certificate information to enable TLS / SSL; see the section below.

Finding the root of the user tree

In this example, we'll start by looking for everything in "example.com", using TLS;

ldapsearch -ZZ -h ldap.example.com -p 389 -D 'CN=Directory Manager' -W -z 2 -b 'DC=example,DC=com' mail dn objectclass

The `-z 2` option just limits to the first 2 responses. The -b provides an LDAP path to a search location. Everything after that are the names of the attributes to return for each located record.

Here are the records returned by an LDAP server in our test environment:

# user.1, People, example.com
dn: uid=user.1,ou=People,dc=example,dc=com
objectclass: person
objectclass: inetorgperson
objectclass: organizationalperson
objectclass: top
mail: user.1@maildomain.net
# user.2, People, example.com
dn: uid=user.2,ou=People,dc=example,dc=com
objectclass: person
objectclass: inetorgperson
objectclass: organizationalperson
objectclass: top
mail: user.2@maildomain.net

From the results, we see:

  • The test users are actually grouped under the node "ou=People,dc=example,dc=com" - we will use this value for "Base DN"
  • It looks like "organizationalperson" is a good value for us to use for the "object class" setting.
  • By providing attribute names on this command line ("mail dn objectclass") we can validate the rest of the values to supply in the Advanced configuration - "First name attribute", "Email attribute", etc.

Supplying certificate information

It is possible that your LDAP server was not configured with a publicy-signed certificate. This may happen if your organization has it's own certificate authority, or if your LDAP server is using a self-signed certificate that you trust.

In this case, the AeroFS Appliance requires explicit configuration of the self-signed certificate. Otherwise TLS and SSL communication with the LDAP server will not be permitted.

The following command extracts the certificate from the server and puts it in the required PEM format:

openssl s_client -connect ldap.example.com:636 < /dev/null

When inserting the certificate, include the ---- BEGIN CERTIFICATE ---- and ---- END CERTIFICATE ---- lines in the setup configuration.

Powered by Zendesk