On-Premise Implementation

Luma 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 Automation supports a hybrid implementation:

1. SaaS Implementation: Luma 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.

2. On-Premise 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), On-premise servers.

On-Premise Deployment Architecture

Below the On-Premise deployment Architecture for Luma 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.

Orchestrator Server Requirements:

Following are the server requirements for On-Premise Orchestrator deployment:

• CPU - 4 CPU

• Memory - 12 GB

• Hard Disk 500 GB HDD

• Operating System CentOS-7 or RHEL 7

• Installed Software - Java 8, MySQL

Server Ports to be opened (Internal)

• For HTTP/S : 80,443,8090

• For SSH: 22

• For Uptime: ICMP Ping Enabled

Integration with Active Directory

Serviceaide’s Luma 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 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:

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.

Configure WinRM to Use HTTP

You can configure the WinRM host to enable communication through the HTTP protocol. You must modify the WinRM configuration by running commands on the WinRM host machine. You can use the same machine as both the WinRM service and WinRM client.

Follow the below steps to Configure WINRM to use HTTP:

1. Run the following command to set the default WinRM configuration values.
   c:\> winrm quickconfig
   

2. (Optional) Run the following command to check whether a listener is running, and verify the default ports.
   c:\> winrm e winrm/config/listener
   

3. Enable basic authentication on the WinRM service.

   1. Run the following command to check whether basic authentication is allowed.
      c:\> winrm get winrm/config

   2. Run the following command to enable basic authentication.
      c:\> winrm set winrm/config/service/auth @{Basic="true"}

   3. Run the following command to allow transfer of unencrypted data on the WinRM service.
      c:\> winrm set winrm/config/service @{AllowUnencrypted="true"}
      

4. Enable basic authentication on the WinRM client.

   1. Run the following command to check whether basic authentication is allowed.
      c:\> winrm get winrm/config

   2. Run the following command to enable basic authentication.
      c:\> winrm set winrm/config/client/auth @{Basic="true"}
      

5. Run the following command to allow the transfer of unencrypted data on the WinRM client.
   c:\> winrm set winrm/config/client @{AllowUnencrypted="true"}
   

6. 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"}
   

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

You can configure the WinRM host to enable communication through the HTTPS protocol. The WinRM host requires a certificate so that it can communicate through the HTTPS protocol. You can either obtain a certificate or generate one. For example, you can generate a self-signed certificate by using the Certificate Creation Tool (makecert.exe) that is part of the .NET Framework SDK.

Prerequisite

Verify that you can access the Microsoft Management Console (mmc.exe) on the WinRM host.

Procedure

Follow the below steps to Configure WINRM to use HTTPS:

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

2. Add the generated certificate by using the Microsoft Management Console.

   1. Run mmc.exe.

   2. Select File > Add/Remove Snap-in.

   3. From the list of available snap-ins, select Certificates and click Add.

   4. Select the Computer account and click Next.

   5. Click Finish.

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

3. 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"}
   

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