SecurityGateway for Email Servers v12.5

Choose this type if you wish to use SMTP to verify unknown local recipients of incoming messages and unknown local senders of outbound messages. Similar to Callback Verification, SecurityGateway will attempt to verify the user via the SMTP protocol. For unknown local senders who attempt to authenticate, SecurityGateway will pass the user's credentials to the SMTP Verification source for authentication. If authentication is successful then the message will be accepted for delivery by SecurityGateway and an account for the user will be created. For accounts that already exist, SecurityGateway will first check the user's login credentials against the local user database. If no match is found there then the SMTP Verification source will be checked.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

Host or IP:

This is for the hostname or the IP address of the verification source. SecurityGateway will connect to this location when querying this source. This option corresponds to the Host column on the User Verification Sources page.

Port:

This is the port SecurityGateway will use when connecting to the verification source, and it corresponds to the Port column on the User Verification Sources page.

Requires authentication

Click this checkbox if the SMTP Verification source requires authentication. Then include the user name and password below.

User name:

If the SMTP Verification source requires authentication, specify your user name here.

Password:

Enter your SMTP Verification source password here.

Choose this type if you wish to use Active Directory or an Exchange server to verify unknown local users. As with SMTP Verification above, this verification type supports dynamic authentication. For unknown local senders who attempt to authenticate, SecurityGateway will pass the user's credentials to the Active Directory/Exchange server for authentication. If authentication is successful then the message will be accepted for delivery by SecurityGateway and an account for the user will be created. For accounts that already exist, SecurityGateway will first check the user's login credentials against the local user database. If no match is found there then the SMTP Verification source will be checked.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

Host or IP:

This is for the hostname or the IP address of the verification source. SecurityGateway will connect to this location when querying this source. This option corresponds to the Host column on the User Verification Sources page.

Port:

This is the port SecurityGateway will use when connecting to the verification source, and it corresponds to the Port column on the User Verification Sources page.

User name:

This space is for the Active Directory/Exchange/Windows user name needed to log in to the verification source.

Password:

Use this space to enter the password that corresponds to the Active Directory/Exchange user name specified above.

Search Filter:

This is the search filter that will be used when querying your Active Directory/Exchange server for users. In most cases the default search filter should be sufficient.

Choose this verification type if you wish to use an MDaemon server using Minger as the user verification source. This is an extended version of the Minger protocol exclusive to MDaemon servers and therefore this option cannot be used with other types of servers. This verification type supports dynamic authentication like the two previous verification types. This means that your users can authenticate or log in to their SecurityGateway accounts using their mail server login credentials.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

Host or IP:

This is for the hostname or the IP address of the verification source. SecurityGateway will connect to this location when querying this source. This option corresponds to the Host column on the User Verification Sources page.

Port:

This is the port SecurityGateway will use when connecting to the verification source, and it corresponds to the Port column on the User Verification Sources page.

Requires authentication

Click this checkbox if the MDaemon server requires authentication to use Minger.

Password:

Enter your MDaemon server's Minger password here.

Choose this option to use the MDaemon XML-API as a User Verification Source type. MDaemon's XML API provides a better alternative to Minger as it can authenticate accounts for which MDaemon has not stored a copy of the password using reversible encryption. It can also return all aliases for an account in a single call. NOTE: This option requires MDaemon version 23.0.2 or later.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

MDaemon XML API URL:

MDaemon's installation default XML-API URL is: "http://servername:RemoteAdminPort/MdMgmtWS/" However, it is highly recommended to configure HTTPS options in MDaemon and use secure HTTP (i.e. https://servername:RemoteAdminPort/MdMgmtWS/).

Create MDaemon XML API Service Account

Click this button to create an MDaemon XML API Service Account with limited permissions. Rather than have you supply a full administrator's credentials for SecurityGateway to use permanently, this feature uses the API to create a separate account whose permission is limited to the single "XMINGER" operation used for verifying and authenticating user accounts.

Choose this verification type if you wish to use an LDAP server to verify your users. However, unlike with the other verification types, you cannot use LDAP to authenticate a user's login credentials. Consequently, dynamic authentication, or authenticating "on the fly", isn't supported. Therefore, if you require your users to authenticate then users verified through an LDAP verification source will not be able to log in or send messages through SecurityGateway without using their SecurityGateway account's password.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

