Group Expansion in Aspire 2.1
Group expansion in Aspire refers to the process of receiving a username and calculating from that
the full set of groups to which the user belongs. Group expansion is most often considered at the
time a search is being performed – a user has logged in to a search application with their user name
and wants to retrieve data. The data in the search engine has been secured using access control lists
and those list access control lists contain the names of users and groups that are permitted or
denied access to the item. To provide the users a comprehensive result set, covering all the
documents a user has access to, the search engine must know the groups that the user belongs to.
However, at login time, the user only provided their username and hence, group expansion is
required.
Different search applications can request group expansion with varying frequencies. Some
applications may request expansion when the user logs in whereas some may request it for every
search. The frequency with which requests are made is not specifically important, as long as the
servers are not overloaded. What is important is the speed with which the information is returned.
Aspire should be able to respond to a request in a timely manner. Whilst a request made during
login may be able to wait a few seconds, a request made during a search must be processed very
quickly.
The format of the incoming request is also important. Search applications may expect to submit
requests to an ldap server (the GSA for example) or via http. Group expansion must support both of
these request types.
There are other things to consider:




An Aspire installation will probably have multiple content repositories (Documentum,
SharePoint etc). Whilst these will quite often connect to LDAP or Active Directory and use
groups from there, it is quite possible they use groups that are unique to the content
repository and so it is important that these “local” groups are correctly handled.
If we do have multiple repositories, it’s possible that the username used in one content
source is not the same as the username used in another, so this situation must be accounted
for.
It is also possible that user and group information from differing repositories comes in
different forms (with or without a domain for example).
Finally, the username passed to group expansion could come with or without a domain, or
may not even be a “standard” username (it could be a SID/GUID for example).
The use of caching in group expansion
As mentioned above, it’s important that the requests for group expansion are processed as quickly
as possible. This would suggest that some sort of caching is required. There is a potential issue here.
What happens if you have an entry in the cache that gives the user access to a group from which he
is later removed? It is theoretically possible that he will return a search result that he can no longer
access. However, most system implementations will then direct the user to the original repository to
retrieve the document at which point the request will be rejected, so any “risk” of the user seeing
prohibited content is mitigated.
Group Expansion Process in Aspire
At the very high level, group expansion inside Aspire can be split in to two processes:


Group collection and caching
Processing expansion requests
However, the two steps noted need to be performed on a per content source basis, so the group
expansion process must include a step that that takes that single request, sends that to each of the
content sources we have installed (or at least what to perform expansion for) and merges the
results. This process is known as the Group Expansion Manager, so the high level architecture for
group expansion becomes:


Content Source
o Group collection and caching
o Processing expansion requests
Group Expansion manager
The group expansion manager will also handle conversion of requests from external sources via http
and ldap to a format Aspire can use and then to convert the responses back to the appropriate form.
The high level architecture can be seen in the diagram below:
Content Source
Content Source
Repository
Group expansion
cache
Content Source
Repository
Group expansion
cache
Repository
Group expansion
cache
Connector AppBundle
Applications needing
group expansion
Connector AppBundle
Connector
AppBundle
Group Expansion
Manager
Group Expansion
Requests
Group collection and caching
Whatever the content source, request format or frequency, the key to the group expansion process
is the ability to get the groups for a user. Since, for content source data extraction purposes, we
have already built a connector that understands how to connect to the content source and has all
the appropriate jar files for the content source API built in, we use this to collect the groups and
insert in them in to a cache.
A scheduler component will periodically send the content source connector component a job to tell
it to reload the cache. When the connector component receives this job, it will open a cache to hold
the newly downloaded groups. Then, in a separate thread (so as not to block any repository
scanning) it will connect to the repository and request:


a list of all users and the groups to which they belong, and
a list of groups and the groups to which they belong (for nested group expansion)
Once the connector has this information, it will:


