7.1. RPC-over-HTTP functionality in IDERI note

The IDERI note server uses MS RPC (Microsoft Remote Procedure Calls) as the middleware that allows applications such as the IDERI note client or the IDERI note administrator to connect to it in a secure and authenticated manner. Using RPC allows to choose between a variety of protocols that are both historic (IPX/SPX both connection oriented and datagram oriented, NetBEUI, NetBIOS over TCP) and in every day use in a typical Active Directory® (Named Pipes, TCP, HTTP). Up until version 3.11 of IDERI note, only named pipes and dedicated TCP ports were used as protocols within the middleware layer of IDERI note. Starting with version 4.0 of IDERI note, HTTP is added to this suite of protocols that allows applications to connect to the IDERI note server. The usage of the term “HTTP” might be misleading in this context, because what is actually in use today for RPC-over-HTTP is not HTTP but instead HTTPS, thereby protecting the traffic that leaves the computers using RPC-over-HTTP with transport layer security (TLS). Nonetheless, the term RPC-over-HTTP will be used throughout this documentation as it has been established historically. There are two versions of RPC-over-HTTP that have been released for MS RPC: Version 1 and version 2. IDERI note only supports the latest version which is version 2.

Apart from the IDERI note server itself, IDERI note supports two essential components of the IDERI note product suite with the RPC-over-HTTP feature: The IDERI note client and the IDERI note administrator. The support for this protocol however, is a little bit different for both components. After an introductory paragraph that covers the basic architecture of RPC-over-HTTP and how it fits into the IDERI note product suite, the subsequent paragraphs in this section will highlight the differences between the usage of RPC-over-HTTP in these two components. The remainder of this section will then discuss recommendations with respect to group policy settings that might affect this functionality and the limitations that this functionality imposes on other IDERI note features.

7.1.1. RPC-over-HTTP architectural overview

Whereas other protocols within RPC use a direct network connection between a client and a server, RPC-over-HTTP requires a special server that acts as an intermediate between these two roles in client-server communications. This special server is called the RPC-over-HTTP proxy. An RPC-over-HTTP proxy typically is a Windows Server installation that has both IIS (Internet Information Services) and the RPC-over-HTTP operating system feature enabled, e.g. through the “Add roles and features” wizard that can be started from the Server Manager Dashboard.

Figure 7.1 shows an overview of the message flow in IDERI note between a client application (IDERI note administrator or IDERI note client) and the IDERI note server when using RPC-over-HTTP as the protocol.

RPC-over-HTTP overview

Fig. 7.1 RPC-over-HTTP overview

On the left-hand side of figure 7.1, a client computer is shown that resides in a network that is connected to the public internet via a firewall/router. This could be an employee’s home network or a public internet hotspot. On the right-hand side of this diagram, the enterprise network with the IDERI note server and an RPC-over-HTTP proxy server is depicted in a large triangle. The message flow between the client computer and the IDERI note server can be described as follows:

  1. A client application (IDERI note administrator or IDERI note client) on the client computer executes a remote procedure call. This network request is routed to the client’s internet router/firewall.

  2. The client’s internet router/firewall sends the remote procedure call over the public internet to the IDERI note server’s network.

  3. The IDERI note server’s network firewall receives the remote procedure call.

  4. The network firewall sends the call to the IIS server running on the RPC-over-HTTP proxy.

  5. The IIS server running on the RPC-over-HTTP proxy sends the remote procedure call to the IDERI note server.

  6. The IDERI note server executes the call and sends its reply to the IIS server running on the RPC-over-HTTP proxy.

  7. The IIS server running on the RPC-over-HTTP proxy forwards the reply to the network firewall.

  8. The IDERI note server’s network firewall forwards the reply across the public internet to the client’s internet router/firewall.

  9. The client’s internet router/firewall receives the reply.

  10. The client’s internet router/firewall sends the IDERI note server’s reply to the client application (IDERI note administrator or IDERI note client).

The next paragraph will shed some light on the proper configuration of the IDERI note server and the RPC-over-HTTP proxy server so they can interoperate successfully.

7.1.2. IDERI note server configuration for RPC-over-HTTP

After a fresh install, the IDERI note server only allows connections from client applications such as IDERI note administrator or IDERI note client using named pipes as the protocol. In addition, dedicated TCP ports can be configured for the administration interface and the client interface using the control panel applet of the IDERI note server installation. In order to allow incoming connections via RPC-over-HTTP from an RPC-over-HTTP proxy server, two additional ports must be configured using the control panel applet, one for access of the administration interface via RPC-over-HTTP and another one for access of the client interface via RPC-over-HTTP.

7.1.3. RPC-over-HTTP proxy server configuration

From the preceding paragraphs it should be clear that in order for RPC-over-HTTP to run properly, the IIS component and the RPC-over-HTTP operating system feature are both required to be installed on an RPC-over-HTTP proxy server. After a default installation of both components, two virtual directories with the names “Rpc” and “RpcWithCert” should be visible under the default web site of the server in the IIS configuration mmc snap-in. In order for RPC-over-HTTP to work with transport layer security, an additional binding for this site must be configured with a server certificate that is considered valid on the client computer. This new binding for https (TLS) can use any free port on the RPC-over-HTTP proxy server, but for maximum compatibility for clients to connect through networks that filter out non-standard ports, 443 is probably the best choice. It is also necessary to enable Windows integrated authentication for this on the virtual directory named “Rpc” and it is best practice to disable anonymous access.

Another important configuration aspect of an RPC-over-HTTP proxy server in order to be able to connect to an IDERI note server is adding the IDERI note server to the “ValidPorts” registry value in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy on the RPC-over-HTTP proxy server. This is done by appending the name of the IDERI note server and the port number that it uses to listen to incoming requests for RPC-over-HTTP separated with a colon to the semicolon delimited list in this registry value. This port that the IDERI note server uses to listen to incoming requests via RPC-over-HTTP should not be confused with the port that the IDERI note server uses to listen for incoming requests via TCP. It should also not be confused with the port (such as 443) that the RPC-over-HTTP proxy server uses to listen for incoming requests from the internet.

7.1.4. Testing an RPC-over-HTTP configuration with IDERI note and rpcping

After installation and configuration of the IDERI note server (see above) and prior to deployment of the IDERI note client or IDERI note administrator, connectivity can easily be tested using a builtin operating system command line tool named rpcping. For our purpose, let’s assume that we have the domain user note\albert.tross from the preceding chapters logged in on some domain workstation and we want to test connectivity from the domain workstation that albert.tross is using with the IDERI note server’s client interface via RPC-over-HTTP. We further assume that the IDERI note server’s name is note-srv01.note.local and that it is listening on port 1027 for incoming connections via RPC-over-HTTP on its client interface. The name of the RPC-over-HTTP proxy server that we are using is srvrpchttp.example.com and it is listening on port 444. In that case the following command can be used by albert.tross to verify a working connection via RPC-over-HTTP to the IDERI note server (make sure to provide this command on a single line):

rpcping /t ncacn_http /s note-srv01.note.local /e 1027 /o RpcProxy=srvrpchttp.example.com:444 /H 2 /u 10 /a privacy /F 3

If this command succeeds, it will print something similar to this on stdout, otherwise an error has occurred:

Completed 1 calls in 2360 ms
0 T/S or 2360.000 ms/T

At this point, it is important to understand, that the name of the IDERI note server, which is note-srv01.note.local in this example, does not get resolved on the client computer for this to succeed. Therefore, the client does not need a DNS server that can resolve note-srv01.note.local, which is a DNS name that only can be resolved by clients that directly connect to the enterprise network where note-srv01.note.local resides. The only server name that needs to be resolved on the client computer is that of the RPC-over-HTTP proxy server, which is srvrpchttp.example.com in our case. The information about which IDERI note server has to be connected to is packaged into the request that is sent to the RPC-over-HTTP proxy server and it is this server’s responsibility to have this name resolved by its DNS server.

The rpcping utility can also be used from a non-domain joined client computer, but for this to work, the credentials of the user albert.tross have to be supplied. In order to test the connectivitiy this way, use the following command line (again, make sure to provide this command on a single line):

rpcping /t ncacn_http /s note-srv01.note.local /e 1026 /o RpcProxy=srvrpchttp.example.com:444 /P albert.tross,note,* /H 2 /u 10 /a privacy /F 3 /I albert.tross,note,*

After typing in this command, you will be prompted twice for the password of albert.tross, first in order to authenticate against the IDERI note server and after that a second time in order to authenticate against the RPC-over-HTTP proxy.

Note that the first example in this paragraph with albert.tross being logged on to a domain computer will not work if the group policy “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” is set to “Deny all” for the client computer. For more information on Group Policies with respect to NTLM and RPC-over-HTTP please read paragraph 7.1.7.

7.1.5. RPC-over-HTTP support in IDERI note client

The IDERI note client has two modes of support for RPC-over-HTTP:

  • Using named pipes or TCP as the primary protocol and RPC-over-HTTP as a fallback protocol

  • Using RPC-over-HTTP as the only protocol

Using the first mode, the IDERI note client will try to connect to its IDERI note server using either named pipes or TCP as the primary protocol. In case this connection method fails because the IDERI note server is not accessible, the client tries to reconnect to the IDERI note server using RPC-over-HTTP and maintains this connection until a successful connection using the primary protocol (named pipes or TCP) is possible again. This allows seamless switching of clients such as corporate laptops, which are connected to the corporate network during work hours, from TCP or named pipes to RPC-over-HTTP after the computer has left the corporate network and eventually has access to the public internet again.

