- 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.
