Users accessing internet via Cloud SWG using WSS Agents and IPSEC access methods.
Authentication and group retrieval is done via Auth Connector.
After building a new Windows member server (WIn2k22 from Win2k19) with a fresh Auth connector installed, the sync of AD groups to Cloud SWG Portal worked fine.
However, many users are getting access denied messages going to allowed site as the Cloud Proxy is missing group info.
All user based rules would work fine.
Auth Connector.
Windows 2022 member server.
Cloud SWG.
Permissions issue causing S4Ulogin event to retrieve groups to fail.
Remove the Auth Connector service account from the protected user group.
Running the Auth Connector in debug mode, we saw that every s4uLogin request failed with Windows 1312 status (A specified logon session does not exist) as shown below, despite the users session existing (earlier AD operations in same session to retrieve the users mail, sAMAccountName confirmed this).
2024/01/24 13:24:22.469 [4440] distinguishedName [CN=Test User,OU=Users,OU=example,DC=local]
2024/01/24 13:24:22.469 [4440] userPrincipalName [[email protected]]
2024/01/24 13:24:22.469 [4440] sAMAccountName [User]
2024/01/24 13:24:22.469 [4440] userAccountControl 0x200
2024/01/24 13:24:22.469 [4440] Mail attribute type 3
2024/01/24 13:24:22.469 [4440] User's mail name [[email protected]]
2024/01/24 13:24:22.469 [4440] FindUserLogonNames() ADSI lookups took 281 milliseconds.
2024/01/24 13:24:22.469 [4440] FindUserLogonNames() returning 0x0
2024/01/24 13:24:22.469 [4440] Performing s4uLogon Auth for: '[email protected]'
2024/01/24 13:24:22.469 [4440] LsaLogonUser failed 8009030e 0
2024/01/24 13:24:22.469 [4440] [496:4440]Failed S4U s4uLogin for user: 'Example\User'; status=1312:0x520:A specified logon session does not exist. It may already have been terminated.
Although a huge number of different search hits exist on this status code, many would point out to a permissions issue. Looking more closely at the service account that was used with the Auth Connector service, we switched to an admin rule and all worked fine.
Looking more closely with the directory team, we found that the original service account used (member of the server operators group) was part of the Protected Users Security Group. As soon as were moved user from this group, the s4uLogin requests returned success status.