|
The FortiProxy or FortiGate requests authentication before a user logs in to the workstation or a Windows update triggers. Windows machines send the workstation name (ending with $) as part of the authentication credentials.
The FortiProxy or FortiGate cannot control whether the clients will send user credentials or machine credentials as a response to the authentication challenge.
A simple workaround is to go to Users & Devices -> 'Firewall Users' and select deauthenticate.
However, this must be done for each of the users for whom the anomaly occurs. In systems with high numbers of affected users, it is therefore recommended to instead add an additional LDAP filter:
Solution 1: If cnid 'sAMAccountName' is configured in LDAP:
config user ldap
edit "LDAP_Server_IP"
set cnid "sAMAccountName"
set account-key-filter "(&(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(!(objectClass=computer)))"
end
Note: The right syntax is (this is tested in FortiProxy v7.0.10 and v2.0.10):
set account-key-filter (&(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(!(objectClass=computer)))
Note:
This AD LDAP syntax query returns results where the sAMAccountName attribute matches the ObjectServer user name and all enabled persons or user objects.
Solution 2: If cnid 'cn' is configured in LDAP:
Make sure the Distinguished Name User objects reside inside the OU that does not have the Computer object.
Related article:
Technical Tip: LDAP configuration examples.
For more information about LDAP syntax, refer to the following Microsoft document:
Active Directory: LDAP Syntax Filters.
|
