How do I add an external directory LDAP user to confluence?

[Deleted user]

How do I pre-populate LDAP users to Confluence?

It _seems_ based on what I've read that any valid external directory user can log in to Confluence, but I can't find this specific answer anywhere in the documentation. (edit) I found the setting "Copy User on First Login" and it is enabled, so any LDAP user can log in to our Confluence instance. However, our LDAP source has users as userIDs insead of useful names, so everything that comes across with the auto-add feature is useless. Ideally, I want to be able to pre-populate the user list with actual data when we hire a new employee instead of constantly checking and waiting for them to log in to confluence for the first time and then cleaning up the mess that the "Copy User on First Login" leaves.

Is there any trick to this?

This is extremely straightforward in JIRA where you have to explicitly add each user into JIRA and while adding each user you choose whether it is an internal directory user or external directory user. I keep expecting to see the same option in Confluence, but don't see it.

[Andrew Frayling · Accepted solution]

Hi Stephen,

It depends on how your external directory has been connected to Confluence as there are a number of different "modes" in which Confluence can use an external directory. Take a look at http://confluence.atlassian.com/display/DOC/Connecting+to+an+LDAP+Directory#ConnectingtoanLDAPDirectory-PermissionSettings which explains how an external directory can be connected as:

* Read Only - Users groups and memberships are maintained in LDAP and you cannot administer users, groups or memberships via the Confluence UI, all changes to user population have to be done in the backend LDAP server.

* Read Only with Local Groups - Users groups and memberships are maintained in LDAP, but you can add groups to the internal Confluence directory from the Confluence UI and add LDAP users to these internal groups, but you cannot add or remove users via the Confluence UI.

* Read/Write - Users groups and memberships are maintained in LDAP and you can modify users, groups and memberships via the Confluence UI, but the user used to connect to LDAP as defined in your Confluence LDAP configuration must have write access to the LDAP directory as all changes will be written directly to the LDAP directory.

You can also Configure Confluence to use an internal directory, but with LDAP authentication only - http://confluence.atlassian.com/display/DOC/Connecting+to+an+Internal+Directory+with+LDAP+Authentication - with this the users are stored in Confluence, but the password check is done against the LDAP directory rather than it being a local password. If you're using multiple directories then you may also find http://confluence.atlassian.com/display/DOC/Managing+Multiple+Directories useful.

In my experience most people use Read Only with Local Groups and all of the user management is done in LDAP, if a new user needs access to Confluence then they are added to the LDAP directory.

If you are already using LDAP with Confluence and the external user that you wish to add is in LDAP then they should just be able to use Confluence, you shouldn't have to add them via the Confluence UI. If the user is already in LDAP, but they cannot access Confluence it sounds like you may be using Internal Directory with LDAP Authentication (http://confluence.atlassian.com/display/DOC/Connecting+to+an+Internal+Directory+with+LDAP+Authentication) , but have not checked the box to "Copy User on Login". If this is the case then you can either select Administration -> User Directories and modify your Internal Directory with LDAP Authentication to check this box, or select Administration -> Manage Users and select "Add New User".

Hope that helps?

Andrew.

[Deleted user]

Thanks for the reply, and sorry for the extremely slow response. I updated my original question to hopefully clear things up a bit.

I can't find what mode our directory is in with regards to Read Only, Read Only with Local Groups, and Read/Write (I inherited the server when our previous admin moved jobs). I see in the Directory configuration Summary that it says "Type: DELEGATING" and the directory is named "Delegated LDAP Authentication." It also has "Copy User on First Login" set - so anybody from the LDAP directory can log in. I should also mention that we are using internal Confluence directory and LDAP directory authentication (in that order).

However, the problem I'm trying to avoid is that our network logins are user IDs instead of useful user names. When a new user logs in from the LDAP directory, it populates the name field with their user ID and the email field with a bogus address that is in the form of "userID@arms.local". I can't force new employees to log in to Confluence, so at this point I'm stuck manually checking the Confluence user management to see if their user ID has been logged into the system yet and then fix up the name and email on the user once they finally do log in.

Hope that more clearly explains what I'm trying to get working. In typing this out and reading the articles you linked, I'm wondering if the directories are backwards. We have internal-only users, but if we switched to having the LDAP directory first and they're not found in the directory, then I would expect Confluence to fall back on the password defined in its own database. The thing that confuses me about this is that the add user page forces me to enter a password for the user - so if they exist in the directory and it is the first authentication source, would the internal password be ignored then?

[Andrew Frayling]

Hi Stephen,

If it says "Delegated LDAP Authentication" that means you're using "Internal with LDAP Authentication".

Do you have "real" names and email addresses in LDAP? If so then the name in Confluence is just a mapping issue as you tell Confluence which LDAP attribute to use for name, email address, etc. Have a look at User Schema settings at http://confluence.atlassian.com/display/DOC/Connecting+to+an+LDAP+Directory#ConnectingtoanLDAPDirectory-UserSchemaSettings

I don't think falling back to the internal directory password is going to work as usernames have to be unique across directories, e.g. if you have a user in LDAP with a username of jbloggs that is already able to log in to Confluence then you cannot add a user to the internal directory with a username of jbloggs as well.

I think there are a couple of options to get things working the way you want:

* Fix the user mappings so that Confluence uses the correct LDAP attributes to populate name, email address, etc. and leave it as "Copy on First Login"

* Manually pre-propulate Confluence with the users using the correct names, email addresses, etc. and uncheck "Copy on First Login"

Out of those two I'd personally go for fixing the user mappings.

The other alternative is to review if "Internal with LDAP" is the best option for your environment or whether one of the read only, read with local groups or read/write is a better fit. The best fit depends on your environment, but all things being equal I tend to use read with local groups over any of the other LDAP configurations.

Hope that gets you a bit closer to how you want things configured?

Andrew.

[Deleted user]

Ok, that last comment was what I needed to put everything together.

I browsed through our LDAP directory source and, to my surprise, there is no real useful data in there as far as proper email address or first name/last name - so the current User Schema Settings are as good as it can get. This was one of the main sources of frustration for me, so at least I know the blame is on our directory instead of Confluence.

I think I'll continue with the "Copy Users on First Login" setting enabled for now and clean up the entries on a semi-regular basis. However, I'll keep in mind that I should be able to turn that setting off and then define the LDAP directory users manually if it gets to be a problem.

Thanks for the responses and helping me out!

[Andrew Frayling]

No probs. Shame LDAP's not in a better state to make your job easier.