I do think that this last comment from Atlassian should be on the first page of Confluence homepage... this days a lot. Here at Citrix we do have over 14.000 groups in Exchange and about half of them do start with pound sign. Such a Confluence install would cost over $30000, and still Atlassian is telling us that we have to rename the 14000 groups?!

Sorry, given the low interest in this bug and the low customer impact (only 3 votes in 6-7 years), we won't be able to fix it in the near term. There are a large number of issues tracked against the product, and we need to prioritise fixing those with a greater impact.

This means this limitation with how certain punctuation characters are used in Confluence in URLs and other places will continue to exist. Customers will need to work around these limitations by adjusting your external user management configuration (e.g. using a different username field) or by setting up separate accounts for affected users.

We are getting new error now that we cannot add a user with #sign in user-Id to any of confluence groups. The web page is not showing any error but the function is not working. Attached the confluence log with profiling on. May be this is helpful to fix the issue.

Hi Matt, Thanks for the update. However, I don't think the issue is with LDAP authentication. The current Issue is with the contractors having personal spaces and operating on their personal spaces. Even after the authentication is complete with LDAP, they cannot operate on their personal space. Temporarily we are resticting contractors not to have personal spaces but use public space with restrictions as needed. Appreciate if you could work on this issue at your future releases, but not ignoring it completely.

Thanks
Srinivasa

Thanks for the information, Srinivasa. I understand your situation now.

Unfortunately, this bug will be a low priority compared to our other outstanding bugs unless more users are experiencing the same problem. It will also involve a lot of investigation to resolve all the issues around hashes in usernames, which are used in URLs and other places where they will cause problems.

Until we do get around to investigating this, a short-term workaround might be to use a different field in LDAP for the Confluence login, one without hashes.

Rather than doing it for all your users, you could do this just for the contractor logins by configuring two LDAP connections in atlassian-user.xml to the same LDAP server. The first connection would be the current settings, plus a filter to exclude users with usernames that start with hashes (i.e. excluding contractors). The second connection would be a user filter for just the contractors, with a different username attribute setting.

There is documentation on how to configure multiple LDAP repositories here:

http://confluence.atlassian.com/display/DOC/Configuring+multiple+LDAP+repositories

Configuring the relevant LDAP filters is something you should be able to find documentation for on the internet. We don't currently cover this in detail in our manual.

Hi Matt,
It is corporate policy to distinguish contractors with full/part time employees. All contractor network-ids have '#' at the start while employees don't.
This policy is in place for a long time.

Hence the LDAP server has these user-Ids in it.

Usernames with hash signs (Australian for "pound sign") in them is something we haven't come across before. It might break a few different things aside from space permissions.

Why do you have these unusual user names in your LDAP server, Srinivasa?

Just to add more about the environment that we had....
1)Database: Microsoft SQL server
2)User Authentication : LDAP without groups
3)sample userId(networkId): #micky
4) Activity that was failing before the major issue is Adding labels to pages in personal space etc.