
At authentication: when an LDAP user successfully logs in (to admin GUI, SSL VPN, CFS prompt, SSO, etc.), SonicWall builds that user’s effective membership:
groups mirrored/mapped from LDAP/AD, plus
the Default LDAP User Group you chose.
That default group therefore becomes a baseline membership for all LDAP users.
When importing users (Users → Local Users & Groups → Import from LDAP), the same default group is applied so imported objects on the firewall also carry that baseline membership.
If your Default LDAP User Group is set to a group that already has VPN access, privileged access, or wide network reach, then any LDAP account with valid credentials — no matter their real role in Active Directory — will inherit those permissions.
Example:
Default LDAP User Group = SSLVPN Services
Attacker obtains any AD user’s credentials — e.g., a low-level account with no business need for VPN.
Because of the default group, SonicWall grants them VPN access automatically, bypassing your intended AD-based restrictions.
Now they have a direct entry into your internal network from the Internet.
In the context of an Akira ransomware attack, the SonicWall Default LDAP User Group can become a critical weak point if misconfigured. This setting automatically adds every successfully authenticated LDAP user to a predefined local group, regardless of their actual membership in Active Directory. If that default group has access to sensitive services—such as SSL VPN, administrative interfaces, or unrestricted network zones—then any compromised AD account, even one with no legitimate need for those services, will instantly inherit those permissions. This effectively bypasses intended AD group-based access controls, giving attackers a direct path into the network perimeter as soon as they obtain valid credentials.
Set the Default LDAP User Group to None

Setting the Default LDAP User Group to None ensures that no additional baseline permissions are automatically granted to all LDAP-authenticated users. This means that a user’s access will be determined solely by the LDAP group memberships mirrored or mapped from Active Directory, eliminating the risk of unintentionally giving sensitive privileges—such as VPN, administrative, or content filtering bypass rights—to accounts that should not have them. With this configuration, any account that is not explicitly part of an allowed AD group will be denied access to services like SSL VPN or firewall administration, even if the credentials are valid. While this approach strengthens security by enforcing least privilege, it also requires careful group mapping and policy configuration to avoid accidentally locking out legitimate users who need access.