2 Replies Latest reply on Mar 17, 2016 11:05 AM by phlrnnr

    Re-Authenticating Generic or Shared Accounts with Kerberos / NTLM Fallback


      Many organizations still have a need for shared workstations where multiple users share a user login to a common workstation in a shared workspace.  When using NTLM or Kerberos authentication, you only are able to see the userID of the shared account to make decisions in MWG, not the actual userID of the person using the browser.  To get around this, we have been using a process we call "reauth" where a user is authenticated twice.  If done properly, this causes a browser to throw a prompt forcing a user to enter new credentials which the browser will then use for authentication until it is closed and re-opened.


      To do this, we make sure all shared accounts are members of a particular AD group (for example, a group called "no-internet".  We then use MWG to perform authentication, look for this group membership, and if present, authenticate the user again.


      It is important that when doing re-auth, you need to make sure you re-authenticate the user with the same type of authentication that the user was originally authenticated with.  If the first auth was done with Kerberos, the re-auth must also be Kerberos.  If the first was NTLM, the re-auth must also be NTLM.  When doing Kerberos, falling back to NTLM, this is important because if the browser chooses Kerberos, and then is offered NTLM, it will fail, and the browser will return an error message instead of a dialog box asking for credentials.


      Here is a sample ruleset.  I hope this helps someone else that was challenged to solve this problem!



      First: the standard Kerberos, falling back to NTLM Ruleset (Thanks jscholte!)



      Next, we have a second ruleset to perform the re-auth.  Note, the user that already was authenticated must be a part of the "no-internet" group:


      The first rule above checks to see if the user was authenticated with Kerberos.  If it was, then it clears all of the authentication methods, and only sends down a "Negotiate" option (meaning auth with Kerberos).  The second rule does the same thing, except for the case where the NTLM fall back rules were used, and NTLM was used for the first authentication.


      The last rule simply sends the Authentication 407 back to the browser with the proper authentication method (Kerberos if Kerberos, and NTLM if NTLM).


      Hopefully this helps someone out!

        • 1. Re: Re-Authenticating Generic or Shared Accounts with Kerberos / NTLM Fallback
          Jon Scholten

          Hi Phil!


          Looks good! I think you might be able to simplify it down to a single rule below "Perform Authentication" (in the first ruleset).


          -Name: Re-Authentication for Generic Accounts

          -Criteria: Authentication.UserGroups contains "no-internet"

          -Action: Authenticate<Default>


          Best Regards,


          • 2. Re: Re-Authenticating Generic or Shared Accounts with Kerberos / NTLM Fallback

            I tried that, but wasn't successful.  The re-auth failed because, the proxy didn't present the kerberos method (only NTLM) because Authentication.Authenticate<Kerberos> was true.  So, if doing kerberos the first time, NTLM was presented for the re-auth and the browser didn't like it.


            That's why I had to clear the authentication.methods and only present what the browser already authenticated with.


            What you are saying works if you are only doing NTLM, or only doing Kerberos.  But it doesn't work with the Kerberos falling back to NTLM.  We were doing this before the way you suggested when we only did NTLM.  Once we added kerberos to the mix, it became more complicated.