Sorry Leon!

Thanks Adrian, I will contact them.

Hi Diego,

If you contact our support team ( http://support.atlassian.com/ ), they'll be happy to investigate the issue you're experiencing.

Regards,
Adrian

Hello Diego,

I hope Atlassian developers could provide you with more information.
I'm not a part of Atlassian team

Cheers,
Leon

Hi Leon,

I was just wondering if the issue I reported in my previous comment will be fixed in a future version of Confluence?

Thanks,

Diego.

Hi Leon,

I'm not sure if it is the same issue. For us we can mix internal and external groups with no issues, the only problem we saw was when the group was pre-populated then the user would not be synced inside Confluence.

Cheers,

Diego.

Hello Diego,

Could it be connected to this CROWD issue - https://jira.atlassian.com/browse/CWD-2135 ?
Since Confluence is using CROWD modules to authenticate users against different directories,
I see resolution of https://jira.atlassian.com/browse/CWD-2135 issue a paramount!!!

It will allow to mix internal groups (created in internal directory) and LDAP groups pulled from external directories for those users.

This feature was available in CROWD up to ver. 2.0.7 I believe, and needs to come back for Confluence and Crowd backwards compatibility.

Someone from Atlassian team are welcomed to reply on this and provide some feedback/timetable?

Thanks,
Leon

Hello,

Thank you for implemeting these changes. I would like to report one issue that we are seeing. When the Confluence admin creates a group, that the user belongs to, in advance and then the user logs in the user is not then added to the group.

I noticed that the admin is forced to add the group in lowercase but the groups that are added automatically are upper case. Is there a reason for this limitation when the groups are created manually?

Thanks,

Diego.

This is how LDAP integration would be helpful to us:

1. A new user logs in using LDAP credentials. Confluence would look for this user's groups in LDAP and if they don't exist then the groups would get created and the user would get assigned to the groups (on the fly - no syncing). If the groups exist then the user just gets added to them.

2. If an existing user logs in and he was previously part of group X, in Confluence, but that user does not have the group affiliation in LDAP anymore then the user would be removed from that group in Confluence but the group would be left intact.

3. Ideally Confluence could distinguish between LDAP created groups and admin created groups so that users are never automatically removed in the latter case.

4. A nice to have would be the ability of Confluence to go into the LDAP tree and prepopulate with all existing groups (optionally populating users) and/or allow for manual creation of LDAP groups for the purpose of creating ACLs in advance of users login in.

Please see comment here - https://jira.atlassian.com/browse/CONF-22709?focusedCommentId=253899&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253899
As it'll give you a background regarding the features needed to resolve this bug.

This requires adding a checkbox for this option and showing/hiding the group & membership mapping configuration to the 'Internal with LDAP auth' (Delegated LDAP) configuration screen. This information needs to be persisted, and the necessary logic added to the authentication process in the delegated LDAP directory implementation.