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 lets an Intermapper server 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 you will have specified for users created this way.

IMAuth is not a replacement for Intermapper's local user database. You may continue to keep some user passwords in Intermapper's local user database for local authentication while requiring others to be authenticated via 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 via 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, and 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 then enter exactly the 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 checkbox unchecked. To connect with LDAP on port 389 with an encrypted connection, select the Use SSL checkbox.

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

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

If you encounter any problems, first try clearing the Use SSL checkbox, or choose Whenever Necessary for the Use Plaintext option in the IMAuth LDAP settings. If this works, it means your server wasn't built to include SSL or SASL DIGEST-MD5 password encryption. You'll 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 was set up, but usually takes the form: ou=people,dc=example,dc=com, where example and com correspond to the domain name your directory was 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 checkbox or choosing Whenever Necessary for the Use Plaintext option in the IMAuth LDAP settings.The Base DN for an ActiveDirectory server will 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 have provided your own certificate, choosing the Whenever Necessary option for the Use Plaintext field in the IMAuth LDAP settings doesn't have much impact on your security. If you really do need the additional encryption, you must perform these 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 may need to use the user's full name. For example, instead of janesmith you would use Jane M. Smith.

When setting up IMAuth, it's 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 a good 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 (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 then the Kerberos key server's 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 would be 'imauth/ad.Intermapper.com'. This user account must also be active in ActiveDirectory; disabling the account is a common mistake that causes authentication failures.