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
    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
    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.
Reply
  • 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.
Children
  • 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.