This chapter describes how the Queue Manager is configured so that it can provide SASL authentication for SOM protocol connections.
8.1
Overview
From R16.0 onwards, M-Switch's Queue Manager can use the Simple Authentication and Security Layer (SASL) to provide authentication for connections which use the SOM (Switch Operational Management) protocol. Either the Directory or a simple XML table can be used for storage of SASL ids, passwords and associated access rights. This chapter will describe how the Queue Manager is configured and makes use of these other resources.
8.2
SASL Authentication
8.2.1
SASL Identifiers
A SASL identifier is a string which resembles an Internet email address, e.g. user@domain. The @domain may be absent, in which case a default domain which depends on the server's configuration will be assumed. Whether a SASL identifier is actually usable as an email address depends on configuration which is outside the scope of this section.
See Section 6.1, “Managing Internet Mailboxes” for a description of how to configure Internet Users.
8.2.2
SASL Mechanisms
A number of different SASL mechanisms are available. Standard mechanisms are CRAM-MD5, DIGEST-MD5, SCRAM-SHA1, PLAIN and LOGIN: these all work without the need for additional (external) resources. Support for GSSAPI (i.e. Kerberos-based authentication) and NTLM is provided, but these rely on external configuration and will be described later. The SCRAM-SHA1, PLAIN and LOGIN are the only mechanisms which will work when password hashing is being used (i.e. the Directory in which passwords are being held was created with SCRAM-SHA1 hashing enabled).
8.2.3
Use of Directory
A number of attributes located in the DSA’s configuration entry (cn=core,cn=config)
control the algorithms used when locating the authentication and authorization information for a given SASL id. The Queue Manager reads these attributes (or uses defined default values when they are not present). The most important attributes used are:
• The isodeSaslGenericRule attribute controls the search strategy used to locate a user's entry, given their SASL id. The default value of 3 indicates that a single search operation should be performed.
• The isodeSaslGenericFullMatchAttr attribute specifies the attribute type which should be used when searching on a SASL id. The default value is mail.
• The isodeSaslGenericBase attribute specifies the DN of the search base which should be used. The default is to search from the base of the DIT.
Once the search strategy and attributes used have been determined, the Queue Manager searches the Directory for information which can be used to authenticate the specified SASL id. Access control considerations mean that both the Queue Manager’s initial access to the DSA’s configuration entry and the subsequent searching/reading of entries containing authentication information will probably require the Queue Manager to bind to the Directory as a privileged entity, particularly as read access to userPassword attributes is required. If you are using a DSA which has been created using one of the standard Isode templates, then a userid (e.g. "cn=Isode Application Server,cn=Users,o=Messaging") with the necessary rights will already exist, and the Queue Manager will already be configured to use this.
8.3
Configuration Using MConsole
8.3.1
Configuration of Queue Manager
Fields on the Lookup tab for an MTA in MConsole allow configuration of the Directory entry which holds the SASL configuration and the authentication details which the Queue Manager will use when binding to the Directory to read this entry and perform SASL authentication of incoming SOM connections.
Figure 8.1. MTA Lookup Tab
The same configuration details are also used by the MTA's SMTP server to enable it to provide SASL authentication of inbound SMTP connections.
Fields on the Security tab control the Queue Manager's use of SASL for the SOM protocol, and also whether insecure SASL mechanisms (PLAIN and LOGIN) are allowed for all connections, are never allowed, or are only allowed when an encrypted connection is in use.
Figure 8.2. MTA Security Tab
8.3.2
SASL User Management
SASL Identifiers and the associated credentials and authorization data can be managed using two different MConsole Views, depending on whether you are accessing a pure X.400 configuration or an Internet/MIXER configuration. For pure X.400 configurations the Authenticated Entities Management view is provided, while on Internet or MIXER configurations the Internet Mailbox Management view is available as well.
8.3.2.1
Authenticated Entities Management View
The Authenticated Entities Management view allows SASL identities which are only to be used for Queue Manager SOM authentication to be created, modified and deleted. These identities have a password and an attribute which specifies the set of SOM operations which this identity is authorized to perform. Either a coarse choice (Full, Restricted or None) can be made, or a fine-grained selection of the specific set of operations available to the identity can be made via the "Specific controls" selector.
8.3.2.1.1 Access Control Groups
As each SASL identity has a DistinguishedName (DN), it is possible to use the DN and password for any identity in a Directory Bind operation to access the Messaging Configuration from MConsole. The Access Control Groups tab for each user on the Authenticated Entities Management view allows an individual SASL identity to be assigned as a member of various pre-defined groups, granting different levels of access to different areas of the Directory Information Tree.
For example, if you wanted to allow "John Smith" to run MConsole in a mode where he could inspect the configuration but not perform any modifications, you would need to: • Run MConsole, connecting to the Directory as the "Initial Directory User" identity. • Open the Authenticated Entities Management view and create a new SASL identity,
e.g. [email protected]
• Click on the newly-created SASL identity and select the Access Control Groups tab. Add the "Messaging Configuration Viewer" group into the "Selected Groups" column, and press the Apply button.
• Selecting the newly-created SASL identity on the left-hand tree and clicking the right-hand mouse button will cause a pop-up menu to be displayed: the "Copy DN" menu item will copy the DN of the selected entry into the paste buffer, from where it can easily be pasted into a new Bind Profile.
• To create the new Bind Profile, go to Switch Configuration Management view and select Messaging then DSA Profile Editor. From here you can select New to add a new bind profile, enter all relevant values and paste your copied DN into the Bind DN value box. Once finished you can select Connect to connect to the directory using your new bind profile.
• Using the new Bind Profile, connecting to the Directory as "John Smith", will now give read-only access to the Messaging Configuration.
8.3.2.2
Internet Mailbox Management View
The Internet Mailbox Management View allows SASL identities which are associated with M-Box and File Transfer by Email mailboxes to be created and edited. These SASL identities which are associated with Internet Message Store and File Transfer by Email mailboxes to be created and edited. These SASL identities can have SOM access rights and access control group membership in exactly the same way as those displayed on the Authenticated Entities Management view.
8.4
Advanced configuration
Some advanced aspects of Queue Manager authentication can only be configured via PP Internal Variables. These can be set using the Advanced tab for the MTA in the Switch Configuration View.
8.4.1
Allowing Anonymous Access
The PP internal variable qmgr_anon_rights allows the rights for anonymous SOM connections to be assigned. The value of the variable should be a space or comma separated list of the rights assigned to anonymous connections. The available values are:
• full Full read and control access • restricted Read-only access
• none No access - the default: anonymous connection attempts will be rejected. • qread Read Queue Manager status
• qctl Control Queue Manager • qstop Stop Queue Manager • qmsgctl Control messages • msgviewView messages • ckadr Check addresses • submit Submit messages • logviewView log files
8.4.2
Restricting SASL Mechanisms
When a SOM client connects to the Queue Manager and initiates a SASL dialogue, the Queue Manager will offer a list of the SASL mechanisms it supports. The list of mechanisms depends on the set of installed SASL plugins, and may include some mechanisms which will not work without further configuration. Two examples are GSSAPI, which requires a Kerberos domain controller, and NLTM.
The ordering of mechanisms in the list reported by the Queue Manager is undefined. By default, MConsole will attempt to authenticate using the first SASL mechanism in this list; this may result in authentication failure when GSSAPI or NTLM is at the start of the list. To overcome this problem, it is possible to limit the set of mechanisms provided by setting the sasl_mech_list PP internal variable to a space separated list of the mechanisms to be used. The actual set of mechanisms used will be the intersection of the members of this list with the set of mechanisms provided by the installed plugins.