Using the second mode, the client will only try to make a connection using RPC-over-HTTP.

It goes without saying that both modes are controlled by command line parameters for inotecln.exe (see section 9.1) and MSI properties for intclnt.msi (see section 8.3).

7.1.6. RPC-over-HTTP support in IDERI note Administrator and IDERI note QuickAdmin

IDERI note administrator and IDERI note QuickAdmin do not use an elaborate fallback scheme such as the IDERI note client. These applications instead allow the user to choose between a local login or remote logins via named pipes, TCP or RPC-over-HTTP. This can be done either from the login dialog (see figure 3.16) or via command line options (see sections 9.3 and 9.4).

It is important to note, that for RPC-over-HTTP to work in these applications, the name of the RPC-over-HTTP proxy server and the port it uses have to be supplied using a concatenation of the DNS name of the RPC-over-HTTP proxy server and its port number, separated by a colon.

7.1.7. Group policy settings for RPC-over-HTTP and Kerberos/NTLM

Until the introduction of Active Directory® with Windows 2000, the authentication protocol used in Windows NT networks was NTLM. Windows 2000 then replaced NTLM with Kerberos as the authentication protocol of choice and NTLM was considered a legacy protocol. NTLM has a number of severe drawbacks in comparison with Kerberos, the most notably being the lack of mutual authentication. With NTLM, a server that a client connects to is not authenticated to the client as in Kerberos, it is only the client that authenticates itself to the server. One might argue however, that this drawback is alleviated by the fact that RPC-over-HTTP as an example of a network application using NTLM employs transport layer security (TLS) today, which provides authentication of the RPC-over-HTTP proxy server to the client by the very nature of TLS as a protocol that authenticates the server to the client. NTLM has also undergone quite some evolvement throughout its years of existence culminating in the removal of NTLMv1 in Windows 11 and Windows Server 2025. Note that IDERI note works with RPC-over-HTTP and NTLMv2 on both of these operating systems with standard settings for group policies.

So for RPC-over-HTTP to work, NTLM is still required as there is no replacement option from Microsoft for this as of today. Please note that with today’s standard configuration settings of an Active Directory®, the RPC-over-HTTP support in IDERI note works out-of-the-box. However, to make NTLM and thus RPC-over-HTTP functional in an otherwise fully kerberized environment, two Group Policy Settings are of importance:

  • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers

    If this option is set to “Deny All”, no client application on the computer can create an outgoing connection using NTLM unless exceptions are defined. So if a client connection via RPC-over-HTTP fails with this policy set to “Deny all” and you want to use RPC-over-HTTP, you have to define an exception for both your IDERI note server and your RPC-over-HTTP proxy server.

  • Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication

    With this policy setting, you can specify a list of servers within your organization that clients are allowed to connect to using NTLM. For IDERI note with RPC-over-HTTP you have to specify both the IDERI note server and the RPC-over-HTTP proxy server. In the examples above for the rpcping utility this would be note-srv01.note.local (the IDERI note server) and srvrpchttp.example.com (the RPC-over-HTTP proxy server).

7.1.8. Limitations of RPC-over-HTTP in IDERI note

Since RPC-over-HTTP uses NTLM as its authentication protocol, builtin configuration options such as “KerberosOnly” REG_DWORD value (see section 10.1) and its corresponding MSI property “FORCE_KERBEROS” (see section 8.3) should be set to 0 for the IDERI note client, otherwise the IDERI note client refuses to connect to its server.

Pushing an alarm to clients in IDERI note requires a connection between the IDERI note server and the IDERI note client using named pipes. Since there is typically no direct connection between an IDERI note client and its server if RPC-over-HTTP is used, this functionality is not available for clients connecting via RPC-over-HTTP. For a similar reason, Active Directory Resynchronization (see section 7.12) does not work for clients that are connected to their server via RPC-over-HTTP because this requires a direct connection from the IDERI note client to its domain controller so it can purge its Kerberos ticket cache and reconnect to the IDERI note server using up-to-date group membership information.

Another area, where RPC-over-HTTP doesn’t work is automatic server detection with an Active Directory® query for an IDERI note service connection point (see section 2.3). Such an Active Directory® query under the hood uses named pipes in order to connect to its domain controller which is not possible in most circumstances where RPC-over-HTTP is applicable.

7.1.9. Running an RPC-over-HTTP proxy server on an IDERI note gateway server

In order to support the connection of mobile devices with an IDERI note infrastructure, a dedicated server instance is used, where the IDERI note gateway service is installed (see section 7.33). This server can also be configured to be used as an RPC-over-HTTP proxy server. However, when running both functionalities on the same server, different port choices have to be made for both server applications. This means: You cannot run the IDERI note gateway service on the standard port 443 and configure the RPC-over-HTTP proxy server on the same computer to also run on port 443, you have to choose a different port for the RPC-over-HTTP proxy server functionality.