Issue:

The user repository in the Messaging Security Gateway (MSG) appliance contains a large amount of users that have been imported from Active Directory, but are no longer part of it. Can the appliance automatically remove users from its user repository as they are removed from Active Directory?

Resolution:

You can configure the import profile to remove user profiles that are not present in the imported data:

1. Log in to the MSG web user interface
2. Select the System-tab at the top of the page
3. Navigate to User Management->Import/Auth Profiles using the left-hand menu
4. Click on the LDAP import profile you want to modify
5. From the window that appears, click on Advanced in the top right corner
6. Under Import Settings, set Remove User Profiles Not Imported to On
7. If you have multiple import profiles, set Add to Group/Sub-org With Profile Name () to On and set Type to the preferred option, between Group and Sub-Org. This is to prevent an import profile to remove users belonging to another profile
8. Click Save Changes

Next time the import profile is run, any user that isn't present in the AD will be removed from the MSG user repository. This will be either when the next LDAP import is scheduled, or when the task is run manually (by marking the import profile on the User Management->Import/Auth Profiles-page using the left-hand side checkbox and clicking Import)

Note: the setting Remove User Profiles Not Imported has a value for the maximum amount of users that it will remove at the same time. This is to prevent for example a failed import from deleting the whole user repository. If the actual number of users to be deleted exceeds this limit (default set to 50), the import process might not complete successfully and remove the users. To circumvent this, temporarily change the value for Restrict Number Of Profiles To Be Deleted To Less Than to be greater than the total amount of users in the group that the profile imports to, and run a manual import. You find the setting by following steps 1-5 from above.

Issue:

Recipients of encrypted mails are receiving warnings about untrusted pages and/or certificates when attempting to view messages.
Looking up the MSG address using an SSL checker gives the following type of reply:
"The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate."

Resolution:

The result from the SSL checker points to a missing intermediate certificate. This can be acquired from the Certificate Authority (CA) and added to the MSG server certificate using the instructions below:

1. Download the required intermediate certificate in PEM-format from your Certificate Authority
2. Download the MSG server-certificate in PEM-format from the appliance web UI: System -> Certificates -> Certificates, use the Download…-button to the right of the certificate
3. Open the PEM-file downloaded from the MSG-appliance in your text editor of choice
4. To the end of this file, add the content of the intermediate certificate PEM-file and save it as a new PEM-file
5. Import the new certificate file into the MSG-appliance: System -> Certificates -> Certificates, use the Import-button above the certificate list
6. Take the new combined certificate in use by distributing it to the master and agent(s): System -> Certificates -> Services

Issue:

• The MSG appliance has stopped sending emails out to external domain addresses
• Sending emails to internal domain addresses works without issue
• Receiving emails from any sender works normally
• Outgoing connector is showing errors about invalid certificates

Resolution:

The problem might be caused by an invalid or expired certificate on the MSG-appliance

To verify the active certificate:

1. Log in to the MSG web UI
2. Select the System-tab on the top of the page
3. Navigate to System->Certificates->Services using the menu on the left-hand side
4. Note which certificate is in use for the different services
5. Navigate to System->Certificates->Certificates
6. Verify the validity of the certificate(s) that is in use

If the wrong certificate is in use, it can be changed on the Services-page from step 3. Use the dropdown menus to change the certificate for all services and click Save changes.

If the certificate in use has expired, use the Generate Certificate Request-button on the Certificates-page from step 5 to start the process of adding a new certificate to the MSG-appliance. Use the created certificate request with an acquired certificate from a certificate vendor to make a new certificate for the MSG, then import the new certificate into the appliance using the Import-button, also on the Certificates-page from step 5. After this, use the instructions mentioned above to change the active certificate for all services, and save the changes.

Issue:

Does MSG message encryption work normally when sending emails from a distribution list?

Resolution:

Yes, sending from a distribution list has no effect on the MSG message encryption functionality.

Issue:

After upgrading the managed hosts and the Policy Manager Server to version 16, the managed hosts unable to retrieve policy or upstream host statistics to the Policy Manager Server.

