Authentication failures with newer Watchguard Authentication Gateway (SSO eventlogmonitor + AD PCs)

Some months ago we upgraded the Watchguard Authentication Gateway to 12.7.2 and then 12.10. We also removed the service user from "Domain Admin" groups, but we gave him permission to access event logs of PCs as described in the guides.

SSO Agent is configured to use only Event Log Monitor, and is installed on the primary domain controller server. We use it to authenticate firebox users from their windows 10/11 Professional PCs joined to a local AD Domain.

Now PC are randomly unable to authenticate.

As you can see from the test below, all requests after the 1st one are failing:

giovanni@mypc:~$ telnet busitsrv01.mydomain.net 4114
Trying 192.168.133.1...
Connected to busitsrv01.mydomain.net.
Escape character is '^]'.
EVENT 350 log info Connected to the WatchGuard Authentication Gateway SSO agent. Version 12.10.0.29857 Build 685243. Connected at:11/15/2023 12:36:53
 To log in to the SSO Agent, type your user credentials. Or, type "help" to see the list of available log in commands.
 After you log in, type "help" to see all of the commands available for the SSO Agent.
login admin xxxxxxx
User admin logged in
get user 192.168.133.60
443 N=1 IP=192.168.133.60 user="johnsmith" domain=mydomain.net server=192.168.133.60 group="CN=CERTSVC_DCOM_ACCESS," group="CN=Domain Users," group="CN=Photo View," group="CN=Netpon Users, group="CN=STEX Admin Group," group="CN=All people bus," group="CN=Users," group="CN=Video Internal,"
get user 192.168.133.60
45 N=1 IP=192.168.133.60 ERROR="unknown user"
get user 192.168.133.60
45 N=1 IP=192.168.133.60 ERROR="unknown user"
get user 192.168.133.60
45 N=1 IP=192.168.133.60 ERROR="unknown user"

Restarting the "Watchguard Authentication Event Log Monitor" service makes the 1st request works again, but all subsequent requests will fail again.

Adding the user to the Domain Admin groups and restarting services did not solved it, also moving the gateway installation to a different server, not a domain controller, was not a solution.

This is error I can find in eventlogmonitor.log when querying a different IP:

2023-11-15T11:33:48Z [tid:9380] INFO: [Thread Body]  [Thread: Response to Get User Command] send message: async-29099-000A-192.168.132.195-10-2 79 N=0 IP=192.168.132.195 ERROR="Remote host "192.168.132.195" in logoff status"
 (to socket[1])

... but the user is logged on and working at his PC.

I had to rollback to WG-Authentication-Gateway 12.5.4 and re-add the service user do Domain Admins group to make AD SSO works.

Why does only the 1st "get user" succeed ?

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @giox069
    If the older versions aren't working, there was likely a change somewhere else.
    -Were any OS updates installed during that time?
    -Have any security policies/group policies changed?

    For example, Event Log Monitor relies on pieces of windows file/print sharing to be able to access the event logs on remote machines. If this gets disabled due to a security policy change, ELM will not be able to pull logs. If this is the case, re-enabling, or using the SSO client should allow this to work.

    -James Carson
    WatchGuard Customer Support

  • edited November 15

    Older versions are working (but requires the user be PC administrator). Newer version aren't working starting from the 2nd authentication attempt.

    Windows file/print sharing is obviously enabled, and the proof is that older versions of GW are working, and newer versions work at the 1st attempt after eventlogmonitor service restart.

    We would not like to distribute the SSO client: it's an extra management cost which we would like to avoid if possilble. Spending a huge amount of money distributing an extra software to manage, just to workaround a misconfiguration or a bug, is not a wise choice.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @giox069 Best I can suggest here is to open a support case. Based on what I can see there's an issue preventing the ELM from pulling the correct user logs (or it being able to at all.) Our support team should be able to sort out what's happening and assist.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.