Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 1 subscriber
  • Views 9273 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

Problems with eDirectory SSO

dspender
We've had mounting problems with edirectory sso over the last few months. I would say ever since the 7.5 update which we did over Christmas break.

At first it was just a few users saying that they would get prompted for manual authentication then it slowly escalated to just about every user having experienced it at some point.

Tonight the whole thing went meltdown.

Messages in the AUA log - tons per second repeating over and over thousands of times and no one could authenticate:

[PHP]2010:04:12-20:00:32 thetube aua[30840]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30841]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30842]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30843]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30844]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30845]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30846]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30847]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30848]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30849]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30850]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30851]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30852]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30853]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
2010:04:12-20:00:32 thetube aua[30854]: id="3006" severity="info" sys="System" sub="auth" name="Trying 10.1.1.227 (edirectory)"
 [/PHP]

We rebooted and at first it seemed to work but minutes later the same symptoms appeared. I tried entering a different LDAP server and the same symptoms occurred. The LDAP servers were both responding normally to other LDAP requests from our other systems. 

I rebooted one last time with the 2nd server active and I am still getting the 'trying' message but it seems to have calmed down for now.

Its too bad because we had similar issues to these when we first started with Astaro a couple years ago and then they seemed to be fixed with 7.3 Now we're back to where we started.

Will probably open a ticket tomorrow but wanted to see if anyone had any thoughts.


This thread was automatically locked due to age.
Parents
  • 0
    RConnelly, Are you certian that the issue is 7.506 and not a recent IPS pattern update?  Do you see anything suspicious in the IPS log?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi

    eDirectory SSO authentication has not been touched in a while.  Authentication
    problems are likely to come from elsewhere.

    I see a lot of different Problems with different versions in this thread, so I
    will try to sort it out:

    starfish4711 | Kingbuzzo:


    You are running version 7.505 (?)

    What are your exact symptoms? 
    I assume your users receive browser popups, although they should be logged in
    via SSO.

    You say that aua.log does not show any authentication failures, except those
    who should fail.  This seems to indicate a httpproxy problem.  Can you check
    http.log for any obvious failures?

    As BAlfson already suggested: Can you also check ips.log for any obvious
    problems?



    RConnelly:


    You ran 7.505 without problems, but after upgrade to 7.506 things started to
    do what?
    I assume your users receive browser popup message for authentication although
    they should be logged in via SSO.

    When you were running SSO, did you see anything obvious in the aua.log?
    Obvious things to look for are:


    •  messages stating that connection to edirectory failed
    •  messages from process 'aua_edirsync' stating that sync finished should appear regularly. Something like "Sync complete at ... took 1s"
    •  Failed SSO authentication attempts. Those request have the users ip address as username



    dspender


    What version are you running now and does the problem still exist?

    the original error messages you saw were from the authentication daemon, and
    not from the process that syncs edirectory (aua_edirsync). Do you see the
    aua_edirsync script in your log at all?

    I am really sorry to admit it, but the only word I have for this is 'weired'.

    About the 'Maximum Child cound reached' messages: Do those still appear?
    Does/Did it appear when you had a lot of load, or at random times? Did the
    original messages (Trying ...) go away then?

Reply
  • 0 in reply to BAlfson
    Hi

    eDirectory SSO authentication has not been touched in a while.  Authentication
    problems are likely to come from elsewhere.

    I see a lot of different Problems with different versions in this thread, so I
    will try to sort it out:

    starfish4711 | Kingbuzzo:


    You are running version 7.505 (?)

    What are your exact symptoms? 
    I assume your users receive browser popups, although they should be logged in
    via SSO.

    You say that aua.log does not show any authentication failures, except those
    who should fail.  This seems to indicate a httpproxy problem.  Can you check
    http.log for any obvious failures?

    As BAlfson already suggested: Can you also check ips.log for any obvious
    problems?



    RConnelly:


    You ran 7.505 without problems, but after upgrade to 7.506 things started to
    do what?
    I assume your users receive browser popup message for authentication although
    they should be logged in via SSO.

    When you were running SSO, did you see anything obvious in the aua.log?
    Obvious things to look for are:


    •  messages stating that connection to edirectory failed
    •  messages from process 'aua_edirsync' stating that sync finished should appear regularly. Something like "Sync complete at ... took 1s"
    •  Failed SSO authentication attempts. Those request have the users ip address as username



    dspender


    What version are you running now and does the problem still exist?

    the original error messages you saw were from the authentication daemon, and
    not from the process that syncs edirectory (aua_edirsync). Do you see the
    aua_edirsync script in your log at all?

    I am really sorry to admit it, but the only word I have for this is 'weired'.

    About the 'Maximum Child cound reached' messages: Do those still appear?
    Does/Did it appear when you had a lot of load, or at random times? Did the
    original messages (Trying ...) go away then?

Children
  • 0 in reply to rleibl
    An Update:

    I was on vacation for a couple weeks, swamped with work upon returning. Finally getting a chance to look at this again.

    Got a reply from Astaro support saying basically that the problem with SSO is that the IPs are not updating correctly in the users' edirectory records. Point taken. A few recommendations to help smooth things over on the edir servers we query. I've tried them and I'm not sure if its working. It hardly matters because our two other auth issues completely overshadow SSO not working correctly.

    My initial problem with AUA barfing and locking up the server has still been unaddressed even after submitting an AUA from the server while it was in debug mode. I still have the log if anyone is interested in seeing it.
    Also we have a problem where the proxy auth box keeps popping up again and again and again after correct credentials were entered. If SSO doesn't work occasionally, that's ok, but if manual auth doesn't work either, then we are screwed.

    I'm continuing on with my ticket in the hopes to get further answers about this. In the meantime I've decided to buy another HP server and setup a second instance of Astaro for testing purposes. We have 3 dedicated internet lines and I will pull one of them off to connect up to the new box to see if we get the same auth issues.  I suspect we will. I'll report back if I hear more from Astaro or when I get the second box up and running.
  • 0 in reply to rleibl
    Hi
    dspender


    What version are you running now and does the problem still exist?

    the original error messages you saw were from the authentication daemon, and
    not from the process that syncs edirectory (aua_edirsync). Do you see the
    aua_edirsync script in your log at all?

    I am really sorry to admit it, but the only word I have for this is 'weired'.

    About the 'Maximum Child cound reached' messages: Do those still appear?
    Does/Did it appear when you had a lot of load, or at random times? Did the
    original messages (Trying ...) go away then?



    We are currently running 7.504

    I do see the aua_edirsync script appearing in the log and it runs successfully. I see usernames and IPs coming across and being updated.

    I so still have 'maximum child count reached' appear regularly. It does seem to be related to load - usually when the same user is spamming auth requests for some reason. I've attached an example. 'Trying...' always seems to appear before each auth request.

    Thank you for looking into this!