Monthly Archives: January 2014

Configuring a Sonicwall for AD-Integrated VPN Access

This article builds off of the previously written article on configuring a Sonicwall for Active Directory integration – you’ll need to follow those steps here before proceeding.

Once the Sonicwall is successfully connected to Active Directory, you’ll likely want one (or more) groups that will give VPN users access to the system. Simply create a group in Active Directory and add some users to it:

Once done, we’ll make the Sonicwall aware of the group by importing it. Log into your Sonicwall and navigate to the Users>Local Groups section. Click the Import from LDAP… button. The Sonicwall will load all groups within the containers you’ve configured it to look for them in and display them. Select the group you just created for your VPN users and click the Save selected button:

That user will now show up in the Local Groups list within the Sonicwall. Click the Edit… button for that group, and add whatever subnets you wish to allow VPN access to:

… and that’s it! Once the user starts their VPN client, they’ll authenticate with their normal Active Directory username and password and they’ll be granted access to whatever subnets you’ve specified.

Credentialing a Sonicwall for Active Directory Integration

One of the many benefits of the Sonicwall OS is its ability to integrated into Active Directory (or any LDAP-based Directory Service). This allows you to keep one database of user information instead of two, reduces security holes, tightens policy enforcement, reduces Administration … you get the idea.

The first step is to create a user in Active Directory. This account will be used by the Sonicwall to authenticate user information, obtain group membership and interact with anything else it may need. Ensure you note the user’s User Logon name field, which will be in the form user@domain.local – this is used by the Sonicwall to bind to the LDAP service:

Because this is a service account, you want a nice, strong password – and remember, you want to prevent it from being changed or expiring:

This user will need access to enumerate group membership for all AD users you intend to allow access to the Sonicwall down the road. I’ve found that these permissions have changed in Server 2012 – older AD permissions allowed any user this right, more modern ones seem more restricted out of the box. I’ve found that the RAS and IAS Servers group suffices for this. If in doubt, pick a user and check out the Effective Permissions for the Sonicwall LDAP user you’ve created by enabling Advanced Features in the Active Directory Users and Computers console, then viewing the Security properties for a given user. Under the Effective Permissions tab, you should see Read group membership as one of the granted rights for the Sonicwall User:

You should be done with the user setup at this point. Let’s get to configuring the Sonicwall. Log into the device and navigate to Users>Settings. For Authentication method for login, you’ll want to choose LDAP + Local Users and then click the Configure button:

Under the Settings tab, you’ll want to enter the DNS Name of IP address of your LDAP Server/DC, the LDAP port you wish to use, the Bind DN (in username@domain.local form) and password of the Sonicwall’s AD user. You’ll notice I’ve turned TLS off on this setup – this is for testing. I suggest turning this off to prove everything else out first, because the TLS setup tends to be the most difficult to configure. Once done, click the Apply button before moving on:

Under the Schema tab, the options are pretty sparse – you get to choose essentially what property your Sonicwall will authenticate the username value to – I use the sAMAccountName value to match what the user enters at their workstations. Once done, click Apply to move forward:Sonicwall-AD-VPN-07

Under the Directory tab, you’ll have more to fill in – if you want to. You can also let the Sonicwall sniff out the proper values for you. Enter your domain in the Primary Domain field as shown. When you change this, it’ll ask if you want to update the User and Group Trees (the values below the domain) to contain the new Domain – feel free to click Yes to this, but either way those trees are probably not the correct values. I’m a big fan of clicking the Auto-configure button, which will read all user and group containers from AD holding those objects for you – and then you can remove the ones you know will not hold users that are logging in:
(If you have any authentication of server communications issues, this is where they’ll happen – the Auto-configure button will be the first time the Sonicwall attempts to communicate with the LDAP service)

Under the LDAP Users tab, you’ll have the option to allow only users who have a matching account in the local database to log in, to allow fuzzy-logic membership of local group names if they have a matching LDAP group membership, and to determine the default group used by the Sonicwall for all authenticated users. Again, once done click the Apply button before proceeding:

Lastly, we want to test. If you have gotten this far, you should be able to authenticate any user to Active Directory and see what groups they are a member of. Here I’m using the Administrator account, but any user account should suffice:

Lastly, I wanted to mention two frequently-asked options supposed by the Sonicwall – these are available by navigating back to the Users>Settings page:

The Case-sensitive user names option is pretty obvious – but, often overlooked. If the user has a login name of JDoe, they’ll have to know this in order to authenticate successfully to the Sonicwall. Since the Windows login screen does not enforce this, it’s unlikely your users will know what is capitalized and thus better to keep this off.

The Enforce login uniqueness option prevents the user from logging in from numerous workstations – it will only allow one session at a time, which increases security but may prevent them from logging in from more than one device.