Authentication is proving the identity of someone or of a process; authorization is what that person or process is allowed to do. This chapter describes the configuration of both of these elements in M-Switch.
This chapter also describes how the secure storage of passwords can be achieved.
18.1
Authentication
18.1.1
Queue Manager authentication
Management tools like MConsole connect to Queue Manager. This is described in
Section 8.1, “Overview”.
18.1.2
Message Store authentication
You can set passwords for an X.400 Message Store User. When creating a user the Advanced button gives access to the Further User Properties window with a Passwords page.
MTS Password
This is the password to be used to bind to the MTA for message submission. Note that the Message Store binds to the MTA as the user.
MS Password
This is the password which authenticates the user to the Message Store.
18.2
Authorization
The authorization mechanisms in M-Switch allow you to permit or block messages in a rule based manner. This takes place in a separate way from routing or other decisions about how messages may be handled.
The M-Switch authorisation system is a complex and flexible subsystem which is designed to allow administrators to configure many different policies into the MTA. For the most part administrators need only use the authorisations system in a very simple way. These are
• prevention of SMTP relay
• enable archiving of messages that pass through M-Switch
• use different SMTP internal and SMTP external channels based on table of trusted MTAs When creating an Internet MTA, each of these three is configured for you in a way that is likely to meet the needs of the majority of Internet configurations. If you need a more complex configuration you should use the M-Switch Advanced Administration Guide.
Figure 18.1. Default MTA authorisation rules
The three rules configured set up the MTA to carry out the authorisation checks generally required so that the MTA operates in an appropriate manner.
18.2.1
Message Archiving
There are two ways in which Messages can be configured to be archived as they enter the MTA:
• Archived to disk • Archived to an address
By default M-Switch is configured to archive messages to disk. However, you can configure M-Switch to archive to an email address by configuring an Internet or O/R Address in the Authorisation Rule. Inbound Messages will now be archived by sending a copy of the message to that address.
Note: If you wish to configure both Archiving by Email and Archiving to disk, you need to configure two Archive Rules. Also note that Archive rules are not affected by priority: i.e. all Archive Rules will be acted on (as long as they match any Filter configured).
18.3
Secure Storage of Passwords
In a number of different places M-Switch needs to configure credentials for connections to other components of the system. These are stored in some cases as text passwords. To avoid vulnerabilities inherent in such an approach, it is possible to store these passwords in an encrypted form ensuring protection from a security failure leading to compromise of the filestore and the files containing such passwords. This feature is described in the M-Switch Advanced Administration Guide.
The following passwords are able to be stored using this encryption feature: • Directory passwords in mtaboot.xml
• Directory passwords in mtatailor.tai • other passwords in mtatailor.tai
• X.509 passphrases used to protect private keys in Digital Identities
If you need to use this feature you should read the M-Switch Advanced Administration Guide.
18.4
Security Issues: Filestore and Users
(Windows only)
As the M-Switch Services can be started automatically (i.e. without an operator), there are certain issues regarding security which you need to consider: for example, it is generally not possible to request a passphrase at startup, or to obtain random number data from operator input.
As a result, decisions about the following issues need to be made carefully concerning: • account selection
• file system access control
The security of M-Switch relies on file system access controls. This means that protection afforded to M-Switch filestore is only as strong as the login security of the system (which is usually password-based), including the ease with which a user can acquire the privileges of another user.
18.4.1
Running Services With Least Privilege
The Isode Service Configuration GUI (like the Windows Service Manager) allows you to configure the account under which the service is to run. You can choose to run under the system account or any other specified account.
You must ensure the account has sufficient privileges to be able carry out its functions. Deploying M-Switch on a default Windows installation will need the user to have the privilege to run as a Service. In typical configurations, no other privileges are required.
If M-Switch is configured to use GSSAPI against Active Directory, you will also need
SE_IMPERSONATE_NAME.
18.4.2
Isode Installation and ACL
Files and directories installed are created with an owner which is either a user or group (i.e. the CREATOR OWNER is: SYSTEM; Administrators; Users)
Files and directories are also installed with ACL (Full Control; Modify; Read & Execute; List Folder Contents; Read; Write; Special Permissions)
They are also set to inherit permissions from the object's parent (in most cases C:\Isode) So by default, mostly objects are created which allow Administrators to do anything, and users to read/execute.
You should consider carefully whether this model is suitable for your deployment.
18.4.3
Example Setup
You might wish to create a specific Group (e.g. Isode Sysadmin) and a specific user as a member of that Group to have the necessary privileges to be able to run as the Isode Messaging Services, without having system wide privileges if the Services were to run as the local System user.
This example assumes you wish to create Windows Group (Isode Sysadmins), with a single user (isode), as which Isode Services are to run. The Isode Services must then be set to run as that user. The C:\Isode filestore must then be set with the appropriate ACL. You can configure the new User, or any member of the new Group to have full control of the C:\Isode directory.
Note: If you change ACLs they are overwritten when the Isode packages are updated.
18.4.3.1
Creating a Windows Group and User
1. Select Start → Administrative Tools → Computer Management 2. Select System Tools → Local Users and Groups → Groups 3. Right click on New Group
4. Fill in the following • Group Name • Description • Close
5. Click System Tools → Local Users and Groups → Users 6. Right click on New User
7. Fill in the following • User Name • Full Name • Description • Password • Password Verify 8. Close
9. Now add the user to the group by right clicking on the newly created user and selecting Properties and selecting the Member Of tab.
10. Click on Add and then click on Advanced then click on Find Now. 11. Select the Group into which the User is to be added.
12. Click on OK (Select Groups), OK (User Properties).
If M-Switch is configured to use GSSAPI against Active Directory, you will also need the user or group to have the privilege SE_IMPERSONATE_NAME.
You have now created the User and Group under which the Isode Services can be run, either of which can be used to assign permissions to access the C:\Isode directory and the files and directories therein.
18.4.3.2
Configure the Isode Windows Services
The Isode Windows Services can be configured using the Isode Service Configuration GUI, or the Windows Service GUI. Using the Windows Service GUI is slightly simpler in this case as this will automatically cause the user to be given the necessary privilege to run as a service.
Select Start → Administrative Tools → Services
For each of the Isode Services you want to run as the newly created user, do the following: 1. Double click the service
2. Select the Log On tab
3. Change the user under which the Service is to run from the Local System account to be the newly created user created in Section 18.4.3.1, “Creating a Windows Group and User”.
• use Browse to select the user
Note: The value will appear as .\<user>).
• Configure the password to be the user password assigned when creating the user You will be warned that the user has been given the privilege to run as a service.
18.4.3.3
Configure Filestore Access Control
The newly created user also needs to be given privileges to access the filestore used by the Isode Services, ie. C:\Isode.
1. Right click on C:\Isode and select Properties. 2. Select the Security tab. Click on Edit. 3. Click on Add.
4. Click on Advanced. 5. Click on Find Now.
6. Select the Windows Group or User you have configured the Services to run as, and double click on the entry.
7. Click on OK (Select User). 8. Click on OK (Service Properties).
9. Ensure the User or Group has full control and click on OK and click on OK. You should now be able to start the Messaging Services so they run as the new user.