If there is an LDAP user with the same username as your administrator account, you must now use their password to login. LDAP logins override internal logins.
To login, the user must be a member of one or more groups that have been granted 'Can Use' permission from the Administration -> Global Permissions -> Group Permissions.
Your atlassian.xml file may contain filters with characters that must be escaped from XML. Check here for details.
If you see an error: "org.apache.velocity.exception.MethodInvocationException: Invocation of method 'isUserDeactivated' in class com.atlassian.confluence.user.actions.ViewUserAction threw exception class java.lang.NullPointerException : null"
You should open \confluence\WEB-INF\classes\atlassian-user.xml and check that your Hibernate Repository is not wrapped in a comment tag (<!-- and -->). The line to uncomment is: <hibernate name="Hibernate Repository" key="hibernateRepository" description="Hibernate Repository" />
Are your users or groups located in subtrees beneath the directory returned by the search filter? If so, you may need to add <usersearchalldepths>TRUE</usersearchalldepths> or <groupsearchalldepths>TRUE</groupsearchalldepths> to your atlassian-user.xml See Map LDAP Users and Groups for details.
Is the group in a subtree? If so, you will need to edit atlassian-user.xml and add a groupSearchAllDepths=true parameter to the LDAP repository to set Confluence to search subtrees of the base group namespace. See Map LDAP Users and Groups for details.
All LDAP users with 'Can Use' permission can be viewed from the user browser, even if they have never logged in. When an LDAP user logs in for the first time, a Confluence user account is created automatically to store their information. You have read-only access to LDAP groups, and can add/remove Confluence internal groups to any user.
Your user count is determined by the number of internal users plus the number of LDAP users who can potentially login. LDAP users that are a member of an LDAP group with 'Can Use' permission granted in Confluence can all potentially login, which means that all members of groups with this permission granted will be counted towards your license. To manage your license usage, only grant login permission to AD groups where all members need accounts. You may like to setup a special confluence LDAP group if no combination of your existing groups is suitable.
Users are not deleted from Confluence, but their logins are disabled within one hour as they expire in the cache. Only non-LDAP groups are retained. Refer to the overview for more detail.
LDAP groups or users granted 'Can Use' permission under 'Global Permissions' can login to Confluence.
Yes.
The LDAP login has priority over the Confluence login. If LDAP 'Can Use' permission is removed or the user is deleted, the Confluence login will still work.
As mentioned above, LDAP login has priority over the confluence login; however only the password is taken into account here. You can log in with either the lowercase or UPPERCASE username.
Active Directory Questions
No, Confluence has no group types. However, you can configure Confluence to only recognise some of these groups over others. For example, you can configure Confluence to only recognise distribution groups. this is done by adjusting the groupSearchFilter in your atlassian-user.xml file.
Yes, you can do this by configuring multiple repositories: one for each domain. More instructions on how to do this can be found here: http://confluence.atlassian.com/x/AgDUAg
Yes.
No, each child group must be individually specified instead. You may wish to vote towards support for nested groups at CONF-6755.
Domino LDAP Questions
Domino servers allow user groups to be set as 'mail-only', 'access control' and 'multi-purpose'. If the groups are set to 'mail-only', when Confluence queries the Domino LDAP server about a given user, Domino will return null. Groups that are created as 'multi-purpose' seem to work fine.