cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IQService architecture: Network ports and firewalls

IQService architecture: Network ports and firewalls

 

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.

IQService Communication.png

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.

 

Firewall and Active Directory Integrations.png

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.

multiple integrations.png

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.

 

Agents.png

 

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.

Labels (1)
Comments

Hello

Regarding the LDAP access, document clearly states that IdentityIQ connects to the AD using LDAP but I am not sure about IQService: is it also connecting to AD using LDAP?

Thanks

    Richard

Hi all,

do I need to use three IQService instances (one within each network) to get this configuration working or would it be possible to use only one IQService for all domains/forests? My guess would be three instances.

Architecture_Diagram.png

Hello

I'd like to know if high availability for IQService agents can be treated with Windows Failover Cluster instead of setting a load balancer appliance.

Does anybody know answer this request please ?

Does it exist a procedure to set the failover of IQService agents through Windows Failover Cluster ?

Thank you for your precious help.

Hi,

As I understand, Sailpoint doesn't provide OOTB high availability for IQService.

It means that the customer needs to provide a Load Balancer to achive this.

Is planned to provide  high availability for IQService OOTB in the roadmap ?

regards, Roberto

@dschmier - Did you go with 3 IQService instances(with different creds - as there is no 2 way trust) for your scenario and if yes did you configure 3 apps for it? 

@adam_hampton , @neelam_futane , @justin_choponis - We have 4 different domains in picture - first domain hosting iiq and iqservice server, 2nd domain hosting an AD forest to which we're connecting to, 3rd domain hosting an AD forest to which we're connecting to + Skype  and last domain hosting exchange forest .

Domain 1 -2 have forest trust, transitive, 2-way

Domain 2-3 have forest trust, transitive, one way

Domain 3-4 have servers joined

In this case if 2 -way trust can't be enabled - is the only seemingly feasible solution here to install iqservice instance on 3 domains we're connecting to from IIQ/IQService and setup them as different applications ? Also in this scenario, run of after create/after modify scripts for Skype might run into issues  - Please advise here

From what we found out, you need to install an IQService in each domain, if you do not have two way trust.

thanks for the response @dschmier - that essentially means configuring 3 AD applications each catering to different domain ? or is there a way you achieved that using a single AD application (using a VIP address for IQService and then some redirection logic for IQService instances for 3 domains)?

@aditya_pathak the problem is, you can only configure credentials and hostname for one IQService system within one application. If you have three domains with different IQServices on different hosts, you need to define three applications.

yep, it's a limitation - thanks for the reply @dschmier .

Version history
Revision #:
6 of 6
Last update:
‎Oct 05, 2023 02:05 AM
Updated by: