Yesterday, I talked about configuring RADIUS for admin auth based on group membership (link). Today, I’ll go into configuring admin access on PAN with just LDAP. You may want to do this if you don’t have a RADIUS server, or if you only have a few admins you wish to grant access to the PAN. The main drawback to be aware of with LDAP based admin access is that, although it would seem that you should be able to use group membership to actuate admin access, you cannot do so with LDAP. To reiterate, any time you want to add another admin user to the device, you have to create them both in AD/LDAP, as well as in the PAN device. Although you won’t have the ability to group users in AD/LDAP and have that actuate access, what you will still gain is the ability to have the admins’ LDAP passwords work for the PAN and change as they change their LDAP password. Additionally, you will be able to disable their LDAP account, and they immediately won’t have access to the PAN.
The configuration is pretty straight forward:
We’re assuming here that you’ve already got an LDAP environment, such as MS Active Directory, and that you’ve created a user account that has the rights to read the parts of the LDAP store your users are located. That being said, the rest of the config happens on the PAN:
Navigate to Device->Server Profiles->LDAP
- Create a new server profile, and check the Administrator Use Only box; you could leave this unchecked and use this LDAP profile for both admin and non-admin (VPN) access, but I recommend making a separate profile for that, even if it’s against the same servers.
- Give the profile a name (the names are locally significant)
- Populate the server field by clicking Add and adding in a name (also locally significant), IP address (or fqdn if your PAN can resolve it), and port (389 for standard LDAP, 636 for LDAPS)
- Populate the domain name, and pick the type of directory (AD,edirectory,sun, and other are your options)
- Specify a base for searching for users—the device will usually suggest the base of the domain, but you can narrow that down a bit if you like. For example, if you have an OU that contains all of your admin users, and you know they will never live anywhere else, you should probably restrict this search to just that OU and its child containers.
- Specify an account to bind to LDAP for searches. The field says “bind dn”, but you can also specify it is username@domain format as well. You’ll need to put a password in for the account as well.
- By default the SSL checkbox is checked…don’t forget to uncheck this if you’re not using LDAPS
Under the authentication profiles (Device->Authentication Profile), create a new profile for LDAP admin access
- Give it a name (locally significant)
- leave the groups to “all” since you are actuating who gets in and out by a step we’ll cover later…
- Choose LDAP under the authentication menu, which will spawn other options
- Choose the server profile you created in the previous step
- the login attribute will be different between LDAP vendors; for MS Active Directory, the login attribute is sAMAccountName
Now that the underpinnings of LDAP are created, you’re ready to define users! Navigate to the administrators section (Device->Administrators), and click Add. Provide the username of the LDAP user, and specify the authentication profile you created in the last step. Choose a role from the drop down menu, and click OK.
Commit your configuration, and open up a new browser window to test access…if it’s successful, you should be brought to the admin GUI with whatever rights you gave the role you chose. If it’s unsuccessful, navigate over to the system log (Monitor->Logs->System) to see what happens during auth. The error messages should give you a pretty good indication of what’s up.