LDAP queries in general should not be "contains" or "starts with" or "like". I'm getting whacked by my administrator because the crowd queries are needlessly complex and are all "contains" - i.e. ray_harrison. The system should really default to equals (i.e. exact match) and provide the ability to customize how they are done. Also, there is no need at all to force an object class search. As an example - in Active Directory, all you should have to do is search for sAMAccountName=

      {input user}

      with nothing else needed. Unfortunately, I will have to default to the internal LDAP mechanisms in your other products until this can be worked through - great concept though!

            [CWD-1318] LDAP Directory Queries "Contains" Causes Issues

            Great to hear

            For future reference - if you want queries answered promptly, it's best to open a support request at http://support.atlassian.com. The workflow there means that your query stays front-and-center until it's resolved.

            Cheers,
            Dave.

            David O'Flynn [Atlassian] added a comment - Great to hear For future reference - if you want queries answered promptly, it's best to open a support request at http://support.atlassian.com . The workflow there means that your query stays front-and-center until it's resolved. Cheers, Dave.

            RayH added a comment -

            Dave,
            I finally "Got a Clue" and RTFM and now better understand much more about what I want to to with Crowd (delegated authentication). I do still think that a search shouldn't be "contains" unless specified, but I no longer am experiencing the issues I was because of how I now have it set up. So lets close this out and let me go get our finance folks in gear for a PO and a check to Atlassian.

            Cheers
            Ray

            RayH added a comment - Dave, I finally "Got a Clue" and RTFM and now better understand much more about what I want to to with Crowd (delegated authentication). I do still think that a search shouldn't be "contains" unless specified, but I no longer am experiencing the issues I was because of how I now have it set up. So lets close this out and let me go get our finance folks in gear for a PO and a check to Atlassian. Cheers Ray

            RayH added a comment -

            Hi Dave!
            On our particular AD instance here at Comcast, the indexes aren't being hit at all. Here's the query from the log:
            2008-11-17 16:26:23,691 http-48095-Processor24 INFO [integration.directory.connector.MicrosoftActiveDirectory] Performing principal search: baseDN = dc=myorg,dc=mycable,dc=com - filter = (&(sAMAccountName=*user_name*)(objectClass=Person))

            We receive a

            LDAP: error code 3 - Timelimit Exceeded]; nested exception is javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timelimit Exceeded]; remaining name 'dc=myorg,dc=mycable,dc=com'

            Whereas if we just search on sAMAccountName=user_name, the result is instantaneous. I have little input with the AD team here - even if I promise a free t-shirt and we have to work with their setup, unfortunately. Is it possible for a user to modify the search query to be "equals" or is that hard-wired? I've looked all over but can't find the information in either a file or the DB (we're using mysql for crowd). A recommendation (and this is from me - we use directories extensively here at Comcast so I read/write from them all the time in applications - and no t-shirt required ) is to keep the search simple and specific. So if you need the object returned by sAMAccountName, then let that be the search attribute. If there is a requirement to do a "contains", make it an optional checkbox or something.

            Right now, we utilize the individual LDAP functionality of each of the Atlassian tools - somewhat tedious to maintain - and it would be terrific if we could utilize crowd.

            RayH added a comment - Hi Dave! On our particular AD instance here at Comcast, the indexes aren't being hit at all. Here's the query from the log: 2008-11-17 16:26:23,691 http-48095-Processor24 INFO [integration.directory.connector.MicrosoftActiveDirectory] Performing principal search: baseDN = dc=myorg,dc=mycable,dc=com - filter = (&(sAMAccountName=*user_name*)(objectClass=Person)) We receive a LDAP: error code 3 - Timelimit Exceeded]; nested exception is javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timelimit Exceeded] ; remaining name 'dc=myorg,dc=mycable,dc=com' Whereas if we just search on sAMAccountName=user_name, the result is instantaneous. I have little input with the AD team here - even if I promise a free t-shirt and we have to work with their setup, unfortunately. Is it possible for a user to modify the search query to be "equals" or is that hard-wired? I've looked all over but can't find the information in either a file or the DB (we're using mysql for crowd). A recommendation (and this is from me - we use directories extensively here at Comcast so I read/write from them all the time in applications - and no t-shirt required ) is to keep the search simple and specific. So if you need the object returned by sAMAccountName, then let that be the search attribute. If there is a requirement to do a "contains", make it an optional checkbox or something. Right now, we utilize the individual LDAP functionality of each of the Atlassian tools - somewhat tedious to maintain - and it would be terrific if we could utilize crowd.

            Hi Ray,

            Crowd uses "contains" queries when searching for users. When directly looking up a known user for authentication or similar, Crowd uses (&(sAMAccountName=ray_harrison)(objectClass=Person)). On our test AD instance I checked that it was hitting the same indexes as a straight (sAMAccountName=ray_harrison) query. However, we're not full-time AD admins, so we are happy to take advice from one, especially if it makes Crowd faster

            So, please ask your administrator how (s)he thinks we should be querying AD for most efficient results. We'll send him/her a Crowd t-shirt for their trouble.

            Regards,
            Dave.

            David O'Flynn [Atlassian] added a comment - Hi Ray, Crowd uses "contains" queries when searching for users. When directly looking up a known user for authentication or similar, Crowd uses (&(sAMAccountName=ray_harrison)(objectClass=Person)) . On our test AD instance I checked that it was hitting the same indexes as a straight (sAMAccountName=ray_harrison) query. However, we're not full-time AD admins, so we are happy to take advice from one, especially if it makes Crowd faster So, please ask your administrator how (s)he thinks we should be querying AD for most efficient results. We'll send him/her a Crowd t-shirt for their trouble. Regards, Dave.

              doflynn David O'Flynn [Atlassian]
              ray_harrison RayH
              Affected customers:
              0 This affects my team
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: