Restricting Access to Components

The administrator can restrict access to LISTSERV Maestro in two different ways. The first way of restricting access is based on the IP address of the computer (where the browser is running) that is used to access the component. The second way of restricting access is to disallow concurrent access with the same user account. This will limit users from logging in twice with the same user account at the same time.

Each of the LISTSERV Maestro components (Administration Hub, Maestro User Interface, Maestro Tracker, and the subscriber access pages for hosted datasets) can be configured to restrict access based upon the IP address of the computer that is used to access the component where the browser/email-client is running. This means that it is possible, for example, to define that everyone (all IP addresses) is allowed to access the Maestro Tracker component, but only certain IP addresses (a local subnet, perhaps) are allowed to access the Maestro User Interface and Administration Hub components. If access is not allowed for a certain address, then a client from that address will receive a
403: Forbidden error when attempting to access the restricted component.

By default, no component access restrictions are in effect. To add access restrictions, it is necessary to add a new Restrict.CONTEXT.ID entry into the Tomcat INI file:

Each such entry must look something like this:

with the following replacements:

•	CONTEXT: Replace with the context name for which you want to introduce a restriction. Usually you will probably want to restrict access to the Maestro User Interface and/or the Administration Hub, for which the matching context names are “lui” or “hub” respectively.

Other possible context names are “trk” and “list” (for Maestro Tracker and for the subscriber pages of hosted lists, although it usually does not make sense to restrict access for these contexts), and “archive” and “scripts” (these two being contexts used by the LISTSERV user interface “WA”).

•

ID: Replace with any ID-string that uniquely identifies the “Restrict” entry from all other “Restrict” entries in the same context. Which kind of ID-string you use is up to you, but you should limit yourself to alpha-numeric characters and make sure that you do not use the same ID-string for two “Restrict” entries with the same context name (i.e. two “Restrict” entries must at least differ in their “CONTEXT” or in their “ID” value, there must never be two entries where both “CONTEXT” and “ID” are the same).

It is important to understand that the listed IP-address ranges or addresses are the addresses which are granted access. All unlisted addresses are thus implicitly denied access to this context.

If no such restriction entry is present for a certain context at all, then access to this context is unrestricted (this is the default for all contexts after installation).

In other words: If for a context there is no entry at all, then access to that context is unrestricted. If there is at least one entry, then access to that context is restricted and access is allowed only for the addresses listed in the entry (or entries) of that context.

Important: Because of the way the Maestro Tracker functions (by accepting tracking events from mails sent all over the internet), the Maestro Tracker component must be accessible to everyone, i.e. you should not specify any restriction entry for the “trk” context. For similar reasons, you should also not specify any restriction entry for the “list” context, so that everyone has access to the subscriber pages of the hosted datasets (unless you have a policy to restrict access to these pages, for example if you are using them only for internal purposes).

After you have saved the modified tomcat.ini, you need to stop and restart LISTSERV Maestro to make it aware of the changes.

If you have distributed the components of LISTSERV Maestro to several servers, then you might need to edit the tomcat.ini file of several of these servers, depending on which components you want to restrict.

For example, if all three, the Administration Hub, the Maestro User Interface and Maestro Tracker are installed on separate servers, then you would typically not add a restriction entry on the Maestro Tracker server (since Maestro Tracker needs to be accessible to all), but you might want to add restriction entries both to the tomcat.ini of the Administration Hub (using the “hub” context) and of the Maestro User Interface server (using the “lui” context).

This would restrict access to the Maestro User Interface (“lui”) and only allow access for computers in the subnet range 192.168.1.0 through 192.168.1.255. Computers with any other IP address would not be allowed to access the Maestro User Interface.

Access to all other components (for example the Administration Hub, Maestro Tracker or the subscriber pages of hosted lists) would remain unrestricted.

This would restrict access to the Maestro User Interface (“lui”) and only allow access for computers in the same subnet range as above and additionally also for the single computer with the address 192.168.6.21.

Also, access to the Administration Hub (“hub”) is restricted and access is allowed only for this one same computer with address 192.168.6.21.

Access to the Maestro Tracker, the subscriber pages of hosted lists, and the LISTSERV Web interface (if being served by LISTSERV Maestro) remains unrestricted.

If there is an organizational reason or policy that dictates this restriction, the administrator has the option of allowing or disallowing users to log in twice with the same user account at the same time. The default setting does allow concurrent access. This restriction should only be used in special cases and with an understanding of the problems associated with using it.

There is usually no reason to disallow concurrent access to LISTSERV Maestro. If two users are logged in with the same account from different workstations, Maestro handles each login session separately; therefore, the two sessions will not interfere with one another. If multiple users need to access and manipulate the same data, then it is generally a better idea to assign separate accounts in the same group to each user rather than allowing them to share a single account. Doing so not only eliminates the need to disallow concurrent access, but it also allows for more detailed logging (i.e. log files that show which user performed particular actions).

To change the default to disallow concurrent access, click on the Global Settings menu, select Maestro User Interface, and then select General Administration. The General Administration of Maestro User Interface screen opens. In the Runtime Administration section, check Disallow multiple logins with the same user account.

Important: Disallowing concurrent access with the same account is not recommended. If it is necessary for some reason, please pay attention to the warnings issued below about potential problems associated with the use of this feature.

Disallowing concurrent access will affect the behavior of the Maestro User Interface. If a user logs in with a certain account, and another user is already logged in with the same account, the system will not accept the second login right away, but will instead do the following:

•

If the second login attempt comes from a different workstation, the user attempting the second login is given the message “Logon failed: Someone is already logged in with the given account from a different workstation. Please use a different account for login.” The user is not logged in. However, the user may still use a different account that is not currently in use to log in.

