Guest User!

You are not Sophos Staff.

[9.191][BUG] OWA login via WAF fails with "Unknown username and or password"

ActiveSync is working, because I can connect to a Exchange mailbox, but whenever I want to connect through the webappplication (Owa), It fails. 

Example:
I try connect to Peter@example.com with ActiveSync, it works.
I try to connect to Peter@example.com with owa (Owa appears after I entered the credentials for the form authentication), it fails.

It used to work, but suddenly it stopped working.
  • fix in 9.200???

    ok, I've seen this is posted in all other threats too. Is this a database error?
  • same issues in 9.193-11...


    Maybe I shhould mention, that UTM is case sensitive for Usernames too. User, user and USER is NOT the same for UTM. If you use usernames as JohnDoe in your company AD, you have zo write the username exactly like that...

    Sorry for short answers and typos. was written on mobile using astaro.org app.
  • Debug log shows same issue if I use basic auth:
    2014:02:01-18:15:31 asg-1 aua[19390]: id="3007" severity="debug" sys="System" sub="auth" name="Trying regular bind with bind_dn and password."
    
    2014:02:01-18:15:31 asg-1 aua[19390]: id="3007" severity="debug" sys="System" sub="auth" name="ldapFilter: (&(objectClass=user)(objectcategory=Person)(sAMAccountName=domain\user))"
    2014:02:01-18:15:31 asg-1 aua[19390]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth_directory() directory authentication failed. No such user."


    "sAMAccountName=domain\user" is the wrong format!
    "sAMAccountName=user" would be correct!

    In 9.192 "sAMAccountName=domain\user"
    In 9.193 "sAMAccountName=domain\user"

    both is wrong..
  • Hi mod
    fix in 9.200???

    ok, I've seen this is posted in all other threats too. Is this a database error?


    No database error. The mantis ids have a target which was empty previously. [:)]

    Regarding Mantis ID 29604 and its limitations with Active Sync:

    - When you are using Active Directory as a backend, the username transmitted by Activesync is either user@domain or domain\user. If a server object of backend type 'Active Directory' is used, then users are expected to authenticate *without* the domain name. 
    The WAF strictly needs the domain name though, as it has to pass the user credentials on to the backend servers which might require the credentials to obbey the format 'domain\user' or 'user@domain'. There is a workaround for this:
    -  Instead of Active Directory set the backend type of the desired authentication server to LDAP and use the custom user attribute 'userPrincipalname'. This should work out of the box for all Active Directory servers. Using users/groups aligned with this LDAP server it's possible to have users specify their domain name but only in the 'user@domain' format ('domain\user' format not supported by AUA).
    The online documentation will specify exactly - step by step - what users need to do for this scenario.
    Will increase priority and target version for this id.
    I hope this is useful.
    Best regards,
    Bianca
  • hi Bianca,

    thanks for this hint. The workaround with ldap authentication seems to work with ActiveSync and owa. This is just a workaround not a solution. I hope, the developers can fix the "sAMAccountName" issue.

    regards
    mod
  • We are planning to release a fix for this issue in Version 9.194.
  • Hi mod,

    Username with \ is seen in sAMAccountName with \. This is an issue and we are tracking it in 30561. Cant attach to this thread because this thread already has a bug id linked to it.

    For the workaround provided above, its actually a solution for now. -> will be provided in next iso

    For your scenario, there is no way to pull the domain name information from AUA, this is not compatible with AUA's way to treating Active Directory server objects. Therefor "sAMAccountName issue" (containing domain in the username) will work with the workaround provided and there will be no code change.
    Best,
    Bianca
  • Hi Bianca,

    thats not realy good news. The "sAMAccountName" is an active directory attribute that can't contain a domain name. Many customers have managed smartphones. Most of them use domain\user method for authentication. Maybe that using the UPN is usefull for some customers but that's just a little part.

    What should we do with the other customers? Must these customers reenroll all the smartphone profiles? For midsize or greater customers this is very painfull.

    best,
    mod
  • We are planning to release a fix for this issue in Version 9.195.