sometimes (not always) we have a problem with the login of ldap users. I do not know whether that is caused by GA Services or our LDAP server system.
So I ask here :-)
If some user login the timeout error "UnexpectedLoginException: LDAPSearchException(resultCode=85 (timeout)" appears (with a long waiting time) - Not always but 40% of all logins.
If repeat the login or cancel waiting time and then repeat (refresh) login it works immediately. Also test login at ldap configuration works all the time.
We have a synchronization tool for our windows clients where the "My documents" folder is automaticly mirrored and synchronized to an shared server folder.
The left side of the web clients java applet need 2 min to show the folder tree. Any idea for reasons? Or is there a possibility to change or save the start folder for the enhanced java applet?
Thank you in advance
Some Questions about your 2 problems...
What type of LDAP Server is it? Do you have the ability to monitor the load on your LDAP Server? What is the network configuration of the LDAP Server in relation to the GoAnywhere Services Server? If you restart GoAnywhere Services, does this occur right away or does it occur after some time being active? Can you send us the exception from the log file? Also, can we get the configuration values of your LDAP Login Method?
Different LDAP Servers have different settings as far as Max Connections, Max Active Queries, Max Connection idle time, etc...
If we can get this information, we can further research your first problem and help you find a solution for this.
How many files/folders exist in the "My Documents" folder? If this folder has many files and folders then it will take longer to load within the applet.
Lead Solutions Consultant
I had to collect some information about the problem and it is not so easy, because the LDAP server are far away and managed by other departments of our big firma...
But first - in this moment I tried to login into webclient and got the timeout error. Then I make only a browser refresh and I'm in my user area without login again!
Second - the problem seems to occur if the user use the lower case user name. Not always but almost always.
Here some technical informations:
LDAP server: sun server with solaris 10 sparc, soft Sun Directory Server 184.108.40.206.0 ,
I have not the ability to monitor the load on our LDAP Server but the guys from the operation service check the logs and can't find this failed login connections. The LDAP server is within our local network. We have try x times of telnet connections between the machines without any network problems.
I attached the log (only login) from june. So you can see the issues. I'll attache some LDAP config screen shots too. A restart eamination is not possible - it is a production platform and the change management wouldn't agree to restart GA :-) again and again
So I hope we found this little bug elsewhere..
I've tested some accounts again and the suspicion is more and more probable that it has to do with case-sensitive login user string.
The error occurs only if the user login is in lower case letters. It is repeatable but....not always.
Maybe the browser cache plays a role or...don't know.
After reviewing, the first question that comes up is how many Person Entries do you have under the o=WIW base DN? If this contains numerous entries (even disabled ones) this might tend to lean more toward a more refined definition for identifying the Persons that need authenticated.
Lead Solutions Consultant
I don't know the exact number yet, but 30.000 or 40.000 entries are possible. To reduce the browsed entries or filter we need additional attributes, right? That is going to be difficult, because the user are a bunch of different people. But we will see, I've contacted some colleagues.
I've no good news. I've put a second entry in the DN field (the tip I've got from one of the LDAP guys). Yesterday we've upgraded to the newest GA versions.
But nothing helps. Each time I test it and, if I think it works well. the error occurs.
Sometimes the user logins work without problems, sometime not - without unforeseeable reasons.
I'll check the new websso possibilities, but it is unsatisfactorily... Have you any other idea?
Thanks and Have a good day!
If I am looking at the CSV you provided and the images correctly the authentications that return the timeout are all taking over 300,000ms to complete. The Read Timeout in your LDAP settings is set to 300, Have you tried to increase this to see if it improves or if it has the same issue.