Remote AD Connector
DirX Identity can be deployed as part of the Atos Cloud Service Identity Management as a Service (IDMaaS). Provisioning targets can be in the provider’s (Atos) cloud infrastructure, in a public cloud or on customer premises outside of a cloud; the Remote AD connector is intended for use in this last scenario.
The Remote AD connector’s provisioning components must be able to work without online (LDAP) connection to the DirX Identity configuration database.
A standard framework-based agent job implements the export-to file-action on the customer side. It obtains its configuration from XML files: one for the job and one for the search request with the filter conditions. Importing the file to DirX is performed by an existing LDIF import workflow. The following figure illustrates the Remote AD connector architecture.
Security Considerations
Transport connections between the customer and DirX Identity in the cloud should be secured by SSL/TLS.
Requirements and Limitations
To deploy / run the service / client, the following requirements apply:
-
Java 7 installed on the customer side
-
Apache Tomcat 7 installed on the cloud provider side
It is assumed that inbound traffic into the cloud is routed through a reverse HTTP proxy, which basically translates IP addresses. Outbound traffic will also be routed through an HTTP proxy. As a result, provisioning using native interfaces such as LDAP and JDBC are not allowed and are replaced by HTTP-based SOAP protocol (web service).
Access to the customer premises is expected to be strictly constrained: no remote installation, no reading / writing of (workflow) configuration in LDAP, no messaging.
Authentication to DirX Identity and to Active Directory: authentication for the standard connectors is based on user / password. Authentication via user certificates is not supported.
Encryption of passwords stored in local configuration files: in standard configurations with workflows hosted by a Java-based Server, the passwords used for authentication of the connectors are encrypted on transport. Framework-based standalone jobs as described here lack this feature: they do not know the system PIN for decryption of the system certificate and they do not have access to LDAP, where the private key is usually stored.
Remote AD Agent
The Remote AD agent is a client application for the File Upload Web Service, delivered as jar archives, configuration files and batch file(s). The Remote AD connector can be started by an operating system scheduler.
Activities
The agent application performs the following activities:
-
Starts the job that connects to Active Directory and searches and exports users to an LDIF file.
-
Packs the LDIF file and sends it to the File Upload Web service.
-
Deletes the exported LDIF file if the transport is successful.
The Export-AD-to-File Job
The agent exports users from the Active Directory (AD) domain according to a configurable search request and then writes the resulting entries to an LDIF file. Typically not all Active Directory users need to be imported to DirX. You can filter them according to their organizational unit or other attributes or on group memberships.
The export-AD-to-file job is based on the DirX Identity Connector Integration Framework and is illustrated in the following figure. The default standalone controller reads its configuration from an XML file. It receives a search request from the SPML file reader, forwards it to the AD connector and then passes the search response to the LDIF connector, which writes it to a local LDIF file.
Installation
The application requires no installation. To start the agent, run the provided batch file. On the command line, you can specify the trust store path (for example, cacerts) to use when connecting to a secure endpoint. See the content of the batch file remoteADAgent.bat for details.
Configuration
You configure the Remote AD agent with the following files located in the config folder:
-
The wsConfig.properties contains Web service-related parameters.
-
The jobConfig.xml contains the job configuration of the AD export workflow, especially the AD connectivity parameters.
-
The searchRequest.xml contains detailed configuration of the search request performed in the AD, especially filtering and returned AD attributes.
The batch file configures logging and trust store location. See the provided files for details.
File Upload Web Service
The File Upload Web service resides in a servlet container (for example, a standalone Tomcat or IdS-J tomcat) on the cloud provider side. Requests to the Web service consist of:
-
Customer ID <_xs_:_string_>
-
Content of the LDIF file <_xs_:_base64Binary_>
Activities
The Web service performs the following activities on the cloud provider side:
-
Unpacks the received LDIF file and saves it under the configured folder.
-
Invokes a Java-based workflow that corresponds to the received Customer ID. This call is asynchronous, so there is no check to verify the result. The workflow imports the users from the LDIF file into the Identity store.
-
Returns a response message to the client if no problems occurred or generates an error response.
Installation
To install the File Upload Web service, locate the war file under the webapps directory of Apache Tomcat. Tomcat automatically deploys the file. After deployment, adapt the configuration files in the newly created remoteADFileUpload folder and then restart Tomcat. The endpoint URL of the Web service is
http(s)://host:_port_/remoteADFileUpload/ProvisionFileUploadService
Where the host, port and usage of HTTP(s) depends on the Tomcat configuration, as described in the "Configuration" section.
Configuration
You configure the Web service with configuration files located under the WEB-INF/config folder. These files include:
-
config.properties - the default configuration file that is used when a request without a client id is received or if no configuration file for the given customer ID is found.
-
customerID*.config.properties* - customer-specific configuration files. These files are used when an incoming customer ID matches an existing customer configuration file.
The default deployment contains the files config.properties and My-Company.config.properties. (See the files for more details, search for the CONFIGURE tag.)
Configuring SSL on Tomcat
The configuration parameters for Tomcat are specified in the file /conf/server.xml.
To enable SSL:
-
Generate / copy the key store file under CATALINA_BASE/keys/keystore.
-
Edit the following lines in server.xml to enable SSL:
<Connector SSLEnabled="true" acceptCount="100" clientAuth="false"
disableUploadTimeout="true" enableLookups="false" maxThreads="25"
port="443" keystoreFile="keys/.keystore" keystorePass="asd123"
protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
secure="true" sslProtocol="TLS" />
To enable LDAP authentication and authorization:
-
Edit the following Realm element under <Host/>:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionName="cn=DomainAdmin,cn=My-Company"
connectionPassword="dirx"
connectionURL="ldap://localhost:389"
userPattern="{0}"
roleBase="cn=Groups,cn=DirXmetaRole,cn=TargetSystems,cn=My-Company"
roleSubtree="true"
roleName="cn"
roleSearch="(uniqueMember={0})"/>
-
Disable other realms that are not required.
The meaning of the parameters is as follows:
roleBase
Specifies the entry under which the groups are located in the LDAP directory.
connectionName and connectionPassword
Identify a technical user. Tomcat uses this technical user in the bind for the LDAP group search. If an anonymous bind is performed, these parameters are omitted. Currently Tomcat cannot use the authenticated user for performing the search for groups.