Host or IP:

This is for the hostname or the IP address of the verification source. SecurityGateway will connect to this location when querying this source. This option corresponds to the Host column on the User Verification Sources page.

Port:

This is the port SecurityGateway will use when connecting to the verification source, and it corresponds to the Port column on the User Verification Sources page.

Bind DN:

Enter the Distinguished Name (DN) that has access to your LDAP server so that SecurityGateway can query it for user names. This is the DN used for authentication in the bind operation.

Password:

This password will be passed to your LDAP server along with the Bind DN value for authentication.

Base entry DN:

This is the root DN or starting point in the Directory Information Tree (DIT) at which SecurityGateway will search your Active Directory for users.

Search Filter:

This is the LDAP search filter that will be used when querying your LDAP server for users. In most cases the default search filter should be sufficient.

Search Scope:

This is the scope or extent of your LDAP searches.

Base DN only

Choose this option if you wish to limit your search to only the Base entry DN supplied above. The search will not proceed below that point in your tree (DIT).

1 level below base DN

Use this option if you wish to extend your search to one level below the Base entry DN in your DIT.

Base DN and all children

This option will extend the scope of your search from the Base entry DN to all of its children, down to the lowest child entry in your DIT. This is the default option selected.

To use Microsoft 365 as a user verification source, SecurityGateway requires a service principal that has been granted permission to access the Microsoft 365 tenant. Further, Microsoft 365 utilizes Azure Active Directory as its directory service. The steps below detail how to configure Microsoft 365 as a user verification source in SecurityGateway.

Register an application with Microsoft Identity platform:

1.Login to the Microsoft Entra admin center.

For accounts with multiple tenants, click the Settings icon and select the desired tenant.

2.In the Admin Center menu, select Identity > Applications > App registrations.

3.Select New Registration

4.Enter an application name in the name field.

5.Select Register

6.Make note of the Application ID

7.Select API Permissions

8.Select + Add a permission

9.Select Microsoft Graph

10.Select Application Permissions

11.Select Group.Read.All and User.Read.All

12.Select Add permissions

13.Click the Grant admin consent for... button

14.Click Yes

15.Select Certificates & Secrets

16.Click + New Client Secret

17.Enter a description in the description field

18.Select the radio button to determine how long the password will be valid for.

19.Make note of the generated password in the Value field as this password will not be viewable again.

In SecurityGateway:

1.Login to SecurityGateway with the global admin.

2.Select Setup/Users

3.Select Accounts

4.Select User Verification Sources

5.Click New

6.Select Microsoft 365

7.Enter a description

8.Enter the Microsoft 365 domain name in the Domain Name field.

9.Select the Type

For most configurations, the option will be "Global."

10.Enter the Application ID from Azure AD in the Service Principle field.

This can be found on the Overview page of the app registration in Azure AD

11.Enter the password generated in Azure AD above in the Password field.

12.Click Save and Close.

Google Workspace verification uses a service account with domain-wide delegation to query the Google Admin SDK Directory API, which SecurityGateway uses to look up and verify unknown local addresses. Optionally, you can also configure an OAuth client to let your Google Workspace users sign in to SecurityGateway directly with their Google account, similar to the Microsoft 365 sign-in experience described above.

To use Google Workspace as a user verification source, SecurityGateway requires a Google Cloud service account that has been granted domain-wide delegation to read your Workspace directory. Follow the steps below to configure Google Workspace as a user verification source in SecurityGateway.

In Google Cloud Console:

Create a project and enable the Admin SDK API in Google Cloud Console

1.Sign in to the Google Cloud Console and create or select the project that will own the service account.

2.Go to APIs & Services > Library, search for Admin SDK API, open it, and click Enable.

Create a service account and JSON key

1.Go to IAM & Admin > Service Accounts and click Create Service Account. Give it a name (for example, "securitygateway-uvs"). No Google Cloud IAM roles need to be assigned; the access this account needs is granted through domain-wide delegation in the next step, not through IAM.

2.Open the new service account, go to the Keys tab, and click Add Key > Create new key, choosing JSON. This downloads a JSON key file. Keep this file safe, and be aware that Google will not let you download it again once you close the dialog. Otherwise, you would need to generate a new key instead.

