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_r312696320
########## 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 + + #. if it doesn't exist it is created in a new account with + the username as names for both account and user. + + #. In case authentication fails the user will be disabled in + cloudstack after the configured + 'incorrect.login.attempts.allowed' number of attempts. + +#. 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 these configured 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. + + #. If the domain is configured to be used by LDAP. Review comment: I think you should also put a comma at the end here. It's a bit confusing with the full stop. ---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
