locked
ADFS pop-up loop on some computers RRS feed

  • Question

  • Hello everyone, I have a strange problem on my ADFS configuration to authenticate users of an AD on a WordPress

    Indeed, the IE configuration was done by GPO, in this one, I made sure to respect the Intranet and Truteed zone where I put the FQDN of my ADFS and the URL of my WordPress.

    I also set up IE following the recommendations of MS.

    ADFS is configured to use the WIA for the intranet zone.

    For the same user, I have different behaviors depending on the computer :

    • On one computer, the SSO connection works perfectly, the request is sent to my ADFS which sends back a token to my user and makes the connection.
    • On another computer, the connection request sends back a pop-up asking for my user's credentials. When I give these credentials, the pop-up reappears 3 times but the connexion failed.

    I have retrieved the logs for these two events , but I can't interpret them to detect where the source comes from.

    Thank you in advance for your help!

    Here is an example of the log on the failed computer

    Information    21/01/2020 11:46:29    AD FS Tracing    155    Aucun    "      Primary stage authDomain: AuthenticationMethods:
      urn:ietf:rfc:1510
      urn:federation:authentication:windows
      urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
      http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/kerberos
      http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
    ProviderAuthInfoList:
      WindowsAuthentication
    UseProviderAuthInfoList: True
    "
    Information    21/01/2020 11:46:29    AD FS Tracing    155    Aucun          EXIT: EvaluatePolicy
    Information    21/01/2020 11:46:29    AD FS Tracing    54    Aucun    "    Sending response at time: '2020-01-21 10:46:29' with StatusCode: '302' and StatusDescription: 'Found'.
    Response headers set: {""Location"":""https://infosv36.sartrouville.lan:443/adfs/ls/wia?SAMLRequest=fZHfa8IwEMf%2FlZD32DRWVoOtuI0xwTHRuoe9jLSmNdBeulyq%2B%2FPX2QmOgU%2FH%2Ffx%2B7m42%2F2pqctQOjYWEhiNOiYbC7g1UCd1lTyym83SGqqlbuej8ATb6s9PoSd8HKM%2BJhHYOpFVoUIJqNEpfyO3iZSXFiMvWWW8LW1OyfEzox36856pUpeZFkUf5dCrCMion%2FG7Mp1rERazKXES8LGNK3i5c4odridjpJaBX4PsQF5zxkIkwC7mMYikm75Ssf8XuDQwr3CLLhyKUz1m2ZuvXbUbJAlE734s%2BWMCu0W6r3dEUerdZJfTgfYsyCAx4p0B7EVAyHEee4dzVVW5Lq4sMTf8PPbWssOA1%2BKCtu8oABo0BY%2Ft0pdmpp7YnZNij17o3FTALwSy44kgH7%2B%2FL0m8%3D\u0026RelayState=https%3A%2F%2Fintranet2%2F\u0026client-request-id=d23da12b-da1a-426a-0700-0080020000d9"",""Content-Type"":""text/html; charset=utf-8""} "
    Information    21/01/2020 11:46:29    AD FS Tracing    155    Aucun        EXIT: OnGetContext
    Information    21/01/2020 11:46:29    AD FS Tracing    54    Aucun    "Received request with following properties:
    
    Date: 2020-01-21 10:46:29
    Remote endpoint: 10.10.2.101
    Local endpoint: 10.10.100.36
    Http method: GET
    Request Url: /adfs/ls/wia
    Query string: ?SAMLRequest=fZHfa8IwEMf%2FlZD32DRWVoOtuI0xwTHRuoe9jLSmNdBeulyq%2B%2FPX2QmOgU%2FH%2Ffx%2B7m42%2F2pqctQOjYWEhiNOiYbC7g1UCd1lTyym83SGqqlbuej8ATb6s9PoSd8HKM%2BJhHYOpFVoUIJqNEpfyO3iZSXFiMvWWW8LW1OyfEzox36856pUpeZFkUf5dCrCMion%2FG7Mp1rERazKXES8LGNK3i5c4odridjpJaBX4PsQF5zxkIkwC7mMYikm75Ssf8XuDQwr3CLLhyKUz1m2ZuvXbUbJAlE734s%2BWMCu0W6r3dEUerdZJfTgfYsyCAx4p0B7EVAyHEee4dzVVW5Lq4sMTf8PPbWssOA1%2BKCtu8oABo0BY%2Ft0pdmpp7YnZNij17o3FTALwSy44kgH7%2B%2FL0m8%3D&RelayState=https%3A%2F%2Fintranet2%2F&client-request-id=d23da12b-da1a-426a-0700-0080020000d9
    Local Port: 443
    User agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362
    Body data length: 0
    Caller Identity: -
    Certificate Identity: -
    Relying Party: -
    Through proxy: False
    Proxy name: -
    Serialized Header: {""Upgrade-Insecure-Requests"":""1"",""Cache-Control"":""max-age=0"",""Connection"":""Keep-Alive"",""Accept"":""text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"",""Accept-Encoding"":""gzip, deflate, br"",""Accept-Language"":""fr-FR,fr;q=0.5"",""Host"":""infosv36.sartrouville.lan"",""Referer"":""https://intranet2/"",""User-Agent"":""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"",""X-MS-Endpoint-Absolute-Path"":""/adfs/ls/wia""}
    "

    • Edited by Askaaroth Tuesday, January 21, 2020 1:48 PM Modification description
    Tuesday, January 21, 2020 1:47 PM

All replies

  • It seems like it is a purely Windows Integrated Authentication issue. By that, I mean that it is very possible that nothing is wrong at the ADFS level.

    Can you create a test account, with no group membership (or just the one required to access this relying party trust) and try from the computer where it does not work. Do you have the same result?

    Also, are they all in the same domain? What version of the OS and Internet browser are installed? From a network perspective, are all computer user an HTTP? All the same proxy? Are there are SSL inspection between the client and ADFS?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Saturday, January 25, 2020 1:48 PM