Table of Contents |
---|
Luma Serviceaide Automation has the ability to define, build, orchestrate and manage workflows that support system and network operational processes. The Automation Workflow Services can integrate with remote services, servers, applications, and hardware to perform tasks. The orchestration process can cross all management disciplines and interact with all types of infrastructure elements, such as applications, databases, and hardware.
To facilitate automation on systems that are available on the Customer network and cannot be accessed outside the network, Luma Serviceaide Automation supports a hybrid implementation:
SaaS Implementation:
...
Serviceaide Automation cloud instance is implemented on Serviceiaide infrastructure and is maintained by the Serviceaide Support Team. The System Administrator can build and design Workflow services to connect to remote services and systems that can be accessed over the internet.
On-Premise Agent Implementation: The Automation Orchestrator component is deployed on the Customer’s local infrastructure within the customer network or private cloud. The Orchestrator allows integration with services that cannot be accessed outside the customer network, such as Active Directory (AD), and On-premise servers.
Info |
---|
From Release 2.0, the Automation Orchestrator is available as a SaaS implementation. The Orchestrator Engine will now be used to execute the discrete MuleSoft Operations through the Mule runtime. In addition to the Mule operations, it will continue to support the Legacy Mule Workflows (Legacy Connectors). |
On-Premise Agent Deployment Architecture
Below the On-Premise Agent deployment Architecture for Luma automationServiceaide Automation. The Orchestrator component deployed in customer network polls the Cloud instance over HTTPS/443 port for secure and encrypted communication. An outbound connection is only required to be open from the customer network. No inbound rules/ports are required.
...
Following are the server requirements for On-Premise Orchestrator (Agent) deployment:
CPU - 4 CPU1 Core
Memory - 12 4 GB
Hard Disk 500 - 50 GB HDD
Operating System CentOS-7 or RHEL 7
Installed Software - Java 8, MySQL, Mule Run
Docker- current version 19.03.8 is but any 17+ version is supported by our application.
MuleSoft - mule-standalone-3.9.0
MySQL – 8
Server Ports to be opened (Internal)
...
Integration with Active Directory
Serviceaide’s Luma Serviceaide Automation can be directly configured to reach out to AD Server if port 389 is open and available over the internet. If port 389 is not available over the internet and can be made only local, the automation orchestrator server is deployed on-premise which can connect to the local AD server on port 389. Luma Serviceaide Automation cloud instance connects to the Automation Orchestrator server over the internet.
...
Following are the configurations required for Automation Orchestrator Server to connect to Active Directory:
Components | Requirements |
Port | AD Default Port: 389, 5985 or 5986 |
Access Account | User Account with Active Directory Admin Access |
Configuration | Port 389 389 port must be enabled and configured to connect from external systems |
Additional installations | WinRM to be installed on the AD Server |
Username | Active Directory Server Username |
Password | Active Directory Server Password |
Accessibility | Active Directory Server to be accessible/reachable from the Serviceaide Automation server setup in your environment. |
Configuring WinRM
Configuring WinRM is a pre-requisite on Windows AD Server. WinRM is a standard web services protocol used for remote software and hardware management. The WinRM service listens on the network for WS-Management requests and processes. WinRM works with HTTP and HTTPS.
...
Follow the below steps to Configure WINRM to use HTTP:
Run the following command to set the default WinRM configuration values.
c:\> winrm quickconfig(Optional) Run the following command to check whether a listener is running, and verify the default ports.
c:\> winrm e winrm/config/listenerEnable basic authentication on the WinRM service.
Run the following command to check whether basic authentication is allowed.
c:\> winrm get winrm/configRun the following command to enable basic authentication.
c:\> winrm set winrm/config/service/auth @{Basic="true"}Run the following command to allow transfer of unencrypted data on the WinRM service.
c:\> winrm set winrm/config/service @{AllowUnencrypted="true"}
Enable basic authentication on the WinRM client.
Run the following command to check whether basic authentication is allowed.
c:\> winrm get winrm/configRun the following command to enable basic authentication.
c:\> winrm set winrm/config/client/auth @{Basic="true"}
Run the following command to allow the transfer of unencrypted data on the WinRM client.
c:\> winrm set winrm/config/client @{AllowUnencrypted="true"}If the WinRM host machine is in an external domain, run the following command to specify the trusted hosts.
c:\> winrm set winrm/config/client @{TrustedHosts="host1, host2, host3"}Run the following command to test the connection to the WinRM service.
c:\> winrm identify -r:http://winrm_server:5985 -auth:basic -u:user_name -p:password -encoding:utf-8
Configure WinRM to Use HTTPS
...
Follow the below steps to Configure WINRM to use HTTPS:
Generate a self-signed certificate. The following command line contains example syntax for creating a certificate on the WinRM host by using makecert.exe.
makecert.exe -r -pe -n "CN=host_name-3,O=organization_name" -e mm/dd/yyyy -eku 1.3.6.1.5.5.7.3.1 -ss my -sr
localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 certificate_name.cerAdd the generated certificate by using the Microsoft Management Console.
Run mmc.exe.
Select File > Add/Remove Snap-in.
From the list of available snap-ins, select Certificates and click Add.
Select the Computer account and click Next.
Click Finish.
Verify that the certificate is installed in Console Root > Certificates (Local Computer) > Personal > Certificates and Console Root > Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates.
If the certificate is not installed in the Trusted Root Certification Authorities and Personal folders, you must install it manually.
Create an HTTPS listener by using the correct thumbprint and hostname. The following command line contains example syntax for creating an HTTPS listener.
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="host_name";CertificateThumbprint="certificate_thumbprint"}Test the connection. The following command line contains example syntax for testing the connection.
winrs -r:https://host_name:port_number -u:user_name -p:password hostname"
Info |
---|
You may contact the Serviceaide support team for any assistance on On-Premise Agent implementation. Refer to ITAS ESA On-premise Agent v1.1v2.0 Runbook to follow the deployment steps. |
...