3.While you're on the service account's details, make a note of its numeric Client ID (labeled "Unique ID"). You'll need it in the next step. Be careful not to confuse it with the Google Cloud project ID, the service account's email address, its display name, or the separate OAuth Client ID you may create later for web login — these are all different values.

Authorize domain-wide delegation in the Google Workspace Admin Console

1.Sign in to the Google Workspace Admin Console as a super administrator.

2.Go to Security > Access and data control > API controls > Domain-wide delegation, and click Add new.

3.For Client ID, enter the service account's numeric Client ID from Step 3 above.

4.For OAuth scopes, enter the following scope, then click Authorize:

https://www.googleapis.com/auth/admin.directory.user.readonly

(Optional) Enable Google sign-in for the SecurityGateway web interface

If you also want your Google Workspace users to be able to sign in to SecurityGateway with their Google account instead of a SecurityGateway password, create a separate OAuth client:

1.In Google Cloud Console, go to APIs & Services > Credentials, click Create Credentials > OAuth client ID, and choose Web application.

2.Add an authorized redirect URI that exactly matches your SecurityGateway login URL with /auth appended (e.g. https://sg.example.com/auth).

3.Make a note of the generated Client ID and Client Secret.

This OAuth client is separate from the service account above. The service account is only ever used for directory lookups, and the OAuth client is only ever used for interactive sign-in.

Choose the admin account to impersonate:

Domain-wide delegation always acts as a specific Workspace user, and looking up directory users requires Google Workspace admin privileges. Choose a super administrator account, or an account with a custom admin role that includes the "Users > Read" privilege. You'll enter this address in SecurityGateway as the Admin Email field below.

In SecurityGateway:

1.Login to SecurityGateway as a global admin.

2.Click Setup/Users.

3.Select Accounts.

4.Select User Verification Sources.

5.Click New.

6.Select Google Workspace as the Type.

7.Enter a description.

8.Enter your Google Workspace primary domain in the Domain Name field.

9.In the Admin Email field, enter the email address of the Google Workspace administrator you chose to impersonate.

10.Paste the full contents of the service account JSON key file into the Service Account Key (JSON) field.

11.If you set up Google sign-in above, enter the OAuth Client ID and OAuth Client Secret. Otherwise, leave these blank.

12.Click Save and Close.

Description:

Use this text box for a description of the verification source (for example, "Server X at example.com"). It corresponds to the Description column on the User Verification Sources page.

Domain Name

Enter your organization's Google Workspace primary domain name (e.g. example.com). This does not need a host name or port; SecurityGateway always connects to Google's own API endpoints for Google Workspace lookups. If you've also configured Google sign-in, this domain is additionally used to confirm that anyone signing in belongs to your Workspace, rejecting sign-in attempts from Google accounts outside it.

Admin Email

Enter the email address of the Google Workspace administrator account for the service account to impersonate. Google's Directory API requires that lookups be performed on behalf of an actual admin user via domain-wide delegation, so this must be an existing account in your Workspace directory with administrative rights to read the directory (a super administrator, or an account with a custom role that includes "Users > Read") — not the service account itself. NOTE: If the Google Workspace account entered in Admin Email is ever suspended, deleted, or has its administrator role removed, Google Workspace verification will start failing for every domain using this source, even though nothing changed in SecurityGateway.

Service Account Key (JSON)

Paste the entire contents of the JSON key file you downloaded for the service account in Google Cloud Console. SecurityGateway uses this key to sign requests to the Directory API on behalf of the Admin Email account above. If you ever need to revoke and replace this key, generate a new one in Google Cloud Console and paste its contents here to replace the old value.

OAuth Client ID (Optional)

The Client ID of a Google Cloud OAuth client (of type "Web application"), used only to let users at this domain sign in to the SecurityGateway web interface with their Google Workspace account, instead of a SecurityGateway password. Leave this blank if you only want Google Workspace used to verify addresses, without offering Google sign-in.

OAuth Client Secret (Optional)

The Client Secret that corresponds to the OAuth Client ID above. Both the Client ID and Client Secret must be set together for Google sign-in to be offered to users at this domain — if either is left blank, users will continue signing in with a SecurityGateway password.