OWA 2013 SSO failed

hello,

I trying to get OWA 2013 working with the APM, but my SSO configuration i snot working properly. even if the auth with the APM is ok, I still get the login page from the OWA with a "wrong username/password" message. and I get this log :

Jul 15 17:17:40 an03dcadc01 warning tmm6[10031]: 014d0002:4: 47b460e1: SSOv2 Logon failed, config /Common/Exchange_TST.app/exchange_forms_sso form owa

here is my sso config:

apm sso form-basedv2 /Common/Exchange_TST.app/exchange_forms_sso {
    app-service /Common/Exchange_TST.app/Exchange_TST
    forms {
        owa {
            app-service /Common/Exchange_TST.app/Exchange_TST
            request-value /owa/auth/logon.aspx
            submit-javascript clkLgn()
            submit-javascript-type extra
            success-match-type cookie
            success-match-value cadata
            controls {
                password {
                    app-service /Common/Exchange_TST.app/Exchange_TST
                    secure true
                    value "%{session.sso.token.last.password}"
                }
                username {
                    app-service /Common/Exchange_TST.app/Exchange_TST
                    value "%{session.logon.last.logonname} " ; I used this to get the domain in the username
                }
            }
        }
    }
}

Anyone managed to get OWA 2013 working ? I found these articles, but I don't know what I'm missing

https://devcentral.f5.com/questions/exchange-owa-2013-sso

https://devcentral.f5.com/questions/sam-auth-double-prompt-using-exchange-iapp

I used the iApp f5.microsoft_exchange_2010_2013_cas.v1.3.0 for my configuration.

18 Replies

mikeshimkus_111
Historic F5 Account
Jul 15, 2014
Hi, looks like the iApp uses "secure false value "%{session.sso.token.last.username}" to get the username value. Did you have a specific reason for changing it?
Abdessamad1
Cirrostratus
Jul 15, 2014
It is set to True only for the password. nothing changed on this side.
Abdessamad1
Cirrostratus
Jul 15, 2014
And I used %{session.logon.last.logonname} to get the username in the format DOMAIN\username as typed in the logon page. because the F5 strip the domain in %{session.sso.token.last.username}
mikeshimkus_111
Historic F5 Account
Jul 15, 2014
Do you have OWA forms authentication set to use username only in the Exchange admin center? That's what the iApp is set up for by default, so you only need to enter the username in the APM logon page, not DOMAIN\username.
Abdessamad1
Cirrostratus
Jul 15, 2014
So I did not understand well enough then, I though I had to passe the full DOMAIN\username I do when directly connecting to the CAS.

I changed it back to the default %{session.sso.token.last.username} and it is working like a charme :)

thanks a lot for the quick reply.
Stefan_Klotz
Cumulonimbus
Jun 11, 2015
I hope someone will read this as this is not a new question, but relates to the same topic.

I also have an OWA2013 application and we have an APM based on 10.2.4 in front of it. Logon page and AD auth works fine, but then SSO is failing. I'm just getting forwarded to the OWA logon mask and the username from the APM logon page is already filled in. I sniffered the traffic on the serverside and there is only ONE HTTP-request towards the URI "/owa/auth/logon.aspx" (issued from the floating SNAT automap address), but in my SSO config I entered in the Form Action field "/owa/auth.owa" (catched that value from the source code of the OWA logon page). Should I see the SSO request also from the SNAT-address or will this be issued from the local self-IP?

Can anybody help me here, what's or where the issue is? Or how can I further troubleshot this? And is it normal that in the APM session log only the session.sso.token.last.username is mentioned? Because it seems that the password will not be correctly transferred to the OWA logon page.

Thank you!

Ciao Stefan :)
mikeshimkus_111
Historic F5 Account
Jun 12, 2015
I see 7 instances of "no start URI match". This means that the SSO isn't being triggered because the URI used to access OWA doesn't match what's configured in the SSO object. You then get a 440 login timeout from the CAS.
Stefan_Klotz
Cumulonimbus
Jun 13, 2015
As I'm running version 10.2.4 I also checked the older Deployment Guide for v10, but for Exchange 2010. I tried now different "start URIs" (the one mentioned in the Guide or just "/owa/") and also included the hidden parameter values, but doesn't seem to matter. In the log I'm still getting "no start URI match", even if the configured and requested one are the same. The response from the server is always 403 Forbidden.

So what are the correct values for form based SSO in version 10.2.4 with Exchange 2013?

Thank you!

Ciao Stefan :)
kunjan
Nimbostratus
Jun 14, 2015
Jun 12 09:43:20 local/DERLLB002 debug /usr/bin/websso[28154]: 01490000:7: <0xf648b6d0>:httpMessage.cpp:322 http headers, len: 329 ======== :status: 302 Found Location: https://Jun 12 09:43:20 local/DERLLB002 debug /usr/bin/websso[28154]: 01490000:7: <0xf648b6d0>:httpMessage.cpp:322 http headers, len: 329 ======== :status: 302 Found Location: https:///owa/auth/logon.aspx?url=https%3a%2f%2f%2fowa%2f&reason=0 Server: Microsoft-IIS/8.0 request-id: 1c93a22b-0cf8-41cf-a34f-5851ca53752c X-Powered-By: ASP.NET X-FEServer: DEFRKIM0533 Date: Fri, 12 Jun 2015 07:42:44 GMT Connection: keep-alive Content-Length: 220 ======== Server: Microsoft-IIS/8.0 request-id: 1c93a22b-0cf8-41cf-a34f-5851ca53752c X-Powered-By: ASP.NET X-FEServer: DEFRKIM0533 Date: Fri, 12 Jun 2015 07:42:44 GMT Connection: keep-alive Content-Length: 220 ========

Try using the start uri as following, replacing DNS name

/owa/auth/logon.aspx?url=https%3a%2f%2f%2fowa%2f&reason=0
Stefan_Klotz
Cumulonimbus
Jun 15, 2015
OK, I get it working that if configured start URI and requested URI are matching the correct POST-request will be send towards the server. But I still get a 403 Forbidden response. We are currently checking this in the access logs of the Exchange servers.

But what I still don't understand, how can I guarantee that the client is always entering the correct start URI (maybe they have a favorit to just /owa/)? I would expect, that Exchange is then doing a redirect to the correct login URI (same as configured for the start URI) and APM will catch this then. But that's not the case.

So is there still something wrong on the F5 or is this an issue on Exchange side? Or can this be adjusted with an iRule doing the redirect to the correct start URI in case the session Cookie is not available?

Thank you!

Ciao Stefan :)