¶ Source AD/LDAP Security Groups
To use AD/LDAP Security Groups, you cannot use the default domain administrator credentials when configuring AD/LDAP in StorCycle.
Instead, create a new user and add them to the domain Administrators group, and use the new credentials to configure AD/LDAP.
When using AD/LDAP Security Groups, users will not be able to access data from restricted locations unless they are a member of that domain group.
Domain groups are assigned to Source locations during creation or edit. A single group may be assigned to a source location. The source group can be changed or removed at any time. During Source creation or edit, check the ‘AD/LDAP Group’ checkbox, and enter the group which is associated with the source.
NOTE: It is possible that StorCycle will not be able to successfully query your AD/LDAP structure to identify group membership. This is due to the potential for AD/LDAP structures to be configured in widely different ways.
¶ AD/LDAP Structure that will only work with StorCycle 4.0.1 group security.In StorCycle 4.0 and prior, the simplest way to enable user/group membership is to have each user’s LDAP entry explicitly list which groups the user has available for StorCycle restrictions. That way, the LDAP query can search from a given user and immediately determine which groups they are in. I.e. which groups are listed in a given user’s LDAP entry. Another possibility is if both user entries and group entries are in the same organizational unit, (specifically the same base DN can be used for searching for both users and groups) then membership queries can be constructed that will look up users inside a group. i.e. which users are listed in a given group’s LDAP entry. At this time, however, 4.0 and prior versions cannot resolve user/group memberships if the groups and users are in different organizational units. For example, this will only work with StorCycle 4.0.1: If users have designated names like this: And groups have designated names like this: We will not be able to do group membership checking on this style of organization UNLESS the user entry explicitly lists the groups the user is in.
¶ AD/LDAP Structure that will work with StorCycle group security 3.6 and higher.Here’s the example DN’s for the setup that does work, because the groups and users share the same organizational unit. Since both john doe and managers are in ou=employees, we can look up the group and the member using the same baseDN of “ou=employees,dc=example,dc=com”.
|
¶ What is Restricted with AD/LDAP Groups?
When a AD/LDAP group is assigned to a source location only domain users who are members of the group will be able to access the location.
| Scans | Only users in the domain group will be able to initiate scans on group-protected source locations |
| Migrate/Store Jobs | Only users in the domain group will be able to initiate migrate/store jobs from group-protected source locations |
| Restore Jobs | Only users in the domain group will be able to restore data which had come from a group-protected source location |
| File Listings | File listings generated with Migrate/Store jobs will only be accessible to users who are members of group-protected source locations. |
Configuration of AD/LDAP Groups and Query Membership
When configuring either AD or LDAP for group query membership, an AD/LDAP domain must first be configured.
The Username (not required for LDAP) and password must have administrator rights to query the domain server, whether using AD/LDAP groups or not.
When adding or modifying the AD/LDAP Search query, the credentials for the AD/LDAP domain should not change and will continue to be administrator level credentials.
So, make sure you have the domain configured and working before attempting to add domain groups. One way to do this is to first configure the domain, enable the ability for domain users to log in, and try to log in with domain credentials.
After this is properly configured, the only change you potentially will make to enable storage groups will be to modify the search query.
Note: Even though the search query will be blank during configuration or edit, StorCycle has a default query that will be used which can viewed from Reports →Configuration
The default query should work for low-complex domain structures.
Administrator level credentials must be used to query the domain server - whether domain groups are used or not
¶ When/How do we Verify Group Membership?
If a Source Location has a domain group assigned, StorCycle will only query the domain server for permissions if a user tries to access it. Upon access, StorCycle will send a search query to the domain server to determine if this user is a member of the group and has access to the data. Since Administrators are never restricted, a non-existent group can be added to any source location to restrict it to Administrator-Only access. Group restrictions can also be used to create Administrator-Only sources when a domain is not configured.
Due to the varying levels of complexity of AD/LDAP deployments, the search query used to assess membership can be edited and fully replaced. This may be a requirement for some organizations.
As a best practice, Spectra Logic recommends creating domain groups specifically for storage restrictions in StorCycle, and recommends adding any users who will log-in to StorCycle into these domain group.
¶ AD/LDAP Search Query
In most cases, before making a modification to the AD/LDAP Search query, you will need to have a thorough understanding of how your AD/LDAP is structured.
Please see LDAP Search Help for guidance on understanding how your AD/LDAP server is configured
StorCycle will only query the AD/LDAP server to verify membership if a group-protected source location is accessed for scans, migrates, restores, or file listings.
¶ Example Active Directory Search Query:
(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=$groupdn))¶ Example LDAP Search Query:
"(&(objectClass=groupOfNames)(cn=$group)(member=cn=$user,ou=users,dc=default,dc=local))"
¶ Restricting by User Name instead of Group
Rather than restricting users who are in a domain group, this feature can be used to restrict a source to a single user.
Example LDAP Query to restrict to User:
(&(cn=$group)(cn=$user))Example LDAP Query to restrict User and Group Names that are the same as the User Name:
(|(&(cn=$group)(cn=$user))(&(objectClass=groupOfNames)(cn=$group)(member=cn=$user,ou=users,dc=dctest,dc=local)))(| ‘ = at least one of the queries below needs to be true.
(&(cn=$group)(cn=$user)) = both terms must be true.
Example AD Query to restrict to User:
(&(objectclass=person)(cn=$user)(cn=$group))¶ View Default Search Query
The AD/LDAP search query which is currently in use can be found in Reports → Configuration, under the AD/LDAP Settings section.
¶ Modify Search Query
If making use of domain groups, the only modification to domain configuration will potentially be a change to the search query. You do not need to change any of the configuration information such as credentials, BindDN, etc. In most cases, the default search query will work without modification.
To change or modify the existing search query, navigate to Gear Icon → Configuration → AD/LDAP Settings. On the bottom of the second page of the AD/LDAP Settings wizard you will find the text field, “User/Group Membership Query”.
To change the query, paste or type a full query which will replace the existing. For example, you could paste: "(&(objectClass=groupOfNames)(cn=$group)(member=cn=$user,ou=users,dc=dctest,dc=local))" and it will replace the existing query in full.
¶ Adding Group to Source Locations
AD/LDAP groups are added to Source Storage locations during creation or edit.
The Group field is available on Page 3 of the Storage Location wizard.
