...

The aim of this project is to provide an more effective mechanism to provision users from LDAP into cloudstack. Currently cloudstack Cloudstack enables LDAP authentication. In this authentication users must be first setup in cloudstackCloudstack. Once the user is setup in cloudstack Cloudstack they can authenticate using their LDAP username and password. This project will improve Cloudstack LDAP integration by enabling users be setup automatically using their LDAP credentials.

A detailed version of the proposal is available at: http://ianduffy.ie/cloudstack-ldap.pdf^{Image Removed}

Project Blog

I have created a blogspot blog in order to document progress made with the project.

http://imduffy15.blogspot.ie/^{Image Removed}

Introduction

...

• The user authenticator (plugins/user-authentication/ldap) This enables LDAP users to login to Cloudstack once the user exists within the internal Cloudstack database.
• LDAPConfig (api/src/org/apache/cloudstack/api/command/admin/ldap/LDAPConfigCmd.java) This allows for adding LDAP configuration. This is detailed over here: https://cloudstack.apache.org/docs/api/apidocs-4.1/root_admin/ldapConfig.html^{Image Removed} This did not allow multiple configurations.
• LDAPRemove (api/src/org/apache/cloudstack/api/command/admin/LDAP/LDAPRemoveCmd.java) This allows for removing the LDAP configuration
• UI features. Global settings -> LDAP configuration allowed for the addition of a single LDAP server using the LDAPConfig command and the removal of an LDAP server using the LDAPRemove command.

...

Along with this global configuration options were added to global configuration this includes:

• LDAP basedn: This allows the user to set the basedn for their LDAP configuration
• LDAP bind password: This allows the user to set the password to use for binding to LDAP for creating the system context. If this is left blank along with bind principal then anonymous binding is used.
• LDAP bind principal: This allows the user to set the principle to use for binding with LDAP for creating the system context. If this is left blank along with the bind password then anonymous binding is used.
• LDAP email attribute: This sets out the attribute to use for getting the users email address. Within both OpenLDAP and ActiveDirectory this is mail. For this reason this is set to mail by default.
• LDAP realname attribute: This sets out the attribute to use for getting the users realname. Within both OpenLDAP and ActiveDiretory this is cn. For this reason this is set to cn by default.
• LDAP username attribute: This sets out the attribute to use for getting the users username. Within OpenLDAP this is uid and within ActiveDirectory this is samAccountName. In order to comply with posix standards this is set as uid by default.
• LDAP user object: This sets out the object type of user accounts within LDAP. Within OpenLDAP this is inetOrgPerson and within ActiveDirectory this is user. Again, in order to comply with posix standards this is set as inetOrgperson by default.

...

The API changes required me to update the UI interface within Cloudstack. With the improved API implementation this was easier. The Global Settings -> Ldap Configuration page has support for multiple LDAP servers however it only requires a hostname and port. All "global" ldap settings are set within the global settings page.

Image Added

Image Added

Concerns

I have a few security concerns around the implementation of the security authenticators within Cloudstack. From testing I have done it seems to work on a fail over bases. That is:
User attempts to authenticate with a password, authentication attempts to happen against the internal Cloudstack database, it fails, it moves onto LDAP.

This raises a concern for me as it means if an LDAP user is deleted, if they have changed their Cloudstack Password