Too many problems, not enough time.

Enable EqualLogic Active Directory Authentication

If you’re using a DELL EqualLogic SAN you have the ability to turn on Active Directory authentication. The benefit once setup is that you can control access to the SAN via AD groups rather than giving out the Group Admin account or maintaining local accounts on the EqualLogic group.

The process to turn on Active Directory authentication is quite simple. Whether AD authentication is on or off you can still use Local authentication and locally created accounts. So if you do lose connectivity to AD you will still be able to local on with the default grpadmin account or any other local accounts that you have made.

To begin, login to the EqualLogic Group Admin webpage with local Group Administrator permissions. On the left select Group Configuration then navigate to the Administration Tab. It should look similar to below with ‘Local Only’ set as the authentication type.

Select the Active Directory radio button. A new window will appear similar to below.

Click Add and type in at least one IP address of an AD Server. If you have more than one (which you should) you can click Add again and input multiple servers. The EqualLogic san will connected against the first AD server in the list and if unable to connect will work its way down the list.

On the right you can leave the Secure protocol as none and Use Default Port. If you’ve successfully put in the correct AD server IP addresses you should be able to click on Get Default and the Base DN should be automatically populated with you the root DN of your AD domain name.

For the User you will need an AD account. Open up Active Directory Users and Computers. Create a basic user with no special rights. Set the account not to expire. Make sure it has read access into AD (by default all user accounts will have this). Back in the EqualLogic Group Administrator use this new account created. Use the full domainusername format.

Click the Test AD Settings. A new window will appear and make a connection to each AD Server you added and perform a test search using the User you just created.

Hopefully all green ticks will be returned and you can click Ok and return to the AD Settings window. If you receive a red cross and a fail double check the IPs of the AD servers.

Click OK and one final window will open asking to join the EqualLogic group to the Windows domain. You can choose to Cancel this step if you don’t wish to use Single Sign On. If you proceed, for the username enter in an Administrator account that would have permissions to add workstations to the domain and click ok.

If successful you will see the Group name added as a computer in AD Users and Computers under the Computers OU.

The Administration tab should now look similar to below. You will have a new Active Directory Status section with a couple green ticks indicating that you have successfully added in an AD server and the Group was successfully created as a computer object in AD for SSO.

That’s all there is to it. You can now click on Add to add a new users or group from AD. A window will appear giving the option to create a standard local user account but now the radio buttons to create an AD user or group are available.

The process is the same for a user or group. Select the Add a new Active Directory user radio button. Under General settings type in the username of the AD User omitting the domain name. You can click on Check name which will verify with a green tick that the user does indeed exist in AD.

Click next and specify the permissions you want the account to have.

Click next again, verify the details and permissions you have set for the account then click finish.

If you choose to use an AD group. I recommend first creating a Domain Local group first in AD. Populate this group with the users you want to have access. Then run through the steps above but select Add a new Active Directory group.

Sounds like an interesting issue. The fact that AD users work obviously means that SSO has been configured and is working. I’m running the same series PS on the same firmware so that shouldn’t be the issue. I’m assuming that all the checks passed successfully? Have you started clean with a newly created test group, newly created test user with Group Admin permission?

My BaseDN name is: OU=datacenter,DC=bce,DC=com
At this level, when i search for an AD group – ‘its-admins’ it does not search that AD group. (The AD group resides in the OU: Datacenter -> Services -> Storage)

However, the search works when I define the BaseDN name on the EQL as:
OU=adminids,OU=datacenter,DC=bce,DC=com.

(There are multiple sub-OUs under OU=datacenter and ‘adminids’ is one of them at the same level as ‘services’)
It appears as though the EQL search is successful when we define a narrower BaseDN scope than a more generic one.

Any thoughts on how to correct this?

PS: Customer has a VNX array and defines the same top-level BaseDN, and can still fetch AD groups at the datactr–>services–>storage level.