The managed hosts have no issue to download the definitions update from the Policy Manager Server. Also, running the connectivity tool shows no issue in connecting to the Policy Manager Server.

The hosts might also after some delay, show up as disconnected or unmanaged in Policy Manager Console.

Resolution:

You need to ensure that the management server address has been configured on the root domain level in the Policy Manager Console:

* Settings (standard view) > Centralized management > Policy Manager Server address
* Settings (standard view) > Centralized management > HTTP port
* Settings (standard view) > Centralized management > HTTPS port

Also, you need to ensure that latest Client Security/Server Security 16.x installer is taken into use. If you are unsure, you may re-download the product installer from the download center at:

Client Security
https://www.withsecure.com/en/support/product-support/business-suite/client-security#download

Server Security
https://www.withsecure.com/en/support/product-support/business-suite/server-security#download

NOTE: This is no longer required with Policy Manager Server 16.02 in use. For more information, refer to the following change log:

https://community.withsecure.com/discussion/comment/130931/#Comment_130931
 

Issue:

The following errors are show during Linux Security 64 installation.
 

1:f-secure-linuxsecurity-12.0.6-1 ################################# [100%]
2019-10-21 11:15:03 net/fshttp.c:1662[7] idle timeout occurred
2019-10-21 11:15:03 fshttps.c:560[7] a timeout occurred
2019-10-21 11:15:03 fsguts2.c:1830[7] unable to perform the HTTP operation, error 201 (timed out)
2019-10-21 11:15:03 fsguts2.c:1062[7] unable to fetch update information from the server, error 201 (timed out)
2019-10-21 11:15:03 src/guts2download.c:148[7] unable to fetch the list of updates, error 201 (timed out)
2019-10-21 11:15:03 src/guts2download.c:84[7] downloading the channel content failed, error 201 (timed out)
Failed to activate the product!

Resolution:

Make sure the Policy Manager Server is accessible by the Linux Security 64 installation target machine.

Issue:

Does Linux Security 64 support the Amazon Web Services (AWS) Auto Scaling environment?

Resolution:

Yes. The AWS Auto Scaling works and it is supported in Linux Security 64 with Policy Manager, provided new UID is generated for new host when auto scaling. 

For an optimal flow you will have to consider adjusting the unique hardware information of the virtualized system, from which the device Host-ID* is generated and when a  host is to be considered as disconnected. This will help to sort quicker and more efficient, which host can be manually or automatically removed from the Policy Manager Console domain structure.
 

Device Host-ID (UID) under Linux Security 64

Linux Security 64 derives the Unique ID (UID) from the unique information provided by the hardware. Most virtualization platforms emulate the unique hardware information as well so every clone should be unique. This UID cannot be cleared or changed.
The unique hardware ID can be seen with the command:

cat /sys/class/dmi/id/product_uuid

Currently there is no possibility from within Linux Security 64 to clear UID as it comes from the operating system.
 

Import rules to the Policy Manager

Import rules need to be configured in Policy Manager so that the new created host will be automatically imported when connected to Policy Manager Server.

• Installation > Import new hosts > Import rules 

Issue:

Messages that have ended up in an MSG quarantine folder are missing from the end user digest / end user web.
Examples of missing messages:

• Message that has been wrongly categorized as spam
• Message quarantined due to SPF fail

Resolution:

There are several possible explanations for this. The message could be exceeding a spam threshold for it to be included, or quarantine folders or MSG modules could be missing from what should be included in the digest.

In the case of spam, the digest can be set to include messages only up to a certain spam score threshold. If the message spam score exceeds this threshold, it will not be included in the digest. If a message has been quarantined due to a high spam score, it will be listed in the Reason-column in the Quarantine -> Messages-page.

To modify this threshold:

