InterMapper Authentication Server
The InterMapper Authentication Server (IMAuth) allows an InterMapper server to authenticate users against a name directory. IMAuth acts as an intermediary between an InterMapper server and the directory, and supports Kerberos, LDAP, RADIUS, ActiveDirectory, IAS and DND directories.
When an authentication request comes in from a user who has been configured as "external", the InterMapper server will forward that request to IMAuth. IMAuth translates and passes this request on to the directory server, and forwards any responses it receives back to the InterMapper server.
Note that IMAuth is not a replacement for InterMapper's local user database. Access permissions are still obtained from the local database, and if a user has not been configured as "external", InterMapper will use the local database for authenticating the user rather than contacting IMAuth. If a user has a different name on the directory server than in the internal database, a new user entry will be created. You will need to re-assign any access controls or permissions to that new user entry. New entries are also added to a group which you specify when configuring IMAuth access in InterMapper, and inherit that group's permissions.
Configuring IMAuth
You must first install the InterMapper DataCenter. Read the InterMapper DataCenter Tech Note for details. The IMDC presents a list of services, including one for IMAuth.
Click on the link in the IMDC to walk through a short series of steps.
Select a directory server type (LDAP, Active Directory, Radius, Open Directory, IAS, etc.)
Specify the IP address/DNS name and port for the specified server. There is a facility for testing the configuration on that page.
Open InterMapper Server settings, and tell the InterMapper server to use IMAuth.
Configuring IMAuth for Various Directory Servers
This section gives information about configuring the AuthServer to use the following types of directory servers.
Kerberos is the most secure protocol supported by IMAuth. Rather than forwarding a user's name and password, IMAuth acts as a kerberized service. InterMapper Remote will obtain a Kerberos ticket (or use an existing one if the user already has one). It then sends a Kerberos service access request to IMAuth, which verifies that the ticket is valid and grants the user access.
However, if Kerberos is used, it will only apply to authentication attempts from InterMapper RemoteAccess. Authentication attempts from the web or telnet interfaces are unable to use Kerberos. If you need to authenticate from the web or telnet interfaces, you will need to select ActiveDirectory or IAS authentication instead.
Like any other kerberized service, IMAuth requires a service principal key on your Kerberos server. You will need to export this key in an MIT-Kerberos-compatible keytab file. This is done with the 'kadmin' utility in MIT Kerberos (or systems based on it, like Apple's OpenDirectory).
If you are using a Windows Server 2003 ActiveDirectory Kerberos KDC, you should use the 'ktpass' tool to export the service key as a keytab file. You must use the Service Pack 2 version of the ktpass tool, because the version distributed with Service Pack 1 has a critical flaw that prevents keytabs from being exported properly. You can download the Windows Server 2003 Support Tools for Service Pack 2, which includes a working ktpass.exe, from this page:
Windows Server 2003 Support Tools SP2
To create the keytab file, first create a user called 'imauth' in ActiveDirectory. Then, run ktpass.exe with these options:
ktpass.exe -princ imauth/hostname@NT-DNS-REALM-NAME -mapuser account -pass password -out imauth.keytab
Where hostname, NT-DNS-REALM-NAME, account and password are replaced by your AD server's host name and realm, and the username and password you created in step 1.
More detailed information can be found at this page:
Once you have created the service principal key and exported it, you can use the IMAuth web admin panel to upload the keytab file for IMAuth to use.
Keep in mind that, due to the way service principal keys are generated, each time you export the key it will change. So whenever you create a keytab using kadmin or ktpass, you must upload this new keytab to IMAuth. Otherwise the key in the KDC's database and the key IMAuth stores will be different.
As with any other kerberized application, authentication will fail unless the system clock on the machines running InterMapper RemoteAccess are synchronized to the time on your Kerberos KDC.
IMAuth acts as a RADIUS NAS, 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 will be asked to specify a secret, and must then enter exactly the same secret in the IMAuth RADIUS or IAS settings.
If you encounter any problems with LDAP, first try un-checking the Use SSL option or choosing Whenever Necessary for the Use Plaintext option in the IMAuth LDAP settings. If this works, it means your server wasn't built or configured to include SSL or SASL DIGEST-MD5 password encryption. You'll need to either stay with the lower 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 it will usually take 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 is based on LDAP, but differs slightly in its default configuration. Versions included with Windows 2000 or earlier may not support all features. So if you are encountering problems in that case, try un-checking the Use SSL option 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.
ActiveDirectory should almost always support SSL. Therefore, choosing the Only when using SSL option for the Use Plaintext field in the IMAuth LDAP settings will not greatly affect your security. If you do need the additional encryption, perform these steps:
- Log into your ActiveDirectory server, and start the Active Directory Users and Computers panel.
- Open the properties for each user who needs to authenticate, and switch to the Account tab.
- Under Account options, check the Store password using reversible encryption box. Note: Windows cannot apply the change immediately, so you must get that user to log onto the Windows domain as normal (by signing onto their machine, for example) before the change becomes active.
Since ActiveDirectory is built around the idea of domains rather than single servers, the username you use to authenticate may be different from your Windows login name. The exact form depends on how your server is configured, and whether you are using SASL encryption or not. If you are having trouble authenticating, try these variations of the user name:
Plain username (i.e. janesmith)
User's full name (i.e. Jane M. Smith)
Username with the ActiveDirectory domain attached (i.e. janesmith@example.com)