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 137

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.

[adam_hampton]

Hi Chris,

IdentityIQ uses 2 different vectors or channels to communicate with Active Directory domains.  Read operations are performed directly from the Java applications via LDAP connections (TCP connections) on port 389 or 636.  Write operations, like creating new users or groups or changing a user's password, occur through IQService.  IQService uses .net APIs to bind to the domain in question, and these under the hood sometimes use LDAP and other times use other Microsoft proprietary communications channels.

The separation of these channels is mostly for historical reasons; IdentityIQ had a read-only connector for Active Directory before it had a read-write connector.  IQService doesn't participate in account aggregation or pass-through authentication functions.  All of those functions occur directly between IdentityIQ JVMs and AD via LDAP.

--Adam

[chris_meisner]

Thanks Adam, How does this answer change when using a Cloud Gateway Architecture? We would never allow remote access to a domain controller over the internet or in use cases where direct access to a DC would not be allowed (restricted system boundaries like Federal Government Environments).

My understating is the Cloud Gateway Service interacts with the IQ Service to perform the tasks. In the model you suggested, would the aggregation tasks be handled by the AD Direct Connector (via the Cloud Gateway proxy application)?

If yes...

If the IQ Service is installed on the domain controller and the target domain controllers, is it necessary to have the Gateway Server host as a member of the same forest or is the requirement ONLY that the IQService Host must be a member.

For pass through authentication, I get the LDAP port requirements, but for domains NOT being used for authentication of IdentityIQ users, are the LDAP ports required from the gateway server to the domain controller?

[adam_hampton]

Q: How does this answer change when using a Cloud Gateway Architecture?

A: The CCG (Cloud connector gateway) itself needs an LDAP TCP path to domain controller hosts.  Aggregation and pass-through authentication tasks will execute from the CCG daemon's java stack.

Q: My understating is the Cloud Gateway Service interacts with the IQ Service to perform the tasks.

A: There is still a 2-channel approach. CCG directly reads, CCG contacts IQService to perform and writes.

Q: Is it necessary to have the Gateway Server host as a member of the same forest?

A: No, only the host(s) on which IQService is installed need to be a member of the target domain.

Q: For domains NOT being used for authentication of IdentityIQ users, are the LDAP ports required from the gateway server to the domain controller?

A: Yes, because account aggregation uses the same LDAP network path as pass through authentication.

--Adam

[deepun_kerai]

Thanks, Adam.

Is there any documentation/information regarding packet sizes and network traffic from the AD connector?

Acceptable timings? How long it takes?

I see the DB Performance Guide in reference to:

There are 4 data points that are relevant from your test data.  Those are:

• the "Generation Test" time of 123,230 milliseconds
• the "1k data item" time of 80 milliseconds per 1k record, on average
• the "4k data item" time of 41 milliseconds per 4k record, on average
• the "8k data item" time of 48 milliseconds per 8k record, on average

Anything outside this?

Thanks,

Deepun

[adam_hampton]

Hi Deepun,

Those metrics define acceptable performance for the IdentityIQ application server to its backing relational database pipe.  There is no benchmarking or network latency recommendations for the Active Directory connector layer or the IQService layer. The Active Directory connector reads via LDAP, and that performance can be measured outside of IdentityIQ using ldapsearch.

In practice we haven't found bandwidth constraints here to be a problem.  There needs to be broadband connectivity between the IdentityIQ application servers and the AD domain controller hosts with which it will be communicating. Beyond there we don't have anything to add.

--Adam

[ben_dizenhouse]

Adam - Your 1:1 ratio comment is a little confusing.  You mention the recommended ratio be 1:1, so if you are provisioning 4 domains, you have at least 4 IQService installations (1 or more per domain).  However, the document describes the scenario of a shared IQService installation for multiple domains.  Since your original comment of Jun 6 2016, is there more direction from SailPoint?  Which is best practice verses which are you seeing your customers deploying successfully?

The document also mentions that the IQService version (including patch level) must match the IIQ version (including patch level).  The more IQService installations that are used, the harder this will be to manage.  This would lead to longer upgrade times/outages/etc.  In the example above, not only would IIQ need to be patched, but the 4+ installs (for 4 domains) also need to be upgraded.  In most organizations i would assume this would involve ever increasing number of teams, based on the management of all the provisioned domains.  This is why I would think a best practice would be to have a "farm" of IQService agents in which the upgrade of the individual nodes can be controlled and its not all done in a single upgrade stage.

Thanks in advance.

[adam_hampton]

ben.dizenhouse​ - This is a changing situation.  My 1:1 recommendation is an old recommendation made from a "the most conservative approach" posture.  The most correct answer depends on the version of IdentityIQ you have installed.  Older versions (6.3, 6.4) treated each domain as a separate Application in the application server's logic.  Early versions of iqservice.exe expected to be "glued" to one domain because the encryption keys between IdentityIQ and IQService were persisted at the Application level inside IdentityIQ's object model and persistence layer.  Trying to use one iqservice.exe to service two domains (from two Application configurations) would result in an encryption key error.  That is no longer the case, which opens up a 1:N model as an option.  We now have a process to sync the keys between different iqservice.exe copies, which is a feature or procedure we did not have a couple of years ago.  Newer versions of IdentityIQ, 7.1 and beyond, also will natively support communicating directly to different domains in a forest because in IdentityIQ 7.2 and forward the connector code is changing to be able to model multiple domains in a forest and foreign security principals as a single Application in IdentityIQ.  The new behavior is also easier for IdentityNow customers, who share the same iqservice.exe binaries with little modification, to install fewer iqservice.exe instances and still be able to communicate to a variety of Active Directory endpoints.

--Adam

[kishore]

Adam,

1:1 : Is this recommendation valid for IdentityNow also, if not could you please suggest for IdentityNow.

[wes_roberts]

Hello Adam,

The article is very useful.  On Sep 21, 2016 12:21 PM you mention : IQService uses .net APIs to bind to the domain in question, and these under the hood sometimes use LDAP and other times use other Microsoft proprietary communications channels.

In performing the binding, what credentials (and port) are used?  There is a concern these aren't encrypted.

Thanks ahead,

--Wes

[#11]

Can this be deployed in the public cloud environment, like Azure for example to talk to Azure AD?