Authenticated users appear as machine names or Anonymous Logon in ProxySG/ASG - Identifying the problem

Products

• ISG Proxy

Issue/Introduction

We have this policy in local CPL – should this somehow mitigate LOCAL account issues? For some reason this does not seem to work? Do you have updated local CPL we could try?

 

 

; #############################

; Authentication rules

; #############################

 

define condition IWA_SILENT_USERS

  user="NT AUTHORITY\anonymous logon"

 user="AUTORITE NT\anonymous logon"

  user="anonymous logon"

  user.regex=”-adm”

  user.regex='^LOCAL'

  user.regex='.+\$$'

  user.regex='dknp'

  user.regex='dkpc'

  user.regex='dkpf'

  user.regex='finp'

  user.regex='firb'

  user.regex='nonp'

  user.regex='plnp'

  user.regex='senp'

end condition IWA_SILENT_USERS

 

<proxy>

  url.domain=<your_xxx_domain> authenticate(no) allow

  url.domain=your_yyy_domain authenticate(no) allow

  realm=xxxxxxxxxxx condition=IWA_SILENT_USERS user.login.log_out(true)

 

Environment

Release : 7.3.12.1

Resolution

Having investigated the CPL code shared, please see our submission below.

In cases where the ProxySG or Advanced Secure Gateway (ASG) appliance requests authentication before a user logs in to their workstation, Windows machines will send either the workstation name (ending with $) or 'NT AUTHORITY\ANONYMOUS LOGON' as the authentication credentials. The ProxySG does not control the client's ability send user credentials or machine credentials as a response to the authentication challenge from ProxySG. 

We can use the following Content Policy Language (CPL) code to log out the Workstation Machine name and have the User authenticate again  (Recommended CPL).

define condition IWA_SILENT_USERS
     user="NT AUTHORITY\anonymous logon"
     user="AUTORITE NT\anonymous logon"
     user.regex='.+\$$'
end condition IWA_SILENT_USERS

<Proxy>
  realm=<real_name> condition=IWA_SILENT_USERS user.login.log_out(true)

See the snippet below, for the test install of the script, done within our internal lab.

 

If you have multiple realms, put them together under a condition and reference the name of the condition in the web access CPL script, in the same manner.

For the additional regex conditions that we see in the case description, please refer to the below, for guidance on how the regex conditions would translate.

'^LOCAL' ==>  literally "'", begin with, literally "LOCAL'"

'.+\$$' ==>  literally "'", anything, once or more, literally "$", must end, literally "'"

 'dknp' ==> literally "'dknp'"

To explain the "user.regex='^LOCAL'" regex condition, please refer to the Authentication failure below.

""2023/02/16 17:03:08.208 [5940] [5184:5940] Failed NTLM Authentication for user: 'LOCAL\nxxxxxx'; status=1909:0x775:The referenced account is currently locked out and may not be logged on to.""

For 'LOCAL\nxxxxxx', the LOCAL isn't a part of the login credential the Windows machine presented for web authentication. The credential presented is "nxxxxxx". So, with the "user.regex='^LOCAL'" regex condition, we are saying that the username presented for web authentication must literally begin with LOCAL. This is the only way the condition would be matched. So, if the Windows machine does not present the credentials this way to ProxySG, the particular regex condition wouldn't match.

For the 'dknp' ==> literally "'dknp'" regex condition, the Windows machine must present a login credential that's literally 'dknp', for the regex condition to be matched.

So, if you chose to add the user.regex condition, refer to the guidance above, for a clear understanding of how the regex may translate.

How do we know we have the particular authentication challenge that would necessitate the use of this CPL script?

The only way to know we have this problem would be to check the user logins, in real time, and we must look out for a web authentication that utilized a non-AD user credential. Please see the snippet below, collected from my Broadcom lab. Note that the snippet does not show the problem and that's because Windows only presented my AD user credential, for web authentication, as expected.

If you that Windows machine(s) is/are presenting the Windows machine name(s)/anonymous/anything else, as described earlier, then there is this challenge and the CPL script can be applied, as guided.

Please note that for every other kind of authentication failure, not linked with the causes described herein, it's recommend to have them independently investigated and the relevant diagnostics checked, to correctly identify the root cause(s), to ensure the most appropriate fix is provided.

One log where you would find the issue, described in this update, show up, would be the LSA debug log. This is particularly useful with IWA_Direct. With IWA_BCAAA, investigating the BCAAA debug log alongside the BCAAA application log, from the BCAAA, Windows server, would be more relevant.