Consider each user in turn and perform un-nesting of the groups, to produce a cache of
users against the (full set of) groups to which they belong.
Switch in the new cache in an atomic operation so group expansion requests are always
using a consistent cache (that is, you do not encounter the situation where expansion for
one user is the result that was cached today and for another user was cached yesterday).
Un-nesting the groups involves talking the user and looking up the groups to which he belongs and
then looking up each of the groups found and now looking to see if those are members of other
groups. This process is repeated until no new groups are found. Thus, if a user is a member of group
“one” and group “two” and group “two” is a member of group “three” and group “four”, the entry in
the cache will record the user as a member of groups “one”, “two”, “three” and “four”.
An added complication when calculating group membership is that some content source repositories
can use external groups (typically from and ldap or active directory server). These groups typically
can be members of “local” groups to the repository but are not always reported back in the list of
groups for the repository and so it can be difficult to work out what “local” groups they belong to.
Thus the connector can be optionally supplied with a list of groups from an external source. These
groups are then looked up by the connector to ensure they are handled correctly.
At the end of the group collection process, the cache will contain a consistent set of users against
the groups to which they belong. This cache will then be used to serve group expansion requests
until the next time the scheduler determines the cache should be reloaded. At this point the process
begins again.
Processing expansion requests
At the point at which group expansion needs to be performed for a user, the user will be looked up
in the cache created by the connector. The input to this process (known as a Group Expansion
Request) will be an Aspire job with particular attributes, including the username of the user to be
looked up. The response (a Group Expansion Response) will include a set of groups to be returned to
the requestor.
The cache is assumed to have already been populated and the process uses a client to retrieve the
information. Whilst the methods to write to the cache needed to understand how to connect to the
repository, the methods to read do not. They only need to be able to understand the information
needed to look up items in the cache and how to format the information returned.
Since the connector already has the cache open, we make it implement a “Group Expansion Server”
interface and have a generic client that takes the “group expansion request”, extracts the username
to look up, calls a method on the “Group Expansion Server” interface to get the groups for that user
and adds the returned groups to the “group expansion response”
Group Expansion Manager
The group expansion manager is responsible for four main areas of processing:




