I'm integrating Bamboo with Active Directory, and found that after the initial bind operation bamboo performs a search using the filter specified in <userSearchFilter> from atlassian-user-custom.xml, BUT on the LDAP searchrequest the filter is modified:
- the file specifies <userSearchFilter>(objectClass=user)</userSearchFilter>
- the operation shows (&(objectClass=user)(sAMAccountName=anonymousUser))
Since there is no account called anonymousUser (and is not the user that is trying the login) the search operation returns with zero values, and the login is rejected. If I try Paddle with the atlassian-user-custom.xml file, the search DOES use the filter specified in the XML file.
Why does bamboo add an extra filter if paddle doesn't? This defeats the purpose of using paddle for testing, if bamboo modifies the search. Also, how can I stop bamboo from adding that "sAMAccountName=anonymousUse" filter? Because of that no domain user can login, while paddle shows that everything is working.
Hello @Nicolas Vila,
What do you have as <
usernameAttribute> in "atlassian-user-custom.xml"?
If I try Paddle with the atlassian-user-custom.xml file, the search DOES use the filter specified in the XML file.
Paddle runs against "atlassian-user.xml" and you should expect two tests as result (reference How to set up LDAP in Bamboo):
TEST 1: Search and list XXX users
TEST 2: Search and list XXX groups
Which result are you getting from Paddle?
Regarding on the search filter, if you are connecting to Windows Active Directory, you should consider updating your search filter to https://msdn.microsoft.com/en-us/library/ms677643(v=vs.85).aspx
If possible, please raise a support case (https://support.atlassian.com) so we can review "atlassian-user-custom.xml", paddle's output and Bamboo logs.
First let me tell you that I made it work. For username attribute i have:
I was renaming the XML file for paddle to find it, and it was in fact finding all users and groups. As for the search filter, I modified for the following:
Once I did that, now I see on the packet capture that the search uses the following filter:
where johndoe is the username tried in the login. The searchfilter looks a little strange but nevertheless it's working.