Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1038 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange SSO eDir behavior

KWATTS
I have found a performance issue that needs to be addressed.  It deals with eDir SSO when asa resorts to a username lookup.  Users who are not logged into Novell are MUCH slower than a user that has logged in.  We are currently evaulating Asatro as a replacement for our current firewalls.  This bug renders the proxy unbearably slow. 

Here is what I see: 

The non-Novell user tries a website and gets challenged with a Basic-auth login.  They are able to login with their eDir username and password.  The log shows that SSO is still trying to authenticate by SSO lookup for EACH AND EVERY object on the webpage.   

Here's a log snippet: 

2006:07:27-15:57:32 (none) aua[5724]: getAuthenticationByIP() eDirectory SSO Auth failed - no user found in eDir for IP: 10.12.32.56
2006:07:27-15:57:32 (none) aua[5724]: do_auth_edir() eDirectory Authentication failed - user '10.12.32.56' or password not valid
2006:07:27-15:57:32 (none) aua[5724]: U:10.12.32.56 F:http R[[[[:D]]]]ENIED C:edir
2006:07:27-15:57:32 (none) aua[2643]: U:kmw01 F:http R[:$]K [] C:cached
2006:07:27-15:57:34 (none) aua[5726]: getAuthenticationByIP() eDirectory SSO Auth failed - no user found in eDir for IP: 10.12.32.56
2006:07:27-15:57:34 (none) aua[5726]: do_auth_edir() eDirectory Authentication failed - user '10.12.32.56' or password not valid
2006:07:27-15:57:34 (none) aua[5726]: U:10.12.32.56 F:http R[[[[:D]]]]ENIED C:edir
2006:07:27-15:57:35 (none) aua[2643]: U:kmw01 F:http R[:$]K [] C:cached
2006:07:27-15:57:36 (none) aua[5731]: getAuthenticationByIP() eDirectory SSO Auth failed - no user found in eDir for IP: 10.12.32.56
2006:07:27-15:57:36 (none) aua[5731]: do_auth_edir() eDirectory Authentication failed - user '10.12.32.56' or password not valid
2006:07:27-15:57:36 (none) aua[5731]: U:10.12.32.56 F:http R[[[[:D]]]]ENIED C:edir
2006:07:27-15:57:37 (none) aua[2643]: U:kmw01 F:http R[:$]K [] C:cached
2006:07:27-15:57:39 (none) aua[5732]: getAuthenticationByIP() eDirectory SSO Auth failed - no user found in eDir for IP: 10.12.32.56
2006:07:27-15:57:39 (none) aua[5732]: do_auth_edir() eDirectory Authentication failed - user '10.12.32.56' or password not valid
2006:07:27-15:57:39 (none) aua[5732]: U:10.12.32.56 F:http R[[[[:D]]]]ENIED C:edir
2006:07:27-15:57:40 (none) aua[2643]: U:kmw01 F:http R[:$]K [] C:cached

You get the idea.   

Now here is a snippet from the same workstation after Novell Login: 

2006:07:27-15:59:12 (none) aua[5804]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-15:59:18 (none) aua[5805]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-15:59:21 (none) aua[5797]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-15:59:24 (none) aua[5801]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-15:59:25 (none) aua[5800]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-15:59:25 (none) aua[5803]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-16:00:00 (none) aua[5802]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-16:00:00 (none) aua[5796]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-16:00:00 (none) aua[5799]: U:10.12.32.56 F:http R[:$]K C:edir
2006:07:27-16:00:00 (none) aua[5798]: U:10.12.32.56 F:http R[:$]K C:edir 

The pages load much faster. 

This is likely a bug.  asa should not be looking for the workstation record after the user has authenticated via Basic Auth.


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to SveN_01
    That looks to be the same issue.  However, it appears that the issue only manifiests itself with SSO.  The explanation by Astaro development was that the credentials are cached for 600 secs before checking the tree again.  This is NOT the case.  If I use User authentication, then the credentials are cached and the tree is not searched.  

    I am making an open appeal to get this fixed before my eval ends.
  • 0 in reply to KWATTS
    The explanation by Astaro development was that the credentials are cached for 600 secs before checking the tree again.


    This is what they are going to change... 
    the credentials are not cached for 600 secs this time!