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.

[daniel_neubert]

Adam,

thank you very much for providing this document and your insightful explanations.

So my understanding is that your statement from above

     "IQService should be installed on a server that is a member of the domain that it is provisioning into"

is also obsolete.

It's also not required anymore to run the service under the service account which is used to connect to AD, as this can't be the same for different domains.

Can you please confirm?

Thanks in advance,

Daniel

[adam_hampton]

Hi Daniel,

Yes, this is also an obsolete statement. The requirement now is that IQService be installed on a computer that is a member of any one of the domains inside the Forest to which IdentityIQ will be provisioning to and aggregating from.  IQService uses service accounts configured inside IdentityIQ for binding to specific domains when making changes.  However, the service account running IQService must still have disk i/o rights for starting and logging, port 5050 TCP network rights, and firewall rights to bind to other DC hosts in the forest.  I believe we can run IQService can run as a simpler service account, with fewer privileges than what we configure in IdentityIQ, but I have not specifically tested this configuration.

justin.choponis​ - have you come across a configuration where we have used IQService to provision to 2 or more domains? In that circumstance was there anything special we needed to do to facilitate the service accounts running IQService?

--Adam

[justin_choponis]

Hi folks - Adam is correct - IQService needs to run on a computer that is a member of one of the managed forest domains. Also, 1 IQService instance can be used with the newer "one app per enterprise" approach with multiple forests in a single AD app.

Note that the security context of the windows service IQService utilizes is the default security context used by before/after scripts (e.g. PowerShell scripts to add a home drive, etc.).

Thus, if you are not using before/after scripts, you can simply run IQService as Local System (default) - the AD connector credentials (those for each domain in the IIQ app XML) are what are passed to IQService to do a basic bind to each managed directory. If you don't like the default option, you can further limit the windows service account here - as Adam highlights above, the service account needs rights to where the binaries sit, and rights to read the IQService registry keys. Again, this is only the case if you ignore before/after scripts. My general advice here is: if you aren't scripting, just leave the default Local System account.

The credentials that "run" the IQService windows service are only really involved for IQService-based scripting that happens related to provisioning actions.

For scripting on the IQService side here, you would want to run IQService as a privileged, domain account that had rights to run the desired script actions that affect resources for any managed forest domains. You would, in essence, have a highly-privileged account that might have access to a couple Exchange organizations across forests, etc. This also implies you'd have an authentication trust between forests. The windows service "log on" feature supports cross-forest authentication, if it is allowed by your domain/forest architecture.

As an alternative, you could use a more creative solution to inject credentials into scripts so you could fine-tune this authentication for scripted actions - this would an advanced topic.

Does that help clarify?

[yann_kernin]

<< It's also not required anymore to run the service under the service account which is used to connect to AD, as this can't be the same for different domains. >>

I can confirm that IQService will re-login to Microsoft environment with the account configured in IIQ AD Application if the user account is different from the one used to run IQService.

(Take care of versions of the .NET / Powershell layer if you plan to use the same IQService vs multiple AD / Exchange that are of different versions)

Best Regards,

Yann Kernin

Engagement Manager

Professional Services Lead for Asia, CISSP

tel: +65 9450-3012 / address: 1 Raffles Place | #20-26 One Raffles Place Tower 2 | 048616 | Singapore

yann.kernin@sailpoint.com<mailto:yann.kernin@sailpoint.com>

www.sailpoint.com<http://www.sailpoint.com/>

[jude_ighodaro]

I have IIQsevice installed on a separate server:

which ports do I need to be opened on DC and IIQservice server?

Thanks

[justin_choponis]

In case this wasn't answered elsewhere, IQService uses .NET System.DirectoryServices for most AD-related work, which will utilize ADSI as the LDAP provider. In addition, some .NET methods in this related library set may end up using Windows API calls mentioned here via System.DirectoryServices.ActiveDirectory. In either case, know that if you specify "useSSL=true" in the IdentityIQ AD application config, a secure binding technique will be used by not only IdentityIQ calls to AD (as those will all be direct to the LDAP provider from JNDI), but also by IQService code paths doing provisioning or advanced aggregation work. More specifically, IQService code will use AuthenticationTypes.Secure and SessionOptions.SecureSocketLayer flag when useSSL is set as true in the IdentityIQ AD application config (a per-domain setting) when doing a bind to a DirectoryEntry object in the directory. Note the that the credentials for the binding mentioned will be as specified for the domain per the IdentityIQ AD application config; they just get passed through from IdentityIQ to IQService during a provisioning request. These credentials are encrypted as they are sent to IQService.

[justin_choponis]

While it really depends on your overall requirements for your deployment, yes, you could put IQService on a virtual machine running in Azure (running Windows Server). In the case of the Azure connector in IdentityIQ, the connection to Azure AD is done via HTTPS calls, so as long as it can make those necessary calls to the Azure RESTful API endpoints, it should technically work. Having said that, I think it would be worth noting that if IdentityIQ sat in a separate region in the cloud or on-premise, there should be a VPN tunnel established as a fail-safe for secure connection over the Internet. While IQService-to-IdentityIQ communications are encrypted by default (and vice-versa), my advice would still be to use a site-to-site VPN tunnel for security in-depth here.

[justin_choponis]

All IdentityIQ and IQService hosts should be able to use LDAP on TCP 389 (or preferably use TCP 636 for LDAPS) on the domain controllers you want to use for the domains in scope. You'd also want

The IQService host must allow TCP 5050 inbound from all IdentityIQ hosts.

Finally (now the tricky part), the IQService host must be able to utilize a variety of ports (these may be used for some functions that use DCOM or similar in a few cases); as mentioned in the article here, we don't recommend firewalling IQService from the domain controllers due to dynamic port issues as mentioned here: Active Directory and Active Directory Domain Services Port Requirements | Microsoft Docs and in our article above.

[eyapene]

I would like IdentityIQ server access the Exchange server to check the uniqueness of emails and create the new mailboxes.

The IQService is directly installed on IdentityIQ server.

Which ports do I need to be opened between IdentityIQ server and Exchange server ?

Thanks

[andrew_mathieson]

SailPoint Support has seen an influx of cases where the customer has requested to setup IQService Rolling Logs.

You can go to the path  HKEY_LOCAL_MACHINE\SOFTWARE\SailPoint\IQService on the IQService installed server change the below keys:

-maxTraceFiles: maximum number of Trace log files that must get created before overwriting the older files.
-traceFileSize: maximum file size of a trace file in bytes

A new file is created when the current file exceeds this limit.

Restart the IQService service.

For further information:
Using log4net with IQService Scripts
https://community.sailpoint.com/t5/Technical-White-Papers/Using-log4net-with-IQService-Scripts/ta-p/...