Using the Intermapper Authentication Server

Use the Intermapper Authentication Server to authenticate Intermapper users through an external authentication directory.

The Intermapper Authentication Server (IMAuth) is a component of the Intermapper DataCenter (IMDC) add-on package. It allows an Intermapper server to authenticate users against an external authentication directory. IMAuth supports LDAP, RADIUS, ActiveDirectory, IAS, and Kerberos directories.

IMAuth acts as an intermediary between an Intermapper server and the directory. If an authentication request comes in from a user whose password is not in Intermapper’s local user database, the Intermapper server forwards that request to IMAuth. IMAuth translates and passes the request to the directory server, and forwards any responses it receives back to the Intermapper server. In addition, a new user entry is created in the local database, configured for external authentication and assigned to a default group that you specified for users created this way.

IMAuth is not a replacement for Intermapper's local user database. You can continue to keep some user passwords in Intermapper's local user database for local authentication while requiring others to be authenticated using IMAuth. For each user, you must choose one method or the other.

Select the Use External Authentication check box in the Edit User or Create User dialog to indicate that the user should be authenticated using IMAuth, in which case you should not supply a password. For more information on creating and editing users, see Users and Groups.

Installing the Authentication Server

Intermapper Authentication Server runs as a component of Intermapper DataCenter and is installed automatically when you install Intermapper.

Configuring and Connecting to Your Directory

You need to configure the Intermapper Authentication Server to talk to your directory server. This is done from Intermapper DataCenter's web administration page. To do this, start IMAuth Server as described above, then open a web browser and navigate to: https://localhost:8182. You can also click Configure in the Reports Server pane of the Server Settings window.

  1. Configure the connection to your authentication directory (LDAP, Radius, ActiveDirectory, Microsoft IAS, or Kerberos v5).
  2. Configure the connection that an Intermapper server uses to connect to IMAuth.
  3. Configure Intermapper to connect to IMAuth.

Tips and Hints for Various Authentication/Directory Servers

RADIUS/IAS

IMAuth acts as a RADIUS client, so it must be added to the clients section of your RADIUS configuration file or, for Microsoft IAS, the clients section of the IAS configuration pane. You are asked to specify a secret and must enter the exact same secret in the IMAuth RADIUS settings.

LDAP

You can authenticate with LDAP using port 389 with or without SSL. To connect with LDAP on port 389 with a plaintext connection, leave the Use SSL check box cleared. To connect with LDAP on port 389 with an encrypted connection, select the Use SSL check box.

You can authenticate with LDAP on port 636, which is an encrypted connection by default. This means the Use SSL check box has no effect when using port 636.

NOTE: In a future version of Intermapper, the Use SSL check box is disabled when port 636 is being used for LDAP authentication.

If you encounter any problems, first try clearing the Use SSL check box, or choose Whenever Necessary for the Use Plaintext option in the IMAuth LDAP settings. If this works, it means your server was not built to include SSL or SASL DIGEST-MD5 password encryption. You need to either stay with the lower IMAuth security settings or upgrade your LDAP server.

Another thing to look at is the LDAP Base DN specified in the IMAuth LDAP settings. This tells IMAuth where in your LDAP directory the user entries are located. This depends on how your directory is set up, but usually takes the form: ou=people,dc=example,dc=com, where example and com correspond to the domain name your directory is set up with. IMAuth takes the Base DN and attaches the user's name; for example, cn=Jane,cn=Smith,ou=people,dc=example,dc=com.

ActiveDirectory

ActiveDirectory is based on LDAP, but differs slightly in its default configuration. If you are encountering problems with these ActiveDirectory versions, try clearing the Use SSL check box or choosing Whenever Necessary for the Use Plaintext option in the IMAuth LDAP settings.The Base DN for an ActiveDirectory server is almost always be: cn=Users,dc=example,dc=com where example and com are replaced by the name of the Windows Domain that ActiveDirectory is serving.

Since ActiveDirectory is built around the idea of domains rather than single servers, the username you use to authenticate must have your domain name attached to it. For example, if your normal Windows logon name is janesmith and your domain is example.com, the username you give when accessing a map with Intermapper or Intermapper Remote Access is janesmith@example.com.

Almost all ActiveDirectory versions support SSL. If you provided your own certificate, choosing the Whenever Necessary option for the Use Plaintext field in the IMAuth LDAP settings does not have much impact on your security. If you really do need the additional encryption, you must perform the following steps:

  1. Log in to your server as an administrator, and start the Active Directory Users and Computers panel.
  2. Open the properties for each user who needs to authenticate, and switch to the Account tab.

  3. Under Account options, select the Store password using reversible encryption check box.

    NOTE: Microsoft Windows cannot apply the change immediately, so you must get that user to log on to the Windows domain as normal (by signing on to their machine, for example) before the change becomes active.

In this case, you might again need to use a different username. Instead of the usual login name, you might need to use the user's full name. For example, instead of janesmith you use Jane M. Smith.

When setting up IMAuth, it is a good idea to try the normal login name, the login name with your domain attached, and the user's full name, to see which login your ActiveDirectory server accepts.

Kerberos

For an introduction to Kerberos, see the following Knowledgebase article:

Problems encountered when using Kerberos are usually caused by misconfiguring the Intermapper Authentication Server, or by the values used when creating the imauth service account.

  • Kerberos Domain - The name, of the Kerberos authentication realm. It is typically all uppercase (for example, Intermapper.COM). On Windows, it is almost always the same as the ActiveDirectory domain's name, but upper-cased.
  • KeyServer Address - The full domain name of the Kerberos key server. On Windows, even on complex networks with multiple ActiveDirectory nodes, only one acts as the Key Distribution Center. The KeyServer Address value must match the machine's name exactly. For example, if the machine is registered on the network as ad.Intermapper.com, the KeyServer Address must be ad.Intermapper.com; entering the IP address of the machine, or just ad, causes authentication failures.
  • Service Principal - The service principal name associated with IMAuth on the domain. This is typically the service name (imauth) followed by a forward slash (/) and the Kerberos key server full domain name. For example, on Windows, assuming you follow the instructions in the Knowledgebase link above and created an ActiveDirectory service account called imauth, the Service Principal value is imauth/ad.Intermapper.com. This user account must also be active in ActiveDirectory; disabling the account is a common mistake that causes authentication failures.