Applicable Versions: 4.5 to 5.5. Please see the article for v6.0
This article describes how DataPA Enterprise can be configured to use MS Active Directory (“AD”) for user authentication, and assigning users to groups.
1. Set-up Authentication AppServer
The authentication will be performed by a Progress AppServer.
This should NOT be an existing AppServer used as a data sources by DataPA; it should be a separate AppServer dedicated to user authentication.
It does not therefore require any database connections (unless your logic requires it to assign users to groups); however, it will require access to the MS Active directory installation against which authentication will be performed.
The AppServer should have the following properties:
• Operating mode: Stateless
• The appropriate DataPA*.pl procedure library in it’s PROPATH.
• PAAuthenticateAD.p set as the connect procedure (Agent --> Advanced features) and this must be present in the PROPATH.
• A version of PAUserGroup.p in the PROPATH, even if it is the default version provided with DataPA.
Also the DataPA Enterprise Service will need to be able to connect to it.
PAAuthenticateAD.p can be found here:
An initial version of PAUserGroup.p can be found in the "Server Procedure Examples" folder located in the "DataPA OpenAnalytics" directory created under your Start menu by the DataPA installation.
2. Set-up DataPA
2.1. General Set-up
Start the dashboard designer, logging in as an admin user (if you don’t have user security enabled already, enable it – “Application Settings” tab --> “Manage Server” button).
Admin users bypass the authentication we are about to set-up (so you don't need to add them in AD). This stops you getting in a situation where nobody can access the set-up screens we are about to use, however access to this group should be restricted as far as possible.
It is assumed that you have already set DataPA’s data location to “Stored on a DataPA Enterprise Server” (“Application Settings” tab --> “Security” button).
2.2. Manage Server screen
You should have the options illustrated below selected at a minimum. i.e.
• Apply user security
• Use an AppServer connect procedure to validate users
• Use a business logic procedure on the server to assign users to groups
Use the “...” button to build the AppServer Connection string.
On the “General” tab enter the AppServer connection details, on the “Advanced” tab we need to specify the required active directory details...
In the AppServer Information field we add a pipe (“|”) delimited set of parameters, these are passed to the AppServer connect procedure – PAAuthenticateAD.p – to perform the authentication (using Windows API calls that implement the LDAP interface to AD).
The parameters are
- AD Host. The machine hosting the Active Directory installation against which authentication is to be performed.
- The DN (“Distinguished Name”) of the Active Directory “root” node under which to search for users and groups *.
- The DN of the User to perform the searches of (2) *.
- The password for the user of (3).
- Optional. A list of AD groups, specified by their common name (“CN”), at least one of which a user must be a member of to be authenticated. If multiple groups are specified they must be comma delimited. If this list is empty users need not be members of any particular group to be authenticated, however the groups of which they are a member are still stored (in SESSION:SERVER-CONNECTION-CONTEXT) so as to be available to the logic of assigning users to groups later (see 2.3 Managing Groups).
- Optional. Set this option to TRUE to enable verbose logging in the authentication procedure. This can be useful if you are having problems. The logging appears in the AppServer server log.
* – If you have problems determining these DN properties, a tool such as “AD Explorer” from SysInternals can prove extremely useful.
Note on security: Here we are storing an admin login to your AD set-up. This information is encrypted and stored in a proprietary DataPA binary format which is secure. You should ensure the non-administrator user groups do not have access to this screen (see 2.3 Managing Groups) so that they cannot access this information.
2.3. Managing Groups
DataPA creates 2 groups by default, “Administrators” and “Default”.
The former is intended to prevent you getting in a situation where nobody can access the set-up screens we used above, however access to this group should be restricted as far as possible.
The later is the group used by DataPA when no other group is assigned.
You should create additional groups for your users and assign your users to groups using the PAUserGroup.p procedure.
For example, here I have set up three groups for users: Management, Sales and Purchasing.
For the security reasons mentioned above these groups should NOT be allowed to administer DataPA this should only be done by Administrators.
You can then base your logic to assign users to DataPA groups on the AD groups of which the user is a member. Recall these groups are saved in SESSION:SERVER-CONNECTION-CONTEXT as part of the authentication process. For example:
