de-DEen-GB
 
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft Technologies like Exchange, Office 365, Azure and Cloud Security.

When you run software solutions that make use of TLS secured communication channels the applications need to have access to the certificate's private key. The private key is part of the certificate stored in the local certificate store of the computer. In most cases the software solution creates a new self-signed certificate and configures access rights appropriately.

When establishing TLS communication channels to external partners, the use of a public SSL/TLS certificate is a must have requirement.

The following step-by-step instructions describe how to assign Read permisson for the Email Security Solution Gateway NoSpamProxy. In this case the solution does not utilize a classic service account, but a so-called virtual service account. Virtual service accounts provide a much better access security when executing Windows services.

Step-by-Step Instructions

Step 1

Open the local computers certificate store using the MMC Snap-Ins.

 

Step 2

Select the certificate to use and open the context menu (right click).

SSL Certificate Conext Menu

Select Manage Private Keys to manage the private key permissions.

 

Step 3

Click Add and add the required service accounts.

In this case the virtual service accounts are part of the local computer entity. Select the local computer and not the Active Directory domain as source when searching accounts. Virtual accounts us the prefix NT Service.

Add the follow accounts to configure read access for NoSpamProxy.

NT Service\NetatworkMailGatewayIntranetRole
NT Service\NetatworkMailGatewayManagementService
NT Service\NetatworkMailGatewayGatewayRole
NT Service\NetatworkMailGatewayPrivilegedService

Add virtual service accounts

Click Check Names to verifiy the existence of the entered service accounts.

 

Step 4

When correctly resolved the accounts names are replaced by theis respective display names. Click OK to add the accounts. 

Resolved service accounts

 

Step 5

Configure read access for all added service accounts and click OK.

Configure read access

The software solution is now capable of accessing the private key of the certificate.

Link

 

 

Read More »

This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.

Problem

You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.

Assumption

The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:

  • Internet Connector
    Use receipients domain MX records
    Use self-signed certificate
    Target address space: *
     
  • Office 365 Connector
    Use tenant.mail.protection.outlook.com to route internal email messages
    Use self-signed certificate
    Target address space: tenant.mail.onmicrosoft.com

In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.

Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.

The following diagram illustrates the setup.

Broken mail flow to other Exchange Online tenants

Solution

The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.

Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.

The new connector configurations are:

  • Internet Connector
    Use receipients domain MX records
    Use 3rd party certificate
    Target address space: *
     
  • Office 365 Connector
    Use tenant.mail.protection.outlook.com to route internal email messages
    Use self-signed certificate
    Target address space: tenant.mail.onmicrosoft.com

The following diagram illustrates the new setup:

Workign mail flow to other Exchange Online tenants

 

Links

Enjoy!

 

 

Read More »

Exchange Server 2013 Exchange Server 2016Problem

When you integrate Skype for Business Server instant messaging with Exchange Server 2013 or Exchange Server 2016 you might encounter the following error in the OWA InstantMessaging log files.

ERROR:UCWEB Failure: Code=TlsFailure, SubCode=TlsRemoteDisconnected, Reason=\r\n
Microsoft.Rtc.Internal.UCWeb.Utilities.UCWException: Unknown error (0x80131500) 
---> Microsoft.Rtc.Signaling.TlsFailureException: Unknown error (0x80131500) 
---> Microsoft.Rtc.Internal.Sip.RemoteDisconnectedException: Peer disconnected while outbound capabilities negotiation was in progress 
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host\r\n   
at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)\r\n   
at Microsoft.Rtc.Internal.Sip.TcpTransport.OnReceived(Object arg)\r\n   
--- End of inner exception stack trace ---\r\n   
--- End of inner exception stack trace ---\r\n   
at Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()\r\n   
at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult result)\r\n   
at Microsoft.Rtc.Internal.UCWeb.UCWAuthenticatedEndpoint.OotyUserEndpointEstablish_callback(IAsyncResult asyncResult)\r\n   
--- End of inner exception stack trace ---\r\n   
at Microsoft.Rtc.Internal.UCWeb.Utilities.AsyncHelper.EndAsyncCall[T](IAsyncResult asyncResult, String methodName, T ucwScopeInstance)\r\n   
at Microsoft.Rtc.Internal.UCWeb.UCWAuthenticatedEndpoint.EndSignIn(IAsyncResult asyncResult)\r\n   
at Microsoft.Exchange.Clients.Owa2.Server.Core.InstantMessageOCSProvider.<>c__DisplayClass33.<SignInCallback>b__32(RequestDetailsLogger logger)

The log files are located at

\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\InstantMessaging

Solution

The Exchange Server OWA host name must be the common name (CN) of the SSL certificate used securing OWA communication.

Example for a non working IM configuration

  • OWA host name: owa.varunagroup.de
  • SSL certificate CN: mobile.varunagroup.de

Example for a working IM configuration

  • OWA host name: owa.varunagroup.de
  • SSL certificate CN: owa.varunagroup.de

Links

 

 

Read More »