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

E-dir authentication problems after 7.501

martho
Can someone just please put me out of my misery? I stupidly upgraded to 7.501 and now I am hosed with authentication problems.

Specifically, the Astaro system tests fine with my e-dir server, both at server level and user level tests. But when I connect from a client computer I get the dreaded username/password prompt, repeatedly. If I hit cancel, it goes to the astaro error screen indicating authentication failure, yet while watching the live authentication log there is no indication of an authentication attempt. If I do log in, that only works for that app instance. Launch IE instead of Firefox and I get the auth errors again. I have rebooted my computer, looked at the astaro config, retested the e-dir connection, verified no errors using dsrepair in the e-dir, and still this goes on. Basically, the new version of astaro is too stupid to figure out that I am logged in and present in the e-dir tree, and some bonehead took out the logging functionality as well. In previous examples of this sort of problem at least I had the joy of seeing in the astaro log that it intentionally rejected me. Now it rejects me at the client level but has no record of it on the firewall, probably assuming that without the records it cannot be found guilty.

Any ideas?


This thread was automatically locked due to age.
  • 0
    From the logs...

    HTTP Access log
    2009:12:09-09:54:40 shl-gtwy httpproxy[3125]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.200.189" user="" statuscode="407" cached="0" profile="REF_gJiSHTkZXo (SHL Network)" filteraction=" ()" size="2606" time="0 ms" request="0xb296b738" url="updates.installshield.com/GetMessages.asp
    2009:12:09-09:54:41 shl-gtwy httpproxy[3125]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.200.189" user="" statuscode="407" cached="0" profile="REF_gJiSHTkZXo (SHL Network)" filteraction=" ()" size="2606" time="0 ms" request="0xb296b738" url="updates.installshield.com/GetMessages.asp
    2009:12:09-09:54:42 shl-gtwy httpproxy[3125]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.200.189" user="" statuscode="407" cached="0" profile="REF_gJiSHTkZXo (SHL Network)" filteraction=" ()" size="2606" time="0 ms" request="0xb296b738" url="updates.installshield.com/GetMessages.asp
    2009:12:09-09:54:42 shl-gtwy httpproxy[3125]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.200.189" user="" statuscode="407" cached="0" profile="REF_gJiSHTkZXo (SHL Network)" filteraction=" ()" size="2606" time="0 ms" request="0xb296b738" url="updates.installshield.com/GetMessages.asp
    2009:12:09-09:54:43 shl-gtwy httpproxy[3125]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="GET" srcip="192.168.200.189" user="" statuscode="407" cached="0" profile="REF_gJiSHTkZXo (SHL Network)" filteraction=" ()" size="2606" time="0 ms" request="0xb296b738" url="updates.installshield.com/GetMessages.asp

    User Authentication log
    2009:12:09-09:54:31 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374071, took 0s"
    2009:12:09-09:54:41 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374081, took 0s"
    2009:12:09-09:54:51 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374091, took 0s"
    2009:12:09-09:55:01 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374101, took 0s"
    2009:12:09-09:55:11 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374111, took 0s"
    2009:12:09-09:55:21 shl-gtwy aua_edir_sync[3144]: id="3006" severity="info" sys="System" sub="auth" name="Sync complete at 1260374121, took 0s"

    You can see the HTTP Access dameon sees the request but doesn't know who it is from. You can also see the User Authentication dameon isn't even aware of the incident.

    I see other http requests where the user is properly associated with the request, but many are not, including mine. Why? What makes that association?
  • 0 in reply to martho
    yesh, this is a constant headache...

    try removing/re-adding the lUser from the e-Dir "internets" group...
  • 0 in reply to Kingbuzzo
    I believe they may have done some work on this issue; check out the soft-release of 7.502 ...  available at download.astaro.com or download.astaro.de .

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    It turns out the upgrade process to 7.5 is not fully baked. While the specified e-dir server is properly configured in the servers tab, the new e-dir SSO does not automatically select the e-dir server. Once the server was selected the problem was resolved.

    That was a pain in the ass. And I assume it is going to smack anyone who does the upgrade with e-dir. In my opinion they need to go back and fix the 7.500 upgrade process. We are currently at 7.501. I can't imagine how 7.502 is going to know that the 7.500 upgrade was hosed and then fix it for me.
  • 0 in reply to martho
    dang - thanks for the heads-up...
  • 0
    Yep - found the same issue here. Still occationally get the authentication box, but it was constant before we selected the eDir server
  • 0
    We actually opened a support-case with Astaro due to these problems,
    and yes,, the upgrade just goes half-way leaving a non-working setup.

    Major issue we are having, which led our customer to disable SSO is in a network with more than one office, more than one server, though still one single Tree.

    Problem for us/customer is;
    One Tree, 8 offices, each office = one Context and at least 1 server,
    issue is; User from "office x" might be at "office y" one week, and at another office another week. So, the setup with "base-dn" and one, single server for SSO has really shown it's limitations..

    We've set it up as one central group, consisting of users from all offices/context,
    this group is then required by SSO to surf and each local astaro have access to this
    from a local read/write replice no the local/most nearby server.

    But,, NOT setting base-dn for users, seems to be an issue for Astaro,
    and , with this setup, having  a base-dn doesnt work.
    2nd issue off course is to have a SINGLE server for SSO !!

    Instead of SingleSignOn to a tree, it's more SSSO SingleServerSignOn....

    With 2 of the offices running clusters, we cant point out which physical server that's
    the current server for "logged in".....
  • 0 in reply to emerson8
    interesting...

    has anyone bit-the-bullet on 7.502 yet?
  • 0
    Yes, it's been on our production box since 12/09.  The only problem was one of my own creation.  7.502 is a "Go" for all of my customers.

    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
    i'm still scared - anyone else with crappy eDIR here?