Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 1 subscriber
  • Views 9287 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.
  • 0
    Well I created a ticket which is about as helpful as decaf coffee.

    I detailed the ticket my issue with times, dates, and usernames for when I found a specific issue was occurring and attached the aua.log along with the ticket title being "Repeated Proxy Requests with eDirectory SSO".

    I get a response a day later asking what sso method I'm using and if I could give him a specific example of the problem with date time and username along with the aua.log. /facepalm

    So responded to all that and provided more logs and even a second example and now that its 36 hours later I've had NO RESPONSE. In the meantime the authentication daemon went into meltdown again (see original post) at 1am this morning until I rebooted the Astaro at 7:30am.

    I don't usually have to create too many tickets - is Astaro support usually this horrible?
  • 0
    Just for anyone else who might have this problem.... here's my latest findings:

    Username: username
    IP: 10.xx.xx.xx
    Time: 10:18:34 - 10:19:51
     
    At 10:18:34 I attempted to browse to [a website] and was prompted for manual authentication. Upon entering my Username and Password the site partially came up but I was prompted again for my credentials. I entered them and was prompted again and again - probably about 10 times. You can see in the HTTP log (looking at the timestamps) that it was giving me a small piece of the website each time I entered my credentials successfully. Yet there is not an entry beyond the first authentication in the AUA log.
     
    After 10 times of entering my credentials, I clicked Cancel on the box until it went away and as you can see from the timestamps on the HTTP log, at that point the entire site flew onto my screen.
     

    Attached to the ticket was an AUA log showing only two entries for 'username' at 10:18:34 and no other entries for 'username'. 
    Attached was the HTTP log to show how the site loads in a staggered manner and then all at once after cancel is pressed repeatedly

    Sadly I cannot attach anything here because the file size limit is 19k [:S]

    "Your file of 39.0 KB bytes exceeds the forum's limit of 19.5 KB for this filetype." [:S][:S]
  • 0 in reply to dspender
    Getting alot of the following in the AUA log. No idea what it means but after a reboot we don't get this message at all and then it slowly starts to appear perhaps until the daemon dies? Just a guess....

    [PHP]2010:04:15-13:03:09 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:09 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:10 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:10 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:10 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:10 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." 
    2010:04:15-13:03:10 thetube aua[3292]: id="3006" severity="info" sys="System" sub="auth" name="Maximum child count reached. Waiting for children to exit." [/PHP]

    Still no word from Astaro so I'm just pressing buttons at this point hoping I figure something out. I could have sworn I paid for support when I bought the thing... [8-)]
  • 0 in reply to dspender
    I haven't seen that error, but have two questions and some comments...

    1) When the other servers authenticate LDAP requests, are they using the same userID as the Astaro does? If not, can you use the Astaro credentials sucessfully on another box?

    2) You said that you are able to authenticate using the Astaro logon requestor. Is the Astaro authenticating you on a one-off basis against LDAP, or against cached credentials?

    3) When we have logon requestor issues, it is often caused by an EDirectory issue - the users do not have a Network Address assigned to them on their environment tab. (IManager > Modify User > [Select User] > General Tab > Environment Tab > Network Address

    4) Try a packet capture from the console of the Astaro box:
    ssh to Astaro and su to root
    tcpdump -i eth0 host 10.1.1.127 (or whatever your internal NIC is)
  • 0 in reply to MisterAG
    I haven't seen that error, but have two questions and some comments...


    Thanks, nothing from Astaro support yet, so I appreciate it.

    1) When the other servers authenticate LDAP requests, are they using the same userID as the Astaro does? If not, can you use the Astaro credentials sucessfully on another box?


    Yes. We use the same credentials (in part thanks to IDM) for every form of authentication on campus. We also authenticate wireless via RADIUS to the same LDAP server the Astaro hits. Its working fine.

    2) You said that you are able to authenticate using the Astaro logon requestor. Is the Astaro authenticating you on a one-off basis against LDAP, or against cached credentials?


    We employ eDirectory SSO - when it works - otherwise the Astaro queries the LDAP server for each initial auth and then seems to cache it for subsequent tries ( which I assume, since I never see entries in the AUA.LOG for a 2nd,3rd and following successful attempts)

    3) When we have logon requestor issues, it is often caused by an EDirectory issue - the users do not have a Network Address assigned to them on their environment tab. (IManager > Modify User > [Select User] > General Tab > Environment Tab > Network Address


    I've read this too, but what I haven't read is HOW to fix it. We have some users with IPs in the field that don't even exist on the network. I'm sure this is key to our SSO issues and I would appreciate any feedback, but we're trying to get manual auth to work correctly first [:D]


    4) Try a packet capture from the console of the Astaro box:
    ssh to Astaro and su to root
    tcpdump -i eth0 host 10.1.1.127 (or whatever your internal NIC is)

    [/QUOTE]

    I mirror the Astaro private port and capture traffic that way. I suppose it probably would be best to do it directly on the box but I try not to mess with the Astaro console too much. Still I'll give it try. Thanks.
  • 0 in reply to dspender
    I am having the same problem, which has been since the first of the year as well. I have had 7.5 for longer, it seems to be a more recent patch. We currently have 7.504

    I too have added more LDAP servers to the list, and switched them around with no luck.

    MisterAG - this occurs with no warning. I am watching the live log now of the user authentication. Our license allows for unlimited users. Basically a user will be logged in and authenticated, then while using the Internet (already having been browsing, or whatever) a new proxy authentication dialog box opens. Sometimes it takes several tries to get it to go away, and while it is happening the live log displays the "Maximum child count reached." error. After a few minutes it just goes back to normal.

    I'm going to try to set up the prefetch, to see if it might be too many users authenticating at once, though our user schedule really hasn't changed, and it still occurs during off-peak times.
  • 0
    nexus: I don't have prefetch setup either... let me know how that turns out.

    Support finally got back to me -----

    " there is a lot
    going on to cause failure.  Here are the messages that shouldn't appear on a
    healthy system:
    "More then two logins: can't resolve conflict"
    "could not set object for Wrig1130: ALREADY_IN_USE_OBJECT" followed by:
    "failed to set object"
    "Maximum child count reached. Waiting for children to exit." 

    These messages imply that the system was unable to process the amount of logins
    that were requested.  As such prompts would be shown to the user and in some cases
    where these messages appear the system may not even be able to query the eDir
    server from these prompts."

    Meh.

    I had added a few eDir servers but I still get those messages. What's more disconcerting are the multiple prompts for auth with none but the initial auth appearing in the aua.log. Support's gonna setup debug and look at some stuff in the system. I'll let you know how it turns out.
  • 0 in reply to dspender
    Thanks. I will let you know what I find out as well, as well as send this to support. I think this is more than invalid settings, since it took place after a patch (I did not change any settings).
  • 0 in reply to nexustechus
    Post #3 here: resolved my issues:https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/44370

    I did the same thing. Over Christmas updated to 7.5 started having authentication issues, the popups to login.

    I did not see what Novell versions you were  using. I am using OES2 Linux. I still have 1 netware 6.5 box, but do not authenticate against it.

    Maybe the above link will help you. Seems Ataro 7.5 is more strict on the authentication.

    M
  • 0
    Thanks mgh, I will check those settings out right away. We are using OES2 primarily to authenticate.