•

If the second login attempt comes from the same workstation, the user is informed that a previous session is already active from the same workstation. The user is then asked whether to cancel the second login, or proceed with the second login and log out of the previous session. If the user cancels the second login, the previous session will be unaffected, but the second login attempt will fail. If the user does not cancel the second login, the previous session will be logged out and the second session will log in.

A second login attempt from the same workstation may happen in situations similar to these:

•

A user has one browser window open, in which the first login session is active. The user opens a second window and tries to log in again with the same account. In this case, the user will be notified that there still is a session open from the workstation and that proceeding with the second login will log out that first session. Most users will probably cancel the second login instead and continue using the first session.

•

A user has been using a first login session in a browser and has closed the browser without logging out properly. Since the system has no way of knowing that the user has closed the browser, it will still keep the user’s login session active. Since the browser is closed already, the user has no way of “going back” to that session to log out properly.

•

This is usually not a problem, since the system will log out the session automatically after a certain timeout period has passed (usually 90 minutes). However, if in the meantime the user opens a new browser window and tries to log in again with the same account, the user will be notified that there is already a session logged in from the workstation, and that proceeding with the second login will automatically log out that first session. Since the first session is the one that the user no longer has access to, the user will proceed with the second login.

LISTSERV Maestro makes the determination of whether a second login attempt comes from the same or from a different workstation by looking at the IP address of the workstation used to make that attempt.

This approach has some caveats of which to be aware (illustrated in the scenarios below).

Problem Scenario #1: NAT Access

If a group of users is accessing the Maestro User Interface using a local subnet with local addresses, and a router with NAT (Network Address Translation) or some other method of address mapping is used to connect to the Internet, and the Maestro User Interface is on the “other” side of that router, then to the Maestro User Interface, all users will appear to be using the same workstation, since they will all have the same IP address, namely that of the router.

In this case, the Maestro User Interface will handle all login attempts as if they were originating from the same workstation, which may result in the following confusing or even harmful situation. One user is logged in with an account from workstation A. Now another user tries to log in with the same account, only from workstation B. Both workstations will appear to the Maestro User Interface as one and the same, since both will be using the same IP address externally. The result is that the second user will be notified that there is another session already active from the workstation with the same account. The user will have the option of proceeding with the login and canceling the previous login. This other session would in fact be the session of the first user and by logging in, the second user would log out the first user, disrupting the workflow.

To work around this situation, make sure that all users are using different accounts, and that the passwords are kept secret, so that no other user can use a colleague’s account to log in from a different computer and thus log out that colleague.

Problem Scenario #2: Dial-Up Access

If a user is connected to the Internet with a dial-up modem connection as provided by most ISPs, the workstation’s IP address is usually assigned dynamically each time the user connects, meaning a different IP address will be assigned each time a connection is made. This may cause the following situation to happen:

The user opens a browser and logs into the Maestro User Interface with a certain account. The user then closes the browser without logging out properly, so that the session will continue to be active until the timeout has expired. The user then disconnects the Internet connection. Shortly thereafter, the user reconnects to the Internet, opens another browser, and tries to log in with the same account. This time, the user is very likely to be assigned a different IP address from the previous connection. The Maestro User Interface will interpret this as a different workstation logging in to the same account. As a result, the Maestro User Interface will report that the account is currently in use from a different workstation and will not accept a login with that account.

The user now has no choice but to wait for the 90 minutes timeout to expire, before logging in again with the same account. To cancel the previous login, the user would have to access the Maestro User Interface using the same IP address as before, which is extremely unlikely with this kind of dynamic address assignment. To avoid this problem, the user should always remember to log out properly. If the browser is closed accidentally without logging out, but before the modem is disconnected, a new browser session should be opened so that the user can log in again, canceling the previous session, and then log out properly.

To moderate this problem, the administrator may configure the session timeout of the Maestro User Interface to be shorter than the default of 90 minutes, so that in the worst case, the user does not have to wait as long to log back in.

The timeout for the Maestro User Interface is configured in the following file:

The value of 90 determines the session timeout in minutes. Set it to a suitable value, save the file and restart the Maestro User Interface.

The same setting can be changed for the Administration Hub by editing the file

A dictionary attack is a technique to gain illegal access to a system by employing a list of words in a dictionary automatically to determine the login password for a given user account. The effectiveness of such an attack can be reduced by only allowing a limited number of invalid login attempts and by locking access to the account for a certain time. (Locking means that the login is denied even if the correct password is supplied.) LISTSERV Maestro supports this form of login locking in the Administration Hub and in the LISTSERV Maestro User Interface component.

To secure the administrator’s account of the Administration Hub, click on the Global Settings menu, select Administration Hub, and then finally select General Administration. In the Advanced Security Options section, enter the maximum number of unsuccessful login attempts and the login locking time in minutes.

If the administrator’s account is already locked due to too many login attempts and the configured login locking time is very long, supply the following value in the hub.ini file:

Then, retry to login as administrator’s with the correct password. Login access is enabled again and the entry from the hub.ini file has been removed. If a system restart is an option (e.g. because currently no important mail job deliveries are being processed), then restart the system to unlock access again.

To secure all accounts of the LISTSERV Maestro User Interface, click on the Global Settings menu, select Maestro User Interface, and then finally select General Administration. In the Advanced Security Options section, enter the maximum number of unsuccessful login attempts and the login locking time in minutes.

If any LISTSERV Maestro User Interface account is already locked due to too many login attempts, click the [Unlock all currently locked accounts] button. If a system restart is an option (e.g. because currently no important mail job deliveries are being processed), then restart the system to unlock all locked accounts again.