Receive external requests
o And return a response when all processing has been done.
Provide workflow components that allow the operator to make changes to the request and
response.
Add external group data in to the request
o See later.
Route the request to all content sources for which group expansion should be performed.
The architecture can be seen below:
ASPIRE
Aspire Content Source
Applications
LDAP Cache Service
Group Expansion Manager
Workflow
(onExpansion)
LDAP Receiver
Applications needing
Group expansion
HTTPReceiver
Workflow
(onRequest)
Add LDAP
Groups
Workflow
(afterLdap)
Request
Router
Workflow
(onResponse)
Encode
Receiving requests
The group expansion manager includes the components for receiving group expansion requests. It
publishes a servlet in Aspire with the (default) path /groupExpansion (ie
http://localhost:50505/groupExpansion). This servlet expects a single parameter (username) sends a
group expansion job in to Aspire. Once processing has been performed, the servlet will return a list
of groups to which the user belongs. Thus a call to
http://localhost:50505/groupExpansion?username=tesla
provides a response in the form:
<groups>
<group>tesla</group>
<group>scientists</group>
<group>italians</group>
<group>group1</group>
<group>group2</group>
<group>group3</group>
<group>group4</group>
<group>PUBLIC:ALL</group>
<group>xxxxxx</group>
</groups>
Note that the user itself (tesla in the above example) is returned as a pseudo group.
The group expansion manager also includes a “proxy ldap server”. This is disabled by default and
requires pre-installation of another service (Ldap group cache). When enabled, this proxy allows
search engines such as the GSA to use Aspire for group expansion. The proxy expects to receive all
requests from the engine. Requests for groups for user are intercepted. The username is extracted
from the ldap request and sent as a “group expansion request” job to the same pipeline as the http
requests. Once the expansion has been performed, the returned groups are gathered and formatted
as an ldap server response and sent back to the engine.
Requests which are not requests for groups (such as general ldap searches or login requests) are
forwarded to a “real” ldap server via an ldap connection component. This ldap connection
component is not installed as part of the group expansion manager and must be configured
externally. The ldap connection component is included in the Ldap Group Cache service (see later).
Workflow
The group expansion manager includes a number of workflow processors to allow the system
administrator the chance to manipulate the group expansion requests or responses and change
either the user to be looked up, or the groups to be returned.
Workflow rules can be added via the UI and are actioned in the following points in the process:
Workflow name Position in process
Usage
onRequest
Change or modify the user name to
be looked up
Change or modify the user name to
be looked up. Add extra external
group information
Change or modify the user name to
look up for an individual group
expander. A single request for
expansion could cause multiple jobs
in this workflow, assuming more than
one expander is configured
Modify the groups returned to the
requestor
afterLdap
Immediately after the request is
received
After external information has been
added to the request (if enabled)
onExpansion
After the request has passed
through the router, but before
the request is sent to the group
expander for expansion
onResponse
After all expansion has been
performed, before the groups are
returned back to the requester
External group data
External group data (typically from LDAP or Active Directory) information can be added during the
expansion process before the request is sent to the group expanders in the content sources. The
information is added before the expansion at the content source for two reasons:


Some legacy connectors require external groups to be provided on the request so they can
perform their expansion
Adding LDAP information at this point allows the router to use this information later in the
expansion process. Differing LDAP or Active Directory attributes to be used for lookup at
different expanders. This is particularly useful if (say) your username for one repository
different to your main username and that different username held in an LDAP or Active
Directory attribute.
Addition of external group data is disabled by default. When enabled, you must specific the Aspire
application that provides external group data. This would typically be the LDAP Group Cache (see
below)
When enabled, the following group expansion request
<doc type="groupExpansion">
<feederLabel>GroupExpander</feederLabel>
<username source="HTTPFeederServlet">tesla</username>
<aspireHttpFeederServlet fullPath="/groupExpansion" remoteAddr="127.0.0.1"
remoteHost="127.0.0.1" remotePort="52644" serverName="l
ocalhost" serverPort="50505" servletPath="/groupExpansion" source="HTTPFeederServlet">
<queryString>username=tesla</queryString>
</aspireHttpFeederServlet>
<groupExpander>
<expanders>
<route lookupAttribute="myLookupAttr"/>
</expanders>
</groupExpander>
</doc>
would have ldap information added and would then appear something like this:
<doc type="groupExpansion">
<feederLabel>GroupExpander</feederLabel>
<username source="HTTPFeederServlet">tesla</username>
<aspireHttpFeederServlet fullPath="/groupExpansion" remoteAddr="127.0.0.1"
remoteHost="127.0.0.1" remotePort="52644" serverName="l
ocalhost" serverPort="50505" servletPath="/groupExpansion" source="HTTPFeederServlet">
<queryString>username=tesla</queryString>
</aspireHttpFeederServlet>
<groupExpander>
<expanders>
<route lookupAttribute="myLookupAttr"/>
</expanders>
</groupExpander>
<ldap source="ldap">
<dn>uid=tesla,dc=example,dc=com</dn>
<mail>tesla@ldap.forumsys.com</mail>
<gidNumber>99999</gidNumber>
<uidNumber>88888</uidNumber>
<uid>tesla</uid>
<objectClass>inetOrgPerson</objectClass>
<objectClass>organizationalPerson</objectClass>
<objectClass>person</objectClass>
<objectClass>top</objectClass>
<objectClass>posixAccount</objectClass>
<homeDirectory>home</homeDirectory>
<sn>Tesla</sn>
<cn>Nikola Tesla</cn>
</ldap>
<groups>
<group source="ldap">tesla</group>
<group source="ldap">scientists</group>
<group source="ldap">italians</group>
</groups>
</doc>
Note the <ldap> section which has a number of attributes under it and the <groups> section with the
ldap groups.
Routing
Routing is the method by which a single request gets sent to multiple content sources for expansion.
If (say) you are using group expansion and have Lotus Notes, SharePoint, Documentum and
Confluence you will almost certainly have four group expanders.
Routing occurs after external group information has been added (if enabled).
When configuring routing you specify a minimum of a content source you want the group expansion
request to be sent to. You can specify as many or as few as you wish. The incoming expansion
request is replicated to produce “child” expansion requests and the “child” group expansion request
is sent (using a new Aspire job) to the desired content source (after being passed through the
workflow component).
The router then waits for the group expansion jobs to complete. The wait time is configurable but
defaults to 15 seconds. The groups from any “child” expansion requests that complete with in the
given time are added to the original request. Once all child requests have returned, or the wait time
has been exceeded, the original request, with a full set of groups, will continue and will eventually
be passed back to the requestor as a group expansion response. Any “child” requests that complete
after the wait time will be ignored
Domain Handling in the Group Expansion Manager
By default, the group expansion manager does not alter the domains of incoming requests or
outgoing responses. However, the manager allows the following options for both incoming and
outgoing domains:
Option
Leave alone
Strip
Add
Description
The username is un touched. If the username has a domain it will be left
alone. If it doesn’t, none will be added
Any domain will be removed from the user or group name
The specified domain name will be added to the user or group name
(replacing of any existing domain name)
Supplementary groups
The group expansion manager will allow you to add supplementary groups should you need to.
These groups are added after all other expansion has been performed.
PUBLIC:ALL
The group expansion manager by default adds the Aspire “PUBLIC:ALL” group. This group is used by
connectors to indicate content that is identified as public. The addition of this can be turned off if
required.
Static Groups
The group expansion manager will optionally add static groups. These are any additionally groups
that you wish to be added to expansion responses. You may configure as many as you wish by
specifying the name of the group (including domain if required) in the UI. Note that the groups are
added exactly as entered and any domain remains unaltered, even if you have configured domain
handling as described above.
LDAP Group Cache
The LDAP group cache is used in conjunction with the group expansion manager. It provides four
main areas of functionality:




Caching of information from ldap (or Active Directory)
Performs ldap group expansion
Provides ldap information for a user
Supplies a list of ldap users and groups for connectors requiring external group information
The architecture of the LDAP Group cache can be seen in the following diagram
ASPIRE
LDAP
LDAP Cache
Group Expansion
Cache
User & Group List
User Information
Cache
LDAP Cache
External group list
request & response
Connectors
LDAP Connector
LDAP Queries & Responses
Group expansion
requests & response
Group Expansion
Manager
The ldap cache can be populated using information from an ldap server, or from information
supplied via a user defined script. Use of the script allows the administrator to use PowerShell, batch
files, shell scripts or executables to write ldap information to a file in either xml or json. This
information is then read by the cache component and loaded in to caches.
LDAP Caches
All information returned by the LDAP cache component is provided from caches. There are three
caches to support the requests of other components:


Group Expansion cache
o A map of user names against the LDAP or Active Directory groups to which they
belong.
Ldap cache
o

A map of username against LDAP or Active Directory attributes for the user. Note
that all attributes are held as strings and any binary attributes will be encoded using
Base32.
User/Group cache
o A list of users and groups found in LDAP or Active Directory.
Cache Population
All three of the caches are refreshed at the same time. A scheduler periodically send an Aspire job to
the cache component which begins the process of rebuilding the caches. Once the caches are
complete, they are “swapped in” to use for cache requests. While the process of rebuilding is
ongoing, the last set of caches which built successfully will still be in use.
The rebuilding process will gather all of the users and groups from LDAP or Active DIrectory, either
by connection to a server or by running the configured script and reading its output.
During configuration, the administrator supplies the names of a number of attributes. These are
described below:
Attribute
User key
User name
Group key
Group name
Group mapping
Description
The unique identifier attribute for users. This is typically the “dn” of the user
which is made available as a “pseudo” attribute.
The attribute that holds the name you wish to use to identify the user in the
group expansion in the cache.
The unique identifier attribute for groups. This is typically the “dn” of the group
which is made available as a “pseudo” attribute.
The attribute that holds the name you wish to use to identify the group in the
group expansion in the cache.
The attribute that allows calculation of the groups a user belongs to. Typically
this is either “memberOf” or “uniqueMember”
As well as attributes, the administrator must also specify whether user objects hold references to
the groups to which they belong or if the groups hold reference to the users that are members.
This information is then used to construct a map of users against the groups to which they belong.
As ldap information is downloaded from the server, or read from a script response, it is inserted in to
a temporary cache with a key taken from the attribute specified in the “user key” or “group key”
attribute. At the end of this stage, we have a map of the unique identifiers against the LDAP or
Active Directory object themselves.
What happens next depends on whether user objects hold references to the groups to which they
belong or if the groups hold reference to the users that are members. If user objects hold references
to groups, then each user is processed in turn. The group name is taken from the value of the “group
name” attribute and the value(s) of the (repeated) attribute given as the “group mapping” are
collected. These values hold the unique identifier of the groups to which the user belongs. These
identifiers are looked up in the temporary cache to get the group objects and the names of these are
found by looking at the value of the “group name” attribute of each group. Finally (as we now have a
user name and a set of group names) the user and groups are added to the group expansion cache.
If groups hold references to users that belong to it, the process is similar, but instead the groups are
processed in turn. Their “group mapping” attribute is found to give the identifiers of the member
user objects. These users are located from the temporary cache and the names obtained from “user
name” attributes. Then the group and users are added to the group expansion cache.
When the group expansion cache is complete, we can extract information to fill the other caches –
the cache of users against ldap information and the external user and group list.
NOTE: The above assumes that the attributes are populated with values. With both server and script
processing, you must ensure that the attributes you choose are present and populated to make the
expansion work correctly.
Connection to an ldap server
If you wish to connect to an ldap server and download ldap information from there you will need to
specify the connection parameters. You will also need to specify queries to obtain all the users you
are interested in and all the groups you are interested in. Note that there is no requirement for the
query to return all of the users or groups. It only needs to return those you are interested in. For
performance reasons you should try to make the results set as small as possible.
By default, the response from the ldap queries will return all of the attributes the returned object
has. However it is unlikely that you will need all of the attributes and the cache allows you to filter
the attributes that are returned. Note however, if you choose to filter, you should ensure that the
return include the attributes you select for the user and group keys and names and for the group
mapping.
Using a script
The ldap cache can be configure to use a script to obtain its user and group information. This script
could be a Windows batch file, Power Shell or executable, or Linux shell script or executable.
When the cache rebuild begins and the ldap cache is configured to use a script, the cache
component creates an empty temporary file and passes the file name to the script. The script can
return either xml or json and should write its output the given file. The format of the xml or json is
given below.
The script can do whatever is required to gather the users and groups (for example connect to a
database, ldap server or other repository) and then write the information to the file. Once the script
completes, the ldap cache component will read the information from the file and load the groups. If
the script encounters an error, it can report this back to the component via the file.
Assuming that the processing of the file completes successfully, the temporary file is deleted. If the
ldap cache encounters an error while processing the file, the file is left on disk to aid debugging.
Xml format
If returning xml from the script, the following format must be used:
<ldap>
<users>
<user>
<attribute name="attr-u1">value1</attribute>
<attribute name="attr-u2">value2</attribute>
.
.
</user>
</users>
<groups>
<group>
<attribute name="attr-g1">value1</attribute>
<attribute name="attr-g2">value2</attribute>
.
.
</group>
</groups>
</ldap>
NOTE: you should ensure you have a value for each attribute you configure for user key, user name,
group key, group name and group mapping.
Json format
If returning json from the script, the following format must be used:
{
"ldap": {
"users": {
"user": [
{
"attribute": [
{
"@name": "attr-u1",
"$": "value1"
},
{
"@name": "attr-u2",
"$": "value2"
}
]
},
{
"attribute": [
{
"@name": "attr-u1",
"$": "value1"
},
{
"@name": "attr-u2",
"$": "value2"
}
]
}
]
},
"groups": {
"group": [
{
"attribute": [
{
"@name": "attr-g1",
"$": "value1"
},
{
"@name": "attr-g2",
"$": "value2"
}
]
},
{
"attribute": [
{
"@name": "attr-g1",
"$": "value1"
},
{
"@name": "attr-g2",
"$": "value2"
}
]
]
}
}
}
NOTE: you should ensure you have a value for each attribute you configure for user key, user name,
group key, group name and group mapping.
Specifying Group Membership
When using a script, it is possible for you to return information that defines the groups to which a
user belongs, rather than have the cache calculate it for you. To do this, make your script return a
<membership> node (as a child of the root <ldap> node).
When specifying membership, no further processing will be done and the only group expansions for
a user will be those specified. If you say user “U1” is a member of groups “G1” and “GX2”, this is
exactly what you will see in the cache, even if group “GX2” does not exist in the groups section. Even
if attributes suggest “U1” is in group “G4” this will not be shown via the cache if a <membership> tag
is used.
If you use xml, add the following format:
<membership>
<user name="user1-key">
<group>group1-key</group>
<group>group2-key</group>
</user>
<user name="user2-key">
<group>group3-key</group>
<group>group4-key</group>
</user>
.
.
</membership>
Or in json:
{
"membership": {
"user": [
{
"@name": "user1-key",
"group": [
"group1-key",
"group2-key"
]
},
{
"@name": "user2-key",
"group": [
"group3-key",
"group4-key"
]
}
]
}
}
Errors
If you need your script to report an error, return the following xml:
<error>
<description>A description of the issue<description>
<trace>Any stack trace information<trace>
</error>
Or json:
{
"error":{
"description":"A description of the issue",
"trace":"Any stack trace information"
}
}
Ldap Group expansion
The ldap cache component implements the “LDAPGroupExpansionServer” interface (extends the
“GroupExpansionServer” interface) which allows it to return user and group information from the
“Group Expansion Cache” to components (including the generic group expander client).
Ldap information
The ldap cache component implements the “LDAPGroupExpansionServer” which allows it to return
ldap information for the user from the “Ldap Cache” to components (including the generic group
expander client).
External group information
The ldap cache component implements the “ExternalGroupServer” interface allowing connector
components to attach to it and receive a list of all the know users and groups from ldap.
Group Expansion Configuration Example
Suppose you wish to configure group expansion for an Aspire system. Your system will have a CIFS
connector, SharePoint 2010 connector and a Lotus Notes connector. Group membership in the
organisation is held in Active Directory and the Lotus Notes user name is held in the “lnUserName”
attribute of the user in Active Directory. You search engine will request group expansion using http
requests.
Group Expansion Components Required
In order to provide group expansion for the above scenario, you will need to use:


The Aspire LDAP Cache Service
o You will require this service to provide Active Directory attributes to the group
expansion request in order to get the Lotus Notes username. You will also need it in
order to provide “external” groups to the SharePoint 2010 connector.
The Aspire Group Expansion Manager Service
o You will require this service in order to serve group expansion requests via http and
to route the requests to the various content source connectors to collect groups.
Installation Process
Overview
The basic order of installation to attain the configuration noted above would be:



Install LDAP Cache service
Install content source connectors
Install Group Expansion Manager service
It is possible to install the connectors before the LDAP Cache service, but you would need to revisit
the SharePoint Connector after the LDAP Cache was installed so the above order is preferable.
Detail on installing and configuring the LDAP Cache and Group Expansion Manager services is given
below
Install the LDAP Cache service
Visit the Aspire UI and log in if necessary. You will be presented with the home screen.
From here use the “settings” button on the right hand side of the screen to load the Services
console.
You should now see the following screen.
Choose “Add Service” and select “LDAP Group Cache”
The service will now load the configuration screen. This may take a moment if the connection to the
internet is slow. Once the service has been downloaded, you will see the following:
Enter a service name.
Click the “Service” tab at the top of the screen or use the “arrow” at the right of the screen to move
to the service configuration screen. You will now see the service configuration.
Fill in the Active Directory connection properties. The “Search base” is the start point in the directory
tree from where searches will be performed, and “Scope” can be set to define how far down the
tree the search will descend – either just the “search base”, the base and the next level, or the
default of the entire “Subtree”.
“User query” should be an ldap formed query that will return all of the users that you wish to cache.
Typically this will be something like “(objectClass=user)” although in our case this brings back
computer accounts and we are not interested in these, so we extend the query to exclude these
using “(&(objectClass=user)(!(objectClass=computer)))” instead. “Group query” is the query to
return all groups you wish to cache, typically “(objectClass=group)”.
Scroll the screen to see the “Mapping attributes” section. In the “Mapping attributes” fill in the
attributes that will allow the user to group mapping to be performed. You must specify the attribute
(or the “pseudo” attribute “dn”) that uniquely identifies the users and groups (the “User key” and
“Group key” entries) and the attribute that holds the value to be used as the user name and group
name (the “User name” and “Group name” entries). You also need to specify the “Group mapping”
attribute and whether the “Groups hold members”.
Finally choose the frequency with which the cache should be refreshed by setting the schedule.
Press “Save” at the top of the screen to save the configuration and load the service. Again this may
take a moment while the required components are downloaded. Once the service is installed, you
will be taken back to the services home page.
How the configuration is used
With the above configuration, when the cache refreshes, it will download all the users using the
query “(objectClass=user)” and store each returned user in a map against its “dn”. Then it will do the
same for groups using the query “(userClass=group)”. Once all the objects are downloaded, it will
consider each user in turn (because “Groups hold members” is not set, which means that user object
hold the groups to which they belong. For each user, it will retrieve all “memberOf” attributes (as
configured by the “Group mapping” attribute). Each “memberOf” attribute will hold the identifier of
a group to which this belongs. In the case of a typical Active Directory configuration, this identifier is
the “dn” of the group object. This identifier will be looked up in the map (which holds the group
objects against their unique identifier – a “dn”) and will find a group object. Once all the
“memberOf” attributes have been considered, we will have a list of all the group objects. We can
then establish the names of the users and groups from the objects we have by finding the value of
the “sAMAccountName” attribute (as configured in the “User Name” and “Group Name” entries).
Once all the above is complete, we will have a user name and a list of group names and this
information will be inserted in to the cache.
Install the Connectors
Installing the connectors is not covered in this guide. Refer to the appropriate documentation. Note
however, that when you install the SharePoint connector (or any other that requires external
groups) you should configure it to use the LDAP Cache service for external groups.
Install the Group Expansion Manager service
Having installed the connectors, return to the home page. You should now see something similar to
this:
Using the “settings” button on the right hand side of the screen to load the Services console.
This will return you to the following screen:
Select “Add service” and then the “Group Expansion Manager”
The service will now load the configuration screen. This may take a moment if the connection to the
internet is slow. Once the service has been downloaded, you will see the following:
Enter a service name:
Click the “Service” tab at the top of the screen or use the “arrow” at the right of the screen to move
to the service configuration screen. You will now see the service configuration. In order to use Active
Directory you must configure the group expansion manager with an LDAP Cache. Use the “LDAP
Cache” drop down and select the LDAP cache you installed earlier.
Scroll down to configure the “expanders” – the content sources to which the expansion request will
be sent. Add the “SharePoint” connector and the “Notes” connector, by pressing the “Add” link
under “Expanders” and select the connector from the drop down. You don’t need to add the “CIFS”
connector as this only uses “Active Directory” groups and and we have those by virtue of having
checked the “Attach LDAP Groups” and configuring the “LDAP Cache”.
As you add the “SharePoint” connector, you can leave the “Lookup Attribute Path” blank, as we
want to use whatever username is passed to us on the original group expansion request. However,
for the “Notes” connector, we want the username looked up to be taken from the user’s
“lnUserName” LDAP attribute. When connected to the “LDAP Cache”, all the LDAP attributes for the
user are added to the expansion request under the path “/doc/ldap”. As we want to look up the
“lnUserName” attribute for the “Notes” expansion, we add a “Lookup Attribute Path” of
“/doc/ldap/lnUserName”.
Once the “Expanders” are configured, press “Save” at the top of the screen to save the configuration
and load the service. Again this may take a moment while the required components are
downloaded. Once the service is installed, you will be taken back to the services home page.
The configuration of the group expansion is now complete.