|
•
|
Attribute—A data item stored in an object in an LDAP directory. Object can have required attributes or allowed attributes. For example, the ‘dc’ attribute is a required attribute of the ‘dcObject’ (domain component) object.
|
|
•
|
cn—The ‘common name’ attribute is a required component of many object classes throughout LDAP.
|
|
•
|
dc—The ‘domain component’ attribute is commonly found at the root of a distinguished name, and is commonly a required attribute.
|
|
•
|
dn—A ‘distinguished name’ that is a globally unique name for a user or other object. It is made up of a number of components, usually starting with a common name (cn) component and ending with a domain specified as two or more domain components (dc). For example, ‘cn=john,cn=users,dc=domain,dc=com’
|
|
•
|
Entry—The data that is stored in the LDAP directory. Entries are stored in ‘attribute’/value (or name/value) pairs, where the attributes are defined by ‘object classes.’ A sample entry would be ‘cn=john’ where ‘cn’ (common name) is the attribute, and ‘john’ is the value.
|
|
•
|
Object—In LDAP terminology, the entries in a directory are referred to as objects. For the purposes of the SonicOS implementation of the LDAP client, the critical objects are ‘User’ and ‘Group’ objects. Different implementations of LDAP can refer to these object classes in different fashions, for example, Active Directory refers to the user object as ‘user’ and the group object as ‘group,’ while RFC2798 refers to the user object as ‘inetOrgPerson’ and the group object as ‘groupOfNames.’
|
|
•
|
Object class—Object classes define the type of entries that an LDAP directory might contain. A sample object class, as used by AD, would be ‘user’ or ‘group.’
|
|
•
|
ou—The ‘organizational unit’ attribute is a required component of most LDAP schema implementations.
|
|
•
|
Schema—The schema is the set of rules or the structure that defines the types of data that can be stored in a directory, and how that data can be stored. Data is stored in the form of “entries.”
|
|
•
|
TLS—Transport Layer Security is the IETF standardized version of SSL (Secure Sockets Layer). TLS 1.0 is the successor to SSL 3.0.
|
Microsoft Active Directory’s Classes can be browsed at <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/classes_all.asp>
LDAP / AD Configuration is executed on the User > Settings page.
Selecting either LDAP or LDAP+Local Users and clicking Apply at the top of the page enables LDAP support, the former using an LDAP directory server exclusively, and the latter using a combination of the LDAP server and the local user database. Upon applying these settings, an informational alert will be presented. Because SonicWALL is receiving sensitive username and password information from authenticating clients, HTTPS logins are automatically enabled to secure the credential exchanges.
|
1
|
Navigate to Start > Settings > Control Panel > Add/Remove Programs.
|
|
2
|
Select Add/Remove Windows Components.
|
|
3
|
Select Certificate Services.
|
|
4
|
Select Enterprise Root CA when prompted.
|
|
5
|
Enter the requested information. For detailed information on CA setup, see: http://www.microsoft.com/windows2000/techinfo/planning/security/casetupsteps.asp
|
|
6
|
Launch the Domain Security Policy application:
|
|
8
|
Open Security Settings > Public Key Policies.
|
|
9
|
Right click on Automatic Certificate Request Settings.
|
|
10
|
Select New > Automatic Certificate Request.
|
|
11
|
Step through the wizard, and select Domain Controller from the list.
|
|
1
|
|
2
|
|
3
|
|
4
|
|
5
|
Step through the wizard, select the Base-64 Encoded X.509 (.cer) format.
|
|
1
|
Browse to System > CA Certificates.
|
|
2
|
Select Add new CA certificate. Browse to and select the certificate file you just exported
|
|
3
|
Click Import certificate.
|
|
1
|
|
2
|
Click Configure LDAP to launch the LDAP configuration window:
|
|
•
|
Name or IP Address—Enter the FQDN or the IP address of the LDAP server against which you wish to authenticate. If using a name, be certain it can be resolved by your DNS server. Also, if using TLS with the ‘Require valid certificate from server’ option, the name provided here must match the name to which the server certificate was issued (such as the CN) or the TLS exchange will fail.
|
|
•
|
Port Number—The default LDAP over TLS port number is TCP 636. The default LDAP (unencrypted) port number is TCP 389. If you are using a custom listening port on your LDAP server, specify it here.
|
|
•
|
Server timeout—The amount of time, in seconds, that the SonicWALL waits for a response from the LDAP server before timing out. Allowable ranges are 1 to 99999 (in case you are running your LDAP server on a VIC-20 located on the moon), with a default of 10 seconds.
|
|
•
|
Anonymous Login—Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (MS AS generally does not), then you could select this option.
|
|
•
|
Login name—Specify a user name that has rights to log in to the LDAP directory. The login name is automatically presented to the LDAP server in full ‘dn’ notation. This can be any account with LDAP read privileges (essentially any user account) – Administrative privileges are not required. Note that this is the user’s name, not their login ID (for example, John Smith rather than jsmith).
|
|
•
|
Login password—The password for the user account specified above.
|
|
•
|
Protocol version—Select either LDAPv3 or LDAPv2. Most modern implementations of LDAP, including AD, employ LDAPv3.
|
|
•
|
Use TLS—Use Transport Layer Security (SSL) to log in to the LDAP server. It is strongly recommended that TLS be used to protected the username and password information that is sent across the network. Most modern implementations of LDAP server, including AD, support TLS. Deselecting this default setting provides an alert that must be accepted to proceed.
|
|
•
|
Send LDAP ‘Start TLS’ Request—Some LDAP server implementations support the Start TLS directive rather than using native LDAP over TLS. This allows the LDAP server to listen on one port (normally 389) for LDAP connections, and to switch to TLS as directed by the client. AD does not use this option, and it should only be selected if required by your LDAP server.
|
|
•
|
Require valid certificate from server—Validates the certificate presented by the server during the TLS exchange, matching the name specified above to the name on the certificate. Deselecting this default option presents an alert, but exchanges between the SonicWALL and the LDAP server still uses TLS – only without issuance validation.
|
|
•
|
Local certificate for TLS—Optional, to be used only if the LDAP server requires a client certificate for connections. Useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (AD does not return passwords). This setting is not required for AD.
If your network uses multiple LDAP/AD servers with referrals, then select one as the primary server (probably the one that holds the bulk of the users) and use the above settings for that server. It then refers the SonicWALL on to the other servers for users in domains other than its own. For the SonicWALL to be able to log in to those other servers, each server must have a user configured with the same credentials (user name, password and location in the directory) as per the login to primary server. This might entail creating a special user in the directory for the SonicWALL login. Note that only read access to the directory is required. |
|
4
|
Select the Schema tab:
|
|
•
|
LDAP Schema—Select Microsoft Active Directory, RFC2798 inetOrgPerson, RFC2307 Network Information Service, Samba SMB, Novell eDirectory, or user-defined. Selecting any of the predefined schemas will automatically populate the fields used by that schema with their correct values. Selecting ‘user-defined’ allows you to specify your own values – use this only if you have a specific or proprietary LDAP schema configuration.
|
|
•
|
Object class—This defines which attribute represents the individual user account to which the next two fields apply.
|
|
•
|
Login name attribute—This defines which attribute is used for login authentication:
|
|
•
|
sAMAccountName for Microsoft Active Directory
|
|
•
|
inetOrgPerson for RFC2798 inetOrgPerson
|
|
•
|
posixAccount for RFC2307 Network Information Service
|
|
•
|
sambaSAMAccount for Samba SMB
|
|
•
|
inetOrgPerson for Novell eDirectory
|
|
•
|
Qualified login name attribute – if not empty, this specifies an attribute of a user object that sets an alternative login name for the user in name@domain format. This might be needed with multiple domains in particular, where the simple login name might not be unique across domains. This is set to mail for Microsoft Active Directory and RFC2798 inetOrgPerson.
|
|
•
|
User group membership attribute – this attribute contains the information in the user object of which groups it belongs to. This is memberOf in Microsoft Active Directory. The other pre-defined schemas store group membership information in the group object rather than the user object, and therefore do not use this field.
|
|
•
|
Framed IP address attribute – this attribute can be used to retrieve a static IP address that is assigned to a user in the directory. Currently it is only used for a user connecting through L2TP with the SonicWALL’s L2TP server In future, this might also be supported for Global VPN Client. In Active Directory the static IP address is configured on the Dial-in tab of a user’s properties.
|
|
5
|
Select the Directory tab.
|
|
•
|
Primary Domain – specify the user domain used by your LDAP implementation. For AD, this is the Active Directory domain name, for example. yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain.
|
|
•
|
User tree for login to server – The tree in which the user specified in the ‘Settings’ tab resides. For example, in AD the ‘administrator’ account’s default tree is the same as the user tree.
|
|
•
|
Trees containing users – The trees where users commonly reside in the LDAP directory. One default value is provided which can be edited, an up to a total of 64 DN values might be provided, and the SonicWALL search the directory using them all until a match is found, or the list is exhausted. If you have created other user containers within your LDAP or AD directory, you should specify them here.
|
|
•
|
Trees containing user groups – Same as the previous, only with regard to user group containers, and a maximum of 32 DN values might be provided. These are only applicable when there is no user group membership attribute in the schema's user object, and are not used with AD.
All the above trees are normally given in URL format but can alternatively be specified as distinguished names (for example, “myDom.com/Sales/Users” could alternatively be given as the DN “ou=Users,ou=Sales,dc=myDom,dc=com”). The latter form is necessary if the DN does not conform to the normal formatting rules as per that example. In Active Directory the URL corresponding to the distinguished name for a tree is displayed on the Object tab in the properties of the container at the top of the tree. Ordering is not critical, but because they are searched in the given order it is most efficient to place the most commonly used trees first in each list. If referrals between multiple LDAP servers are to be used, then the trees are best ordered with those on the primary server first, and the rest in the same order that they are referred. |
|
•
|
Auto-configure – This causes the SonicWALL to auto-configure the Trees containing users and Trees containing user groups fields by scanning through the directory/directories looking for all trees that contain user objects. The User tree for login to server field must first be set, and clicking Auto-configure then brings up the following dialog:
|
|
7
|
Select the LDAP Users tab.
|
|
•
|
Allow only users listed locally – Requires that LDAP users also be present in the SonicWALL local user database for logins to be allowed.
|
|
•
|
User group membership can be set locally by duplicating LDAP user names – Allows for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.
|
|
•
|
Default LDAP User Group – A default group on the SonicWALL to which LDAP users will belong in addition to group memberships configured on the LDAP server.
Group memberships (and privileges) can also be assigned simply with LDAP. By creating user groups on the LDAP/AD server with the same name as SonicWALL built-in groups (such as ‘Guest Services,’ ‘Content Filtering Bypass,’ ‘Limited Administrators’) and assigning users to these groups in the directory, or creating user groups on the SonicWALL with the same name as existing LDAP/AD user groups, SonicWALL group memberships are granted upon successful LDAP authentication. The SonicWALL appliance can retrieve group memberships more efficiently in the case of Active Directory by taking advantage of its unique trait of returning a ‘memberOf’ attribute for a user. |
|
•
|
Mirror LDAP user groups locally – Mirrors the LDAP user groups locally.
|
|
•
|
Refresh Period – Enter the mirror refresh time in seconds.
|
|
•
|
Mirror – Select the type of user groups that are mirrored by selecting the All user groups on the LDAP server or Only groups that have member users or groups radio buttons.
|
|
8
|
Select the LDAP Relay tab.
The RADIUS to LDAP Relay feature is designed for use in a topology where there is a central site with an LDAP/AD server and a central SonicWALL, with remote satellite sites connected into it through low-end SonicWALL security appliances that might not support LDAP. In that case the central SonicWALL can operate as a RADIUS server for the remote SonicWALLs, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server. Additionally, for remote SonicWALLs running non-enhanced firmware, with this feature the central SonicWALL can return legacy user privilege information to them based on user group memberships learned through LDAP. This avoids what can be very complex configuration of an external RADIUS server such as IAS for those SonicWALLs. |
|
•
|
Enable RADIUS to LDAP Relay – Enables this feature.
|
|
•
|
Allow RADIUS clients to connect via - Check the relevant check boxes and policy rules are added to allow incoming Radius requests accordingly.
|
|
•
|
RADIUS shared secret - This is a shared secret common to all remote SonicWALLs.
|
|
•
|
User groups for legacy users – These define the user groups that correspond to the legacy ‘Access to VPNs’, ‘Access from VPN client with XAUTH’, ‘Access from L2TP VPN client’ and ‘Allow Internet access (when access is restricted)’ privileges respectively. When a user in one of the given user groups is authenticated, the remote SonicWALL will be informed that the user is to be given the relevant privilege.
|
|
10
|
Select the Test tab.
The Test page allows for the configured LDAP settings to be tested by attempting authentication with specified user and password credentials. Any user group memberships and/or framed IP address configured on the LDAP/AD server for the user is displayed. |
|
•
|
|
•
|
RFC2798 InetOrgPerson: Schema definition and development information is available at <http://rfc.net/rfc2798.html>
|
|
•
|
RFC2307 Network Information Service: Schema definition and development information is available at <http://rfc.net/rfc2307.html>
|
|
•
|
Samba SMB: Development information is available at <http://us5.samba.org/samba/>
|
|
•
|
Novell eDirectory: LDAP integration information is available at <http://www.novell.com/documentation/edir873/index.html?page=/documentation/edir873/edir873/data/h0000007.html>
|
|
•
|
User-defined schemas: See the documentation for your LDAP installation. You can also see general information on LDAP at <http://rfc.net/rfc1777.html>
|