I'm not understanding why your SSO was setup the way it was. I'm not finding the value and hopefully I just set something up wrong. LDAP Only: Step 1: Go to lf.domain.com Step 2: Login with Username and Password. Done SSO: Step 1: Go to lf.domain.com. Step 2: Click SSO Step 3: Answer a popup asking if it's ok to transfer from lf.domain.com to adfs.domain.com. Why is this happening? No other ADFS/SSO solution I have does this. I've never even seen this popup before on anything. Step 4: Answer a popup asking if it's ok to transfer from lf.domain.com to adfs.domain.com. Yes, this happens twice. Step 5: On the ADFS landing page, which should not come up at all using IE in a Windows Domain (pass-through authentication), input a much longer email address and password. Done What I expect to happen with SSO: Step 1: Go to lf.domain.com Step 2: Click SSO Done I followed these instructions: https://man.liquidfiles.com/security/sso_saml2_W2012_server.html Windows Server 2016 - ADFS 4.0 Hopefully someone can help me out. The ADFS landing page should only come up with third party browsers.
That doc was for w2012 and you tried it in the new w2016 so we can expect there will be some improvements in settings. It sounds like you will need to investigate and change some security settings. For w2008 and w2012 SSO this works as described. When SSO is configured correctly then if a user clicks the SSO button on the LF login page and he has been successfully authenticated before during login to domain on his desktop then the user will be allowed directly to the LF. If not then LF will redirect him to the SSO auth page for authentication. Cheers David
Change what security settings? All other endpoints I use with my ADFS implementation properly use passthrough authentication. You're settings are almost identical to what most other people use. In fact the only difference between you and Google Apps is one of your your Claim Issuance Policies. But those are the direct result of how you configured your SSO. Email -> Email Transform Email -> Name ID Here's Google: Email -> Name ID (this is literally the only difference and Google works fine) Transform Email -> Name ID And here's another weird bug. The ADFS landing page has a link "Login as current user". At first I thought that wasn't working. Come to find out I have to click on it twice because clicking on it the first time fixes the URL then it works the second time. First URL (from your application): https://adfs.domain.com/adfs/ls/?SAMLRequest=xxxxxxxxxx Second URL: https://adfs.domain.com/adfs/ls/wia?SAMLRequest=xxxxxxxxxx It adds the wia because the previous URL is malformed for a SAML request. As far as I can tell, this is your application sending the malformed link. All other solutions I use properly populate this data with the appropriate type. Also, because of SSO I had to force HTTPS since ADFS wont allow HTTP. I noticed this after forcing HTTPS: https://files.domain.com// What's with the double trailing slash?
I installed w2016 and tried to set up SSO with LF. There has been added many new features related to the cloud, and access control, but the SAML2.0 related configurations stay almost same like we have listed on our W2012 SSO howto page. Clicked up that settings (relaying party trust and claim rules) and it worked me all ok same way as under W2012 server, without any popups screen you described above few weeks ago. Only thing, for fist time after I pressed SSO button I had to accept self signed certificate of the testing ADFS server which can be expected. I don't want substitute MsSupport here and I have not reproduced that popups yet as well. So just guessing now. Maybe this popups could be related with the "ADFS > Access control Policies".
I got rid of the pop ups by clearing the browser cache of any machine that happens to. However pass through authentication is still not working. Instead of clicking SSO and going into LF it takes me to my ADFS landing page every time and the user has to either log in or click current user twice.
One client found this solution: ADFS 2016 added primary authentication methods for Intranet and Extranet. For Intranet "Forms authentication" was checked and LF always arrived on the login page of server. Unchked it and now auto SSO is working fine.
I believe I was that client as I had a ticket opened for this exact issue/complaint. Unfortunately the workaround I discovered of turning off form based auth broke other systems, so had to be enabled again. We require form auth as a failback form of auth for users whose signin can't SSO using their logged in creds, and need to manually supply alternate creds. Disabling form auth should not be a requirement, it should try Windows based SSO first-- this is how every single other app works. Also, even when using form auth there is something wrong, it makes you sign in twice. Any chance a dev can look at this? It's a real pain in an otherwise great product. The only reason why I can think it would use forms as a first auth type is if Liquidfiles is messing with the browser agent string, which I understand is how ADFS decides whether to use integrated auth or forms. Also I can confirm the behavior seen by justin. On first try the url path is malformed, it requires the /wia in the url
LF appliance with default SSO settings is configured like that, to handle the authentication from stronger method to weakest. When "Authn context" is set as Code: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport and "Auth Comparison" to "Minimum" ADFS service should pickup at 1st the stronger "Windows domain authentication" method for AD users and for non AD users then fall back to the minimum allowed which is password protected transport method and offer then the login form. When in W2016 it does not work like that it's a question for window support to tell us what should be configured in the ADFS settings. Also important is to have enabled the windows authentication method in browser.
