Knowledgebase

Login attributes tab

The settings in the Login Attributes tab determine which LDAP users can log in to your cloudShare system and which attribute or attributes the provided login name is matched against (e.g. LDAP/AD username, email address). You may select multiple user details. (You may bypass the form fields and enter a raw LDAP filter if you prefer.)

You may override your User Filter settings on the Users tab by using a raw LDAP filter.

LDAP Username:

If this value is checked, the login value will be compared to the username in the LDAP directory. The corresponding attribute, usually uid or samaccountname will be detected automatically by cloudShare.

LDAP Email Address:

If this value is checked, the login value will be compared to an email address in the LDAP directory; specifically, the mailPrimaryAddress and mail attributes.

Other Attributes:

This multi-select box allows you to select other attributes for the comparison. The list is generated automatically from the user object attributes in your LDAP server.

Edit LDAP Query:

Clicking on this text toggles the filter mode and you can enter the raw LDAP filter directly.

The %uid placeholder is replaced with the login name entered by the user upon login.

Examples:

• only username:

  (&(objectClass=inetOrgPerson)(memberOf=cn=cloudShareusers,ou=groups,
  dc=example,dc=com)(uid=%uid)
  

• username or email address:

  ((&(objectClass=inetOrgPerson)(memberOf=cn=cloudShareusers,ou=groups,
  dc=example,dc=com)(|(uid=%uid)(mail=%uid)))
  

Groups tab

By default, no LDAP groups will be available in cloudShare. The settings in the Groups tab determine which groups will be available in cloudShare. You may also elect to enter a raw LDAP filter instead.

Only these object classes:

cloudShare will determine the object classes that are typically available for group objects in your LDAP server. cloudShare will only list object classes that return at least one group object. You can select multiple object classes. A typical object class is “group”, or “posixGroup”.

Only from these groups:

cloudShare will generate a list of available groups found in your LDAP server. Then you select the group or groups that get access to your cloudShare server.

Edit LDAP Query:

Clicking on this text toggles the filter mode and you can enter the raw LDAP filter directly.

Example:

• objectClass=group
• objectClass=posixGroup

y groups found:

This tells you approximately how many groups will be available in cloudShare. The number updates automatically after any change.

Connection settings

Configuration Active:

Enables or Disables the current configuration. By default, it is turned off. When cloudShare makes a successful test connection it is automatically turned on.

Backup (Replica) Host:

If you have a backup LDAP server, enter the connection settings here. cloudShare will then automatically connect to the backup when the main server cannot be reached. The backup server must be a replica of the main server so that the object UUIDs match.

Example:

• directory2.my-company.com

Backup (Replica) Port:

The connection port of the backup LDAP server. If no port is given, but only a host, then the main port (as specified above) will be used.

Example:

• 389

Disable Main Server:

You can manually override the main server and make cloudShare only connect to the backup server. This is useful for planned downtimes.

Directory settings

User Display Name Field:

The attribute that should be used as display name in cloudShare.

• Example: displayName

2nd User Display Name Field:

An optional second attribute displayed in brackets after the display name, for example using the mail attribute displays as Molly Foo (molly@example.com).

Base User Tree:

The base DN of LDAP, from where all users can be reached. This must be a complete DN, regardless of what you have entered for your Base DN in the Basic setting. You can specify multiple base trees, one on each line.

• Example:

  cn=programmers,dc=my-company,dc=com

  cn=designers,dc=my-company,dc=com

User Search Attributes:

These attributes are used when searches for users are performed, for example in the share dialogue. The user display name attribute is the default. You may list multiple attributes, one per line.

If an attribute is not available on a user object, the user will not be listed, and will be unable to login. This also affects the display name attribute. If you override the default you must specify the display name attribute here.

• Example:

  displayName

  mail

Group Display Name Field:

The attribute that should be used as cloudShare group name. cloudShare allows a limited set of characters (a-zA-Z0-9.-_@). Once a group name is assigned it cannot be changed.

• Example: cn

Base Group Tree:

The base DN of LDAP, from where all groups can be reached. This must be a complete DN, regardless of what you have entered for your Base DN in the Basic setting. You can specify multiple base trees, one in each line.

• Example:

  cn=barcelona,dc=my-company,dc=com

  cn=madrid,dc=my-company,dc=com

Group Search Attributes:

These attributes are used when a search for groups is done, for example in the share dialogue. By default the group display name attribute as specified above is used. Multiple attributes can be given, one in each line.

If you override the default, the group display name attribute will not be taken into account, unless you specify it as well.

• Example:

  cn

  description

Group Member association:

The attribute that is used to indicate group memberships, i.e. the attribute used by LDAP groups to refer to their users.

cloudShare detects the value automatically. You should only change it if you have a very valid reason and know what you are doing.

• Example: uniquemember

Special attributes

Quota Field:

cloudShare can read an LDAP attribute and set the user quota according to its value. Specify the attribute here, and it will return human-readable values, e.g. “2 GB”. Any quota set in LDAP overrides quotas set on the cloudShare user management page.

• Example: cloudShareQuota

Quota Default:

Override cloudShare default quota for LDAP users who do not have a quota set in the Quota Field.

• Example: 15 GB

Email Field:

Set the user’s email from their LDAP attribute. Leave it empty for default behavior.

• Example: mail

Expert settings

In the Expert Settings fundamental behavior can be adjusted to your needs. The configuration should be well-tested before starting production use.

Internal Username:

The internal username is the identifier in cloudShare for LDAP users. By default it will be created from the UUID attribute. The UUID attribute ensures that the username is unique, and that characters do not need to be converted. Only these characters are allowed: [a-zA-Z0-9_.@-]. Other characters are replaced with their ASCII equivalents, or are simply omitted.

The LDAP backend ensures that there are no duplicate internal usernames in cloudShare, i.e. that it is checking all other activated user backends (including local cloudShare users). On collisions a random number (between 1000 and 9999) will be attached to the retrieved value. For example, if “alice” exists, the next username may be “alice_1337”.

The internal username is the default name for the user home folder in cloudShare. It is also a part of remote URLs, for instance for all *DAV services.

You can override all of this with the Internal Username setting. Leave it empty for default behavior. Changes will affect only newly mapped LDAP users.

• Example: uid

Override UUID detection

By default, cloudShare auto-detects the UUID attribute. The UUID attribute is used to uniquely identify LDAP users and groups. The internal username will be created based on the UUID, if not specified otherwise.

You can override the setting and pass an attribute of your choice. You must make sure that the attribute of your choice can be fetched for both users and groups and it is unique. Leave it empty for default behavior. Changes will have effect only on newly mapped LDAP users and groups. It also will have effect when a user’s or group’s DN changes and an old UUID was cached, which will result in a new user. Because of this, the setting should be applied before putting cloudShare in production use and clearing the bindings (see the User and Group Mapping section below).

• Example: cn

Username-LDAP User Mapping

cloudShare uses usernames as keys to store and assign data. In order to precisely identify and recognize users, each LDAP user will have a internal username in cloudShare. This requires a mapping from cloudShare username to LDAP user. The created username is mapped to the UUID of the LDAP user. Additionally the DN is cached as well to reduce LDAP interaction, but it is not used for identification. If the DN changes, the change will be detected by cloudShare by checking the UUID value.

The same is valid for groups.

The internal cloudShare name is used all over in cloudShare. Clearing the Mappings will have leftovers everywhere. Never clear the mappings in a production environment, but only in a testing or experimental server.