1. Log in to the MSG Web UI
2. Navigate to System -> End User Services -> Filters -> General using the left-side menu
3. Check if Enable Score Range is set to On or Off
4. If it is On, check the value for Only Include Messages With a Score Less Than or Equal To
   1. Compare this value with the spam score of the message missing from the digest
   2. If the message has a larger spam score than this value, everything works as intended. Consider whether you want to modify the threshold to a higher value. Remember that setting the threshold to 100 will have the same effect as not having the setting enabled at all. Another solution, if only particular messages are being affected by this, is to create a custom spam rule that detects these messages and assigns them a lower spam score so they end up below the threshold 
   3. To modify the threshold, use the Only Include Messages With a Score Less Than or Equal To drop-down menu to set a new value and click Save Changes in the top right corner
5. If it is set to Off, this will have no impact on the digest content

For a message to be included in the digest, both the quarantine folder and the module responsible for putting the message in the quarantine must also be included in the digest. When looking at messages in a quarantine folder, the Reason-column will give a clue of what module should be included for a message to show up in digests. The Reason-value might be for example "Spf: 0", meaning that the Sender Policy Framework module must be included. By default, only the Spam – Quarantine module is included in the digest

To verify that the quarantine folder where the message ends up is included in the digest:

1. Log in to the MSG web UI
2. Navigate to System -> End User Services -> Filters -> Folders using the left-side menu
3. Check if the relevant quarantine folder is listed under Include in Digest
   1. If it is not, mark it from the Available Folders-list and use the >>-button to move it over to the Include in Digest-list
   2. Click Save Changes in the top left corner

To verify and add modules to the digest

1. Log in to the MSG web UI
2. Navigate to System -> End User Services -> Filters -> Modules using the left-side menu
3. Check if the module that sent the message to the quarantine is listed under Include in Digest
   1. If it is not, mark it from the Available Folders-list and use the >>-button to move it over to the Include in Digest-list
   2. Select the module from the Include in Digest-list and click on Options… , a new window should open
   3. Click on the tab Digest Commands
   4. From Commands, select the commands you want to have available for digest messages that have been affected by this particular module and use the >>-button to transfer them over to Available in Digest
   5. Click Save Changes to close the window
   6. Back at the main Modules-page, click Save changes in the upper left to save the new settings

Issue:

Messaging Security Gateway (MSG) appliance is reporting the following alerts:

• crit eid.plinx.log.sel Battery ROMB Battery | Low | Asserted
• err eid.plinx.raid Raid is in Write-Through Mode, Performance will be degraded.

Resolution:

These alerts are related to the RAID battery relearning and are completely normal behaviour for the appliance.

Battery relearns occur every 90 days by Hardware default. During a battery relearn, the battery fully discharges and gains statistical information regarding its overall State of Health (SoH). When the battery charge drops below a charge threshold, the disk write-cache policy changes to Write-Through.

What does disk Write-Through mean? This means that the data writes occur twice (to Memory and Disk) to protect and preserve the data in the event of a critical hardware failure or disk failure.

The battery will fully discharge, and when the disk write-cache policy changes to Write-Through, the Appliance RAID is degraded and performance is affected. Any changes to hardware or something that will trigger an asserted failure (such as ROMB Battery failed (since it's discharged entirely)), will generate a PPS alert.

As the battery recharges, the disk write-cache policy changes to Write-back. As this is the normal state of the hardware, the alerts will cease as the battery is operational and the SoH is good.

As this happens every 90 days for each appliance where a RAID Controller is present, you should expect to see these alerts reoccur regularly. If the appliance doesn't recover (can be expected to happen in a few hours), open a support ticket.

Issue:

A mail targeted to multiple recipients returns with the message saying that "the following addresses had permanent fatal errors", followed by a list of all recipients. However when sending the same message to individual users it seems to work. It seems that if one recipient is invalid, all recipients get the same label, why is this happening?

When checking the message in Smart Search in the MSG Web UI, the MTA logs contains the following error:
relay=[], dsn=5.0.0, reply=550 5.1.1 User unknown, stat=Service unavailable

Resolution:

The entry from the MTA logs list a reply from a server relaying the mail to the final recipient, so the problem is not within MSG but coming from the relay server of the recipient.
This is something that the recipient needs to verify on their end. If the recipient causing these errors is a legit user, they might be missing from a user verification database on the receiving end and their relay server might be set up to reject messages where any of the recipients are unknown.