cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [cloudstack-documentation] onitake commented on a change in pull request #67: short description of the evolution of LDAP bindings
Date Sat, 10 Aug 2019 09:01:38 GMT
onitake commented on a change in pull request #67: short description of the evolution of LDAP
bindings
URL: https://github.com/apache/cloudstack-documentation/pull/67#discussion_r312696056
 
 

 ##########
 File path: source/adminguide/accounts.rst
 ##########
 @@ -279,17 +279,99 @@ or ApacheDS to authenticate CloudStack end-users. CloudStack will search
 the external LDAP directory tree starting at a specified base directory
 and gets user info such as first name, last name, email and username.
 
-Starting with CloudStack 4.11, an ldap connection per domain can be
-defined.
+Starting with CloudStack 4.11, an LDAP connection per domain can be
+defined. In this domain autosync per account can be configured,
+keeping the users in the domain up to date with their group membership
+in LDAP.
+.. Note:: A caveat with this is that ApacheDS does not yet support the
+virtual 'memberOf' attribute needed to check if a user moved to
+another account. Microsoft AD and OpenLDAP as well as OpenDJ do support
+this. It is a planned feature for ApacheDS that can be tracked in
+https://issues.apache.org/jira/browse/DIRSERVER-1844.
+
+There are now three ways to link LDAP users to CloudStack users. These
+three ways where developed as extensions on top of each other.
+
+To authenticate, in all three cases username and password entered by
+the user are used.
+
+#. manual import. A user is explicitely mapped to a domain/account
+   and created as a user in that account
+
+       #. CloudStack does a search for a user with the given username.
+
+       #. If it exists, it checks if the user is enabled
+
+       #. if the user is enabled, CloudStack searches for it in LDAP
+          by the configured 'ldap.username.attribute'.
+
+       #. if the LDAP user is found, CloudStack does a bind request
+          with the returned principal for that LDAP user and the
+          entered password.
+
+       #. the authentication result from LAP is honoured.
+
+#. autoimport. A domain is configured to import any user if it does
+   not yet exist in that domain. For these users a account by the same
+   name as the user is created on the fly and the user is created in
+   that account.
+
+       #. If the domain is configured to be used with LDAP,
+
+       #. CloudStack searches for it in LDAP by the configured
+          'ldap.username.attribute'.
+
+       #. if an LDAP user is found is found, CloudStack does a bind
+          request with the returned principal for that LDAP user and
+          the entered password.
+
+       #. If LDAP authentication checks out, CloudStack checks if the
+          authenticated user exists in the domain it they try to log
+          on to.
+
+          #. If it exists it is ensured to be enabled
 
 Review comment:
   I think "it" should be "the user account" to make it clearer what it refers to.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message