cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [cloudstack-documentation] DaanHoogland commented on a change in pull request #67: short description of the evolution of LDAP bindings
Date Fri, 09 Aug 2019 17:06:32 GMT
DaanHoogland 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_r312570065
 
 

 ##########
 File path: source/adminguide/accounts.rst
 ##########
 @@ -279,17 +279,63 @@ 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 confirgured,
+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. MicrosoftAD 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 estensions to each other.
+
+#. manual import. A user is explicitely mapped to a daomain/account
+   and created as a user in that account
+
+     To authenticate, username and password entered by the user are
+     used.  Cloudstack does a search for a user with the given
+     username. If it exists, it does a bind request with DN and
+     password.
+
+#. 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.
+
+     To authenticate, domain, username and password entered by the
+     user are used.  If the domain is configured to be used with LDAP,
+     Cloudstack does a bind request with DN and password. If it exists
+     and authenticates it checks if a user with the given username
+     exists. If it doesn't exists, a account/user will be created with
+     the username as names for both account and user.
+
+#. autosync. A domain is configured to use a LDAP server and in this
+   domain a number of accounts are 'mapped' against LDAP-groups. Any
+   user that is in one of thos accounts will be checked against the
+   current state of LDAP and if they exist they will be asserted to be
+   in the right account according to their LDAP-group. If they do not
+   exist in LDAP they will be disabled in cloudstack.
+
+     To authenticate, domain, username and password entered by the
+     user are used. If the domain is configured to be used by LDAP,
+     Cloudstack does a bind request with DNv and password. If it
 
 Review comment:
   this is a c&p error. the old text was 'DN and password' and I think it should be CN.


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