Forum Discussion
FI_2016_187929
Nimbostratus
NimbostratusSAML SSO Using Logged In Windows Credentials
Trying to configure our F5 hosted IdP to authenticate clients using their logged in Windows credentials. The SP is an external vendor, we do not need to use Kerberos to authenticate to the application, just trying to use it to get the logged in credentials.
Using 401 Response to get logged in credentials, LDAP Query to get variables, and assigning the SAML Resource at the Full Resource Assign.
The LDAP lookup appears to be working and I can view the accounts AD variables in the APM report, however the SAML assertion is not being sent. I didn't see any SAML references in the logs so I don't know why, although there was and entry for Could not find SSO domain, check variable assign agent setting
We do get the following Kerberos references in the logs
KERBEROS agent: ENTER Function executeInstanceKERBEROS module: ENTER Function authenticateUsermodules/Authentication/Kerberos/KerberosAuthModule.cpp func: "display_status_1()" line: 84 Msg: : GSS-API error gss_accept_sec_context: d0000 : Unspecified GSS failure. Minor code may provide more informationmodules/Authentication/Kerberos/KerberosAuthModule.cpp func: "display_status_1()" line: 84 Msg: : GSS-API error gss_accept_sec_context: 186a5 :: KERBEROS agent: LEAVE Function executeInstanceExecuted agent '/Access_Policy_act_kerberos_auth_ag', return value 0
Is what we are trying to do possible? We can get the username from the HTTP 401 Response and set the variables, however SAML assertion not being sent.
Michael_Koyfma1Cirrus
Frank,
What you're trying to do is definitely possible and has been done quite a number of times. It's unclear right now if any of the issues/errors you're mentioning are benign or not. What is your end goal? Does your IDP serve only a single SP, or are there multiple SPs in the future? The way it should work is you should be going to SP, which will send users to the IDP with AuthN request, and then it will run through the Access Policy, perform seamless transparent authentication and issue SAML assertion in the response.
You should also turn on APM logs, including SSO to debug mode to see everything that is happening. And last, but not least, SSO Credential Mapping agent should not be necessary in your case.
- FI_2016_187929
Thank you for the help Michael. Currently the IdP is only serving a single SP. I removed the SSO Credential Mapping and now I get prompted for username and password, which I would like to avoid. With SSO Credential Mapping I was not prompted. After entering username and password, I get the same as before, assertion not sent. I can do some more testing tomorrow.
kunjanMay be good to note this
https://support.f5.com/kb/en-us/solutions/public/16000/000/sol16056.html
Try enabling debug for SAML SSO under IdP configuration under general settings.
Regarding the password prompt do you see this in a new browser session? Typically only upon 401 request the browser send the authentication header.
If the first HTTP request to APM goes with authentication header, user will see the password prompt, for which work around is possible.
- FI_2016_187929
Thank you everyone for your help. We now have IdP initiated working. The basic configuration was there, I needed to remove the SSO Credential Mapping and I also had the incorrect SSO Configuration associated with the Access Policy. However the SP initiated is not working correctly. When accessing the SP initiated URL in Internet Explorer, the client is redirected to the IdP and is then prompted for Windows security credentials. The 401 Response appears to be working because the logs show the varible is set Session variable 'session.logon.last.username' set to 'username@domain.com'. If the client cancels the Windows credentials prompt, they are prompted by a Windows download dialog asking if they want to Open or save sso from idp.domain.com. If they then reenter the SP URL in the browser again, they get successful access to the site using SAML SSO.
If they try to access the site in Chrome they get the following The webpage at https://idp.domain.com/saml/idp/profile/redirectorpost/sso might be temporarily down or it may have moved permanently to a new web address. Again, the logs show the username variable being set and successful sent through Access Policy. It seems there is some issue accessing the saml/idp/profile/redirectorpost/sso site.
Would there be any issues using Kerberos with SP initiated access?
InnOHi, I have kind of same problem here with the same policy. Any time the connection is SP-initiated, I get prompted for credentials any time the POST to /saml/idp/profile/redirectorpost/sso happens. Same policy but IdP-initiated works perfectly.- Evan_Champion_1I had the same problem where POST to /saml/idp/profile/redirectorpost/sso returns 401. I resolved this by changing IdP connector to Single Sign On Service Binding = Redirect.
- Evan_Champion_1Once you get this part working unfortunately you will find there is an issue with Kerberos authentication on F5 where initial authentication will work transparently as expected, but following session expiry the user will be prompted for credentials. See: https://devcentral.f5.com/s/feed/0D51T00006i7cUJSAY. Please open a support case with F5 to raise the priority of this issue.
- FI_2016_187929
In the Access Policy for Kerberos Auth, is Request Based Auth disabled?
- InnOSetting Request Based Auth to Disabled did the trick for me. Now I have to read some literature on that item to fully understand it :) Thanks, man, that was helpful.
Thrillseeker_12Excellent, did the trick for me as well! ;-) Thanks a lot