IQService architecture: Network ports and firewalls

[#1]

• Introduction
• Architecture
• TLS support for RPC communication
• High availability for IQService agents
• Additional consideration for load balanced environment
• IQService under IdentityIQ vs. IQService under IdentityNow

Introduction

Installations of IdentityIQ/Virtual Appliance provisioning to Active Directory, Lotus Notes, SharePoint Server, Windows Local and a few other various target systems will use the IQService windows provisioning agent as an intermediary to provision to systems that require integration with a Windows based API. These projects commonly have questions related to how IQService communicates with IdentityIQ/Virtual Appliance. They also have questions related to how the IQService agent communicates Active Directory. This document provides answers and guidance for the most frequently asked questions.

Architecture

IQService is a windows based agent written in .net languages. It leverages APIs provided in Windows environments to provide provisioning services for IdentityIQ's/ IdentityNow's Java based technologies.  IQService is installed as a service running on a Windows OS based host. By default it listens on TCP port 5050 for requests from IdentityIQ/Virtual Appliance systems. The following diagram illustrates the most common deployment architecture for IQService.

Single IQService installation now supports TLS and Non-TLS ports. The default Non TLS port is 5050. There is no default TLS port, it has to be supplied during installation or it can be updated later. There is an option to set Non-TLS port to zero in order to disable Non-TLS port.

NOTE: Multiple IQService's can be installed on one machine.

IdentityIQ/Virtual Appliance has various integration strategies for communicating with Active Directory. For simple read-only aggregation and pass-through authentication only LDAP communication between the IdentityIQ/Virtual Appliance is required. If a firewall is in place between the IdentityIQ/Virtual Appliance and the Active Directory domain controller host it must permit any of the IdentityIQ/Virtual Appliance to communicate with the domain controller host.  Only allowing the UI servers or only allowing the Batch/Task servers is not sufficient. Aggregations, running from the Batch/Task servers, pass-through authentications and single account refreshes running from the UI servers all require access to the Active Directory domain controller hosts.

As shown in the above diagrams, communication via TCP between IdentityIQ/Virtual Appliance and IQService must be available. By default this happens on Non-TLS Port 5050, but it can be configured to use configured TLS Port. Communication via UDP and TCP between IdentityIQ/Virtual Appliance and at least one AD domain controller via LDAP must be available. By default this happens on ports 389 and 636.

If the installation uses SPNEGO for integrated windows authentication in place for IdentityIQ/Virtual Appliance then the install also needs port 88 (Kerberos) from IdentityIQ's/Virtual Appliance's servlet containers to at least one domain controller. If the installation has the AD Password Interceptor in place then this requires an open route from each AD Domain Controller to at least one IdentityIQ/Virtual Appliance server connection on the port where IdentityIQ/Virtual Appliance is running web services. This is on ports 80, 8080, 443, or 8443 (HTTP/HTTPS) and varies installation to installation.

The network segment between IQService and domain controllers is more complicated. The IQService provisioning agent calls functions exposed by Microsoft’s.net packages that are a “black box” that communicate to Active Directory indirectly.  IdentityIQ/Virtual Appliance does not control what port numbers these APIs leverage to interact with Active Directory. Microsoft publishes a list of ports that the .net API and ADSI interfaces use to communicate with an Active Directory server. Were a firewall to be placed between IQService and the Active Directory domain controllers it would need to be exceeding permissive by opening a large number of dynamic ports. The complete list of ports is published by Microsoft here: http://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx

The IQService agent uses a sub-set of these ports documented by Microsoft. For communication between IQService and a domain controller SailPoint recommends at least the following ports must be opened:

• LDAP Ports 389 and 636
• Kerberos port 88
• Active Directory Web Services 9389
• Active Directory port 3268(If a Global Catalog is configured)
• Active Directory port 3269(If a Global Catalog is configured)
• Active Directory DNS port 53
• Active Directory Replication, Login services port 445
• Kerberos Passwords, port 464
• Authentication port UDP 137
• Authentication port TCP 139

The following diagram illustrates firewalls in place between IdentityIQ/Virtual Appliance components and Active Directory components. Green check marks indicate places where firewalls are common and/or recommended. A red X indicates where firewalls are not recommended for use in the deployment. It is recommended that the IQService provisioning agent be inside the firewall security permitter for active directory domain controllers.

Integrations communicating to multiple Active Directory domains need to have firewall ports opened from all IdentityIQ/Virtual Appliance servers to the complete set of domain controllers configured for each domain. Integrations using domain-controller host specific provisioning plans must have firewall ports opened to all domain controllers to which IdentityIQ/Virtual Appliance will be sending provisioning requests. This is most common when password reset is deployed to reset a user’s AD password on the domain controller host closest to the user’s workstation.

The following diagram illustrates an IdentityIQ/Virtual Appliance integration with multiple domains and a single IQService.

In this scenario the IQService instance must have access to at least one domain controller from each domain (X, Y, Z). If password-reset use cases are in place that communicate with specific DC hosts then provisioning for communication to those specific DC hosts must be in place.

TLS support for RPC communication

SailPoint provides the following features to enhance the security of communication channel between IdentityIQ/Virtual Appliance and IQService:

• TLS Communication between IdentityIQ/Virtual Appliance and IQService: IQService based Connectors now support TLS communication between IdentityIQ/Virtual Appliance and IQService which secures the data traversing over the network.
• Client Authentication: IQService based connectors now support Client Authentication which authenticates every incoming request from IdentityIQ/Virtual Appliance before executing those requests. This is required if TLS is enabled to ensure all operations provided in the IQService are appropriately secured from unauthenticated access.

NOTE: Use of Non-TLS port is not recommended for production as it uses a static key for encryption of RPC messages.

For more information, see IQService: TLS and Client Authentication Configuration.

High availability for IQService agents

Applications in IdentityIQ/Virtual Appliance only support configuring a single host name and port number for communicating with an IQService instance.  IQService agents can be configured for HA (high availability) through the use of a Load Balancer configured to route the TCP traffic from IdentityIQ/Virtual Appliance to IQService instances. The recommended deployment is for a "primary" and "secondary" configuration, where traffic is routed to the primary IQService instance preferentially as long it is online, and then routed to the secondary IQService instance only in circumstances where the primary does not accept an incoming TCP connection.

When deploying this configuration, configure the load balancer to listen for TCP traffic on port 5050 or whatever port you have configured in the Application in IdentityIQ/Virtual Appliance. The load balancer should then be configured to point to 2 hosts running IQService on port 5050 (or whatever the chosen site-specific port for IQService is). The load balancer should be configured to send traffic to the primary host as long as the TCP socket on the primary host accepts traffic. If the primary host fails to accept TCP traffic on the port then requests should be sent to the secondary host until the primary host starts accepting traffic again. This is basically “prefer primary but use secondary if primary is not available” failover configuration.

When using multiple IQService instances care must be taken to deploy the same IQService version on both the primary and secondary hosts and be certain the same pre/post provisioning scripts are available on both hosts. When upgrading IQService agent versions be certain to upgrade both the copy installed on the primary agent host and the copy installed on the secondary agent host.

Additional consideration for load balanced environment

One certificate with subject's CN as FQDN of load balancer along with private key must be imported on all IQService instances.

Configure IQService with -m command (-m <x509 FQDNNameOfLoadBalancer>)

The following diagram illustrates a recommended HA configuration for IQService agents.

IQService under IdentityIQ vs. IQService under IdentityNow

The IdentityIQ and IdentityNow product use an IQService agent to provision changes to Windows based platforms. The agents these products use share the same name (“iqservice.exe”) and have almost identical configuration procedures. Although these agents look very similar they should not be considered identical or compatible. The IdentityIQ product and IdentityNow product follow different release schedules and at various points there are features and improvements that may be available in one product that are not available in the other product. Using one product's version with the other product can cause problems with incompatibilities between the products' agents. This can cause confusion for installations that use IdentityIQ and IdentityNow that require some clarification:

• The versions of IQService used with IdentityNow are not compatible with IdentityIQ. Likewise the versions of IQService shipped with IdentityIQ and its patches are not generally compatible with IdentityNow.
• Supports multiple installation of IQService instances on one machine.
• One IQService instance can be used to provision across multiple domain or forests based on the connectivity.

NOTE: If IQService is installed, the IQService version must match the IdentityIQ Server version, including the patch version. If you upgrade one you must upgrade the other, ensuring that the IQService patch version matches the IdentityIQ Application Server.

[rpendela]

This is so useful to understand the services and communication between agents and services. My question is related to Windows Local Direct connectors. We have 100+ windows servers in DMZ environment that we are planning to manage through IIQ. 

- Which is recommended approach?

Installing one or two IQService agents on internal servers (using same IQService of AD domain controllers) to connect to DMZ servers? (I think it requires to open RPC and SMB ports for communication between IQService and WinNT ADSI interface)

OR

Installing IQService on each DMZ windows server and open TLS/Non-TLS port through firewall

- If installing IQService on each DMZ windows is better approach, how can we manage these IQservice during IIQ upgrades and patches?

[gaurav_khullar]

Hi 

Regarding the point "it is not recommended to have a firewall between IQService and Domain Controller". In the past I have seen the setup work where there was a firewall but we had a subset of firewall rules in place to enable communication over 

• LDAP Ports 389 and 636
• Kerberos port 88
• Active Directory Web Services 9389
• Active Directory port 3268
• Active Directory port 3269
• Active Directory DNS port 53
• Active Directory Replication, Login services port 445
• Kerberos Passwords, port 464
• Authentication port UDP 137
• Authentication port TCP 137

Is the latest on this that we can not at all have firewall b/w IQService Host and DCs or we have still have a firewall as long the ports are enabled for communication.   

[menno_pieters]

@gaurav_khullar 

It is a (negative) recommendation. If you choose to do things otherwise, that's up to you, but it will complicate things, including support. Every component adds complexity to the provisioning path. If something goes wrong, there will be more things to debug.

If you put the firewall between IdentityIQ and IQService, you'll need to make sure that one port (the IQService) port is open. If you put the firewall between IQService and AD, you'll have to ensure that a whole lot of ports are open. Depending on what you do with IQService (e.g. running PowerShell scripts on remote servers), there may be additional ports that need to be opened.

Your choice of where you put IQService and firewall(s) possibly affects:

• Complexity
• Reliability
• Performance
• Traceability

- Menno

[deljr1983]

My environment will have IdentityIQ 8.1p2 on RHEL with IQService installed on a Windows Server 2019.  Unfortunately, my customer has decided the IQService should be separated from the AD DC by a firewall.  The guidance in the body of this article references the default non-TLS port is 5050, but can disable this and enable a customized TLS port.  As well as the following ports: 

For communication between IQService and a domain controller SailPoint recommends at least the following ports must be opened:

• LDAP Ports 389 and 636
• Kerberos port 88
• Active Directory Web Services 9389
• Active Directory port 3268
• Active Directory port 3269
• Active Directory DNS port 53
• Active Directory Replication, Login services port 445
• Kerberos Passwords, port 464
• Authentication port UDP 137
• Authentication port TCP 137  ..."

When it comes to the dynamic ports that will need to be opened to enable communication, is the requirement to open the FULL range of the dynamic ports for the specific version of Windows Server, or is it SOME ports within the range of those dynamic ports?

[daniel_neubert]

Dear IQService-experts,

from my point of view it would be really helpful to know how we can mimic IQService behavior in order to troubleshoot issues outside IIQ. Being able to give these commands to Windows-/Exchange-administrators can speed up problem resolution.

Especially regarding Exchange provisioning could you please confirm or amend the following test script:

$Cred = Get-Credential
$ExchSess = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -Credential $Cred -ConnectionUri https://<ExchServer>/PowerShell

 Does this correctly reproduce IQService's behavior in case we have TLS enabled in the AD applications' Exchange area?

Thank you very much.

[pasha]

Hi All

When I click on "Discover Domains" when configuring an Active Directory application, is it IQService talking to the domain controllers on port(s) 3268/3269, or is it the IdentityIQ itself?  I believe it is IdentityIQ, but the diagrams above are not showing those connections. Please correct me if I am wrong. For some reason my netstat command does not show me all the connections.

[gaurav_jain]

I am not sure about the port but it must be IQService discovering the domains. You can validate that by removing IQService configuration and see if it is still able to discover. 

[pasha]

Thanks @gaurav_jain  I ended up using wireshark and when I click on "test connection" I see connections to the iqservice server (6060 TLS) as well as the domain controllers on ports 3289, and 636.  I am using TLS connections.

[BStuart_Costco]

Given an H.A. model with 2 IQ service nodes behind an F5 load balancer, has anyone experienced any issues with the health check monitor on port 5050 causing transactional issues in IQ service (heartbeat conflicts with application traffic)?  Would love to know any options for the health check other than pinging port 5050.

Related question--how key is the suggestion to have the IQ service nodes set up with priority going to the primary at all times?

[jsosa]

Hi, I am not clear in how to deal with TLS. I have 4 IQS on prod that will be fronted by a load balancer. As 5050 is the plain text, does it only works this way? Or can I configure each IQS with its server certificate, and configure the LB as a client of this TLS communication?