LDAP authentication uses the LDAP protocol to authenticate users that are accessing network (Internet) resources. The LDAP authentication will require a pop-up box in which the user will enter their credentials (username and password) in order to access the Internet. These credentials are stored or cached by the web browser. Any time the browser is closed, the cached credentials are discarded by the browser. When a new browser window is opened, the end user will be prompted for their LDAP credentials. If users frequently close all their browser windows and open them again, and/or if the users are not accustomed to authenticating using their LDAP credentials, the users may end up complaining. If so, you may wish to consider using a different form of seamless authentication, such as IWA, Windows SSO, or Novell SSO.
- Knowledge of the type of LDAP server that is on the back end
- Knowledge of the LDAP baseDN (this is where you start your LDAP searches)
- A directory user that LDAP can use in order to search the tree if anonymous LDAP browsing is not enabled or allowed.
- Create the LDAP authentication realm in the Management Console.
- Create policy (Web Authentication Layer and Web Access Layer) that leverage the LDAP realm
STEP 1: CREATING THE LDAP AUTHENTICATION REALM ON THE PROXYSG
1.) Go into the Management Console on the ProxySG ( https://<ip.address.of.proxysg>:8082/ ) and go to the Configuration tab > Authentication > LDAP.
2.) In the "LDAP Realms" tab, click on the "New" button. Give the realm a name, such as "MyLdapRealm". Select the type of LDAP server that's on the back end. Put in the IP address of the LDAP server. Also select the LDAP port. Generally the user attribute type is "cn" for common name. Once all the correct data has been entered, click on "OK" and then the "Apply" button to save your changes.
3.) If you have multiple LDAP servers that you want to use in case one server goes down, then click on the "LDAP Servers" tab and enter the IP address of an alternate server host. Click the "Apply" button to save your changes.
4.) Click on the "LDAP DN" tab. This is where you set your base DN(s). The base DNs are the locations in the LDAP tree that ProxySG will search for LDAP users. For AD users, this will be cn=user_container,dc=host,dc=example,dc=com. Once your base DNs have been included, click on the Apply button. NOTE for eDirectory users: For those who are running eDirectory, make sure that the base DNs point to replica servers and not just servers with a sub-ref on them. Blue Coat does not recommend using a server that only contains subrefs on the replica server.
5.) Click on the "LDAP Search & Groups" tab. The "Anonymous search allowed" may be checked. If anonymous LDAP search is not allowed, then uncheck it. You will also need to enter a user name and password. This username and password must be in LDAP format, such as cn=user,cn=users,dc=host,dc=example,dc=com. You may want to create a limited or restricted user that can only search your tree. NOTE: If you have user password policies enabled (every user password must be changed ever <xxx> number of days), then make sure you document the password change interval and stay on top of mandatory password changes. In order to keep potential disruptions to a minimum, it may be advantageous to not place password restrictions (change the LDAP search user's password every <xxx> number of days) on the LDAP search user. Use your own discretion about password management for the LDAP search user account. Click on "Apply" to save your changes.
6.) Click on the "LDAP General" tab. Review the items entered in this page. The credential refresh timeout is set to 900 seconds (15 minutes). This is the amount of time the credentials will be cached on the ProxySG before the ProxySG goes back to the LDAP server to refresh (re-authenticate) the user's credentials. For now, simply use the defaults.
7.) The ProxySG is now ready to pass authentication requests on to the LDAP server.
STEP2: CREATING POLICY ON THE PROXYSG
The assumption about policy creation is that no authentication is currently in place.
1.) In the Management Console ( https://<ip.address.of.proxysg>:8082 ) go to the Configuration tab > Policy > Visual Policy Manager > Launch . The Visual Policy Manager (VPM) will launch.
2.) Click on Policy > Add Web Authentication Layer... > and give it an appropriate name, such as LDAPAuth and click on the OK button. Your new web authentication layer called LDAPAuth will be created.
3.) Since this is a new web authentication layer, the first rule is created. Go to the Action column, right click and select Set > New... > Authenticate... Give it a name, such as LDAP. For the Realm, select the realm name given in step 1.2 above. In this example, we used MyLdapRealm as the name. For simplicity sake, you can leave the authentication mode as Auto. (For additional information about authentication modes, please see 000012964 or the Configuration and Management Guide (CMG).) Click the OK button twice and make sure the "LDAP" authentication object is displayed in the Action column.
4.) Optional: For testing purposes, you may want to restrict the source IP addresses to designated test workstations. That way if LDAP authentication does not work as expected, the authentication changes only affect test workstations and not the whole proxy infrastructure. To restrict authentication to a select group of workstations, right click on the Source column, select Set... > Client IP Address/Subnet... . Enter the IP address (if this is a single IP address, the subnet mask can be omitted) or the network in which you wish to authenticate. Click the Add button, then Close, then OK. The IP address or subnet you selected should now show up in the Source column.
5.) Now go to your existing Web Access Layer. If you don't have a web access layer, create a new web access layer (Policy > Add Web Access Layer...). If you have an existing web access layer, add a rule after your deny rules. This assumes that your default policy is "Allow" and not deny.
6.) In the newly created rule, right click in the Source column and select Set... > Authenticated user > OK. In the Action column, right click and select Allow. NOTE: If LDAP authentication is being added for some test workstations, for the Source column you create a combined source object. In the top right "at least one of these objects" box, add in the Authenticated User source object. In the bottom right "at least one of these objects" box, put in the IP address(es) that you selected in optional step 4 above. Save your changes.
7.) Install policy and test.
NOTE: Users will be presented with an authentication pop-up box that asks for a username and password for the name of the LDAP realm created in Step 1.2 (MyLdapRealm) above. Generally the credentials entered will be just the user's common name (CN). For example, if this is an Active Directory LDAP environment and user fred resides in the Users container, and your domain is called host.example.com, then all you need to do is enter fred for the user name and user fred's password. If you do not want users to be prompted for authentication, then you need to try a noninteractive method of authentication, such as IWA, Windows SSO, or Novell SSO.
- If you want to make sure the ProxySG is able to browse the LDAP server, in the web access layer in the source column, right click and select Set > New > and select either User or Group. For the "Authentication Realm", select your LDAP realm. Then click on the "Browse" button. If everything is functioning as expected, then you should see your LDAP tree. If everything is working as expected, just cancel out all the changes made. If you are unable to browse the LDAP tree, then you will need to troubleshoot why that does not work.
- LDAP troubleshooting can be aided by using an LDAP browser. You can search your favorite search engine for an LDAP browser of your liking. Softerra has an LDAP browser that can be used to browse the LDAP tree. Blue Coat does not explicitly or implicitly endorse this particular LDAP browser implementation. It is being mentioned simply as a courtesy to help expedite searching for an LDAP browser.
- Bypassing authentication. If most of your applications work with LDAP authentication, but there are a few applications that just don't seem to work properly when LDAP authentication is enabled, please see 000008272 titled "Bypassing ProxySG authentication" on various methods that can be used to bypass ProxySG authentication.