Quantcast
Channel: Ivanti User Community : All Content - Cloud Services Appliance
Viewing all 418 articles
Browse latest View live

Cloud Services Appliance ( CSA ) Online activation failed. Try again or contact LANDESK support for assistance. Activation communications error

$
0
0

Cloud Services Appliance ( CSA ) System not activated. Online activation failed. Try again or contact LANDESK support for assistance. Activation communications error. The Cloud Services Appliance was unable to contact the LANDESK license server. Check your network settings. If the Cloud Services Appliance does not have Internet access, click >>here<< to manually...

 

screenshot csa activation fails.png

 

RESOLUTION

 

Add / modify the "Host names" on the Cloud Services Appliance ( CSA ) as follows:

 

IP Address: 67.199.253.210

DNS name: license.landesk.com

Host name: license.landesk.com

 

screenshot csa system file hosts.PNG

 

and activate / reactivate the CSA by going to Activation > Activate Now, entering your username and the password and clicking "Activate online"

 

* Test the username and password used for activation by attempting to login to the Ivanti's Licensing Portal on https://portal.ivanti.com

 

** Test your password in the field Organization ID to see what you are entering as the keyboard layout on the CSA screen might not be match the layout of your keyboard.

 

*** Make sure you spell the word licenSe in license.landesk.com with the letter S and not with the letter C as in licence.landesk.com

 

 

If CSA activates successfully you will see

 

Activation complete..

The system activated successfully

System activation summary

Status: The system activated successfully. Thank you for registering with LANDESK Software.

screenshot csa system file hosts activated successfully.PNG


Failed to post the certificate to the CSA

$
0
0

Problem:

When trying to post your cert from core to CSA, you get a message stating Failed to post the certificate to the CSA. Failed to save the CSA settings.

 

Known Solutions:

  1. Remove any self signed certificates from the CSA Manage LDMG Certificates.
  2. Reboot the CSA
  3. Stop LANDesk Gateway Service, Reset the CSA's Service and Admin account passwords on the CSA. Try to post again.
  4. Verify port 443 from core to CSA is open.
  5. Restart the Landesk management gateway service
  6. Check the .0 files in the ldlogon folder, make sure they have the proper CSA  information and that they are also in the core shared files\keys folder.
  7. Check the connectivy policy being used.
  8. Verify the proper settings in the ...\ManagementSuite\ldlogon\AgentBehaviors\ClientConnectivityBehavior_<corename>_<version>.xml file
  9. Read program files\landesk\managementsuite\log\console.exe.log for more information on the failure to post the cert.

 

 

Note: When encountering this kind of issue, it may be a good idea to also review Unable to Update CSA Information in LDMS

IP Address provided is not valid when trying to connect to CSA from Core server

$
0
0

I have configured the Landesk CSA 4.3 and I am trying to connect from the Core server (LDMS 2016.3) to the CSA, but I keep getting the error below that the IP address provided is not valid.  I know this is the correct IP because I can get to it from the internet and it resolves correctly.  

 

It's a Dual NIC configuration, one NIC in the DMZ and one internal.  I followed the steps in this article - Best Known Method for Configuring LANDESK Cloud Service Appliance (former Management Gateway) version 4.2 and newer Best Known Method for Configuring LANDESK Cloud Service Appliance (former Management Gateway) version 4.2 and newer  .   Traffic is being routed from the internet to the CSA, as I said I am able to get to the url from the internet.  Is there configuration in the DMZ/ Firewall I could be missing?

 

I don't see any connections in the brokerservice.log so its not even able to attempt connecting.  Any ideas where to look or what to do from here??

Network traffic specific for communication betwenn Core and CSA

$
0
0

This document is going to describe some points regarding network communication you can see within Core and Cloud Service Appliance.

 

Ivanti Management Gateway has been built to ensure the highest security level. We are still working on improvements and additional features to fulfill customer requirements.

 

If you have a look on network traffic captured on Core server connected to CSA you can encounter unusual situation. Management Gateway at the end of communication sends TCP packet with RST flag which might be consider as for example TCP reset attack. However, this is totally normal for CSA and its traffic with Core server.

You can also meet a situation when the stream contains only one packet with RST, ACK flags and sequence number is 1. Such a behavior should be also treated as expected.

This is done to reset the broker tunnel a create a new session key for the connection to the CSA. Even though the CSA sent this in this through the tunnel, a connection cannot be established from the CSA.

Agent Configuration settings to detect when to use IP Address vs. FQDN?

$
0
0

So I'm having a bit of an issue with my agent configurations here; i have a variety of machines I manage, some of which are on and off network randomly, but frequently. The network that these machines are on does NOT have a DNS, so in order to communicate with the core directly, it needs to point to the IP address. However, the CSA has an issue resolving to the core server when given the IP address instead of the FQDN. Therefore, i can either have these machines work when they are ON the network, OR off the network, and seemingly not both. Any Ideas?

How To: Change the Public IP Address of the Cloud Services Appliance Updating the Remote Managed Devices Automatically

$
0
0

Environment

 

LANDESK Management Suite 9.5 SP1 and later
Cloud Service Appliance 4.x

 

Scenario

 

You need to change the public IP address used by the remote managed devices, and you want to update their configuration without redeploying the agent or having them connecting to the corporate network.

 

Rationale

 

There are several ways to reconfigure your clients in order to have them connecting to a new Cloud Services Appliance or to its new public IP address such as a LANDESK Agent re-deployment or connecting your managed nodes to the corporate network and have them getting the updated agent settings, or configuring your firewall to redirect the traffic of two public IP addresses to the interface of the appliance, or even setting up a second CSA with the new public IP address and update the connectivity settings of the clients making them switching from a CSA to another.


This article let you update your clients when none of the above options are available. If you have only one appliance, and you have to shut down the former IP address and activate the new one sequentially, you can have your remote clients configured without the need to redeploy the LANDESK Agent, its settings, or having the remote clients connecting to the corporate network to communicate with the Core directly, in the simplest possible way.

The idea is to update the remote managed nodes with the new public IP address PRIOR to change it on the appliance, temporarily losing connectivity with them, wait for all of them running a Security Scan so they can update their connectivity settings and then change the IP address of the Cloud Services Appliance, having the managed devices regaining connectivity with it and with the Core Server.

 

The IP address of the appliance is included in the LANDESK Agent connectivity settings, that are updated automatically on the managed devices that are able to communicate with the core while running a Security Scan.

 

Solution

 

1) Update the Cloud Services Appliance configuration on the Core

 

update_csa_public_ip_address.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2) Update the .0 file replacing the old IP CSA's address with the new one.

 

This is achievable in several ways, for example scheduling a powershell script via policy

Here is a script sample, where the fields <old ip>, <new ip> and <certname> must be replaced with the relevant data:

 

(Get-Content "$env:LDMS_LOCAL_DIR\..\..\Shared Files\cbaroot\certs\<certname>.0") | ForEach-Object { $_ -replace "<old ip>", "<new ip>" } | Set-Content "$env:LDMS_LOCAL_DIR\..\..\Shared Files\cbaroot\certs\<certname>.new"

Remove-Item "$env:LDMS_LOCAL_DIR\..\..\Shared Files\cbaroot\certs\<certname>.0"

Rename-Item "$env:LDMS_LOCAL_DIR\..\..\Shared Files\cbaroot\certs\<certname>.new" <certname>.0

    


3) Open, verify and save the all the Connectivity settings used by the remote managed devices. This will update the related XML file in the %LDMS_HOME%\ldlogon\AgentBehaviors (C:\Program Files\LANDesk\ManagementSuite\ldlogon\AgentBehaviors) with the new appliance's IP.

 

Note: Update the default ClientConnectivityBehavior.xml. Failure to update this, will result in the Brokerconf.xml repeatedly reverting to the old CSA IP.

There may be several ClientConnectivityBehavior.xml files. Either edit all of them to show the new CSA IP address or verify that you have modified the one that is actually being used as default via LDMS Console > Agent Configuration > Properties > Client connectivity > Configure.

 

save_connectivity_settings.png

 

connectivity_settings_xml.png
For 9.6 and later:

 

Update client connectivity profile:

 

Go to Tools > Configuration > Agent settings.
Locate the client connectivity settings that are in use by your agents.
Move the csa to the available section.
Uncheck the box to enable the CSA then click save.
Re open the configuration and then move the CSA to the selected column.

Then click save.
Validate that the settings were updated by checking the client connectivity xml located here: C:\Program Files\LANDesk\ManagementSuite\ldlogon\AgentBehaviors

 


4) Wait for your managed devices to run a scheduled security scan. This schedule depends on how their Agent is configured in the Security and compliance scan > Patch and compliance scan section. This will update the connectivity settings of the remote clients, making them pointing to the new IP address of the CSA and losing connectivity with it.

 

vulscan_settings.png

 

As an alternative, you can manually run the following command on the devices, or include it in a software package distributed via policy and downloadable via http (software package configured via UNC don't work via the appliance).

"%LDMS_LOCAL_DIR%\..\vulscan.exe" /changesettings (silent mode)

"%LDMS_LOCAL_DIR%\..\vulscan.exe" /changesettings /showui (showing the user interface)

 

vulscan_updates_connectivity_settings.png

 

This will make the client lose the connectivity to the former public IP address making it pointing to the new IP address. The connectivity will be re-established once the new public IP address of the CSA will be configured.

 

5) Change the public IP address of the Cloud Services Appliance

 

Client verifications

 

To verify that a client has received the updates, verify that the significant file includes the new IP address of the Cloud Services Appliance:

 

%LDMS_LOCAL_DIR%\..\..\Shared Files\cbaroot\broker\broker.conf.xml

%LDMS_LOCAL_DIR%\..\..\Shared Files\cbaroot\certs\*.0

 

broker.conf.xml_updated.png

 

If it's too late

 

If the IP address of the Cloud Services Appliance has already changed and you haven't had the chance to update your clients using the previous IP address, you lost communication with the managed devices outside the CSA.

 

Some things you can do are:

 

  • Create a powershell script that updates both the .0 file and the broker.conf.xml files
  • Upload the script to the CSA using the Software Package Upload section of the appliance, instructing your user on how to download and execute the script

 

package_upload.png

 

  • Have your remote clients connect to the corporate network so they can run a Security Scan being directly connected to the core

 

Other resources

 

An alternative method to silently update the .0 file on the remote devices:

How To: Silently Update the Management Gateway IP Address in the .0 File

 

The logic user by a managed device to connect to the Cloud Services Appliance is explained in the following article:

How to change the IP address on an established Management Gateway

How To: Change the IP Address on an Established Management Gateway

$
0
0

Overview:

By default clients that connect to the Management Gateway from the internet will use the IP address of the Gateway instead of the domain name. This connection method has both pluses and minuses but if the IP address of the Management Gateway ever changes the clients themselves will be lost and won't be able to connect. Therefore when changing an IP address of an established Management Gateway careful planning must take place.

 

Client Overview:

When a client starts a connection with the Management Gateway it will retrieve connection information in the following order

 

  1. C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.conf.xml (NOTE: This file is not created by default and is usually skipped)
  2. Any broker certificates already on the client.
  3. The hash.0 file located in C:\Program Files\LANDesk\Shared Files\cbaroot\certs

 

Resolution:

There are many different possibilities to correcting this problem. One of the best resolutions is to create a broker.conf.xml file on a test client, modify the file to use the domain name of the Management Gateway and then distribute the file along with an updated hash.0 file to clients. This process will minimize client loss as the client will then use the domain name located in the broker.conf.xml file instead of the IP address.

 

Broker.conf.xml Creation:

The broker.conf.xml file is created when the "Update" button on the "Gateway Information" tab is clicked. The button becomes available when a change is made to the configuration. After creating the file edit the xml and replace the ipaddress in the public domain name for the Management Gateway. Testing this file is recommended. (Note: The broker.conf.xml file is only read when brokerconfig.exe is loaded into memory so reloading brokerconfig.exe is necessary before changes take affect and testing will produce good results)

 

For computers residing within the DMZ which have neither connection to the Internet or Intranet, it is still possible to manage these devices via the LANDesk Cloud Appliance, using the same 'Broker.conf.xml' work-around.

 

1. Creating a specific "Broker.conf.xml" file for the devices in the DMZ.  What you'd do is create the "Broker.conf.xml" on one client in the DMZ by running the "BrokerConfig.exe" manually.  This is in the \ldclient directory.

 

The broker.conf.xml file is created when the "Update" button on the "Gateway Information" tab is clicked. The button becomes available when a change is made to the configuration. You'd want to pick "Connect using the Management Gateway"

 

The ‘Broker.conf.xml’ that is generated is in the \\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker

 

2. The 'broker.conf.xml' should be edited so that the  <ipaddress>xxx.xxx.xxx.xxx</ipaddress> reflects the internal network's IP address.  Having this file in the \\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker directory will cause the agent to use that IP address as opposed to using the public facing address.

 

Remember, the 'broker.conf.xml is only read when BrokerConfig.exe is loaded into memory, so it is necessary to reload BrokerConfig.exe before the devices will use the new address.

 

Note:  Please make sure to test a few devices to make sure the results are what you expect.

 

 

Producing a new hash.0 file:

Open the Configure - Management Gateway option on the core server. Temporarily enter the new public address and click "Ok". You may receive an error concerning communication with the broker. This error is fine and normal. Save the changes anyway. You'll find the new hash.0 file located in C:\Program Files\LANDesk\ManagementSuite\LDLogon folder. (Note: Some cores may have multiple hash.0 files. Open each file and make sure you get the correct one) After the modified hash.0 file is created change the Configure - Management Gateway settings back to what they were before.new

 

Update client connectivity profile:

 

Go to Tools > Configuration > Agent settings.
Locate the client connectivity settings that are in use by your agents.
Move the csa to the available section.
Uncheck the box to enable the CSA then click save.
Re open the configuration and then move the CSA to the selected column.

Then click save.
Validate that the settings were updated by checking the client connectivity xml located here: C:\Program Files\LANDesk\ManagementSuite\ldlogon\AgentBehaviors

 

 

 

Distribute the modified files:

After collecting a broker.conf.xml file and a modified hash.0 file they will need to be distributed to the clients. Configure a policy task through the Management Gateway to replace them.

 

Summary: It will take some time for all clients to check-in. However once the domain name is being used the clients should be able to connect to the Gateway regardless of it's IP Address. It is recommended to plan and start this task well ahead of the actual IP change to the Gateway so that most (if not all) clients are updated.

How To: Download and Patch the 4.3 Cloud Service Appliance Manually

$
0
0

Note: This document applies ONLY to the 4.3 CSA. DO NOT attempt to install these patches on any other version of the CSA.

 

You only need to install the most recent patch. I.E. the highest numbered patch

 

 

Note:The 135 patch is required for 137 to install.

 

Note:Do not attempt to install the 135 patch on CSA that has already had the patch applied. To verify open the CSA Console, go to "About" check the version. if it is dev-135 or greater, do not attempt to apply the 135 patch.

 

 

 

GSB 135-177: DO NOT INSTALL. USE MOST RECENT PATCH

 

Latest Patch

 

GSB 184:

http://patch.landesk.com/patches/GSB431_184.tar.gz

 

To Install GSB 155+:

  1. Download most recent patch to your computer.
  2. Copy the file to the /tmp directory on the CSA. The easiest way to do this is using WinSCP (WinSCP :: Official Site :: Download) or FileZilla (FileZilla - Client Download)
    1. Connect using the CSA IP or name, while using port 22.
      31494-winscp-login.png
    2. You will be prompted to add the host key to the cache, click yes.
      31494-winscp-hostkey-prompt.png
  3. You will be given 2 panes, one for your local machine and one for the CSA.
    31494-winscp-view.png
      1. You may need to traverse up the directory tree until you find the tmp folder.
      2. Find the file on the pane for your local machine and copy the CSA upgrade file that you previously downloaded to the tmp folder on the CSA.
  4. Once copy is done, SSH into the CSA. You will need to use the admin account.
  5. Run the following commands: Note: The CSA is a Linux machine, don't forget that commands are case sensitive.
    1. cd /tmp
    2. sudo tar -xvf GSB431_###.tar.gz
      (replace the ### symbols with the number of the patch you downloaded)
    3. enter the password for the admin user
    4. cd GSB431_###
    5. chmod +x patch.sh
    6. sudo ./patch.sh
  6. CSA will update and reboot as part of update.

 

 

 

Older Patches

 

GSB 155+ are cumulative patches. You can download and install this from any patch level

 

GSB 135:

http://patch.landesk.com/patches/GSB431_135.tar.gz

 

GSB 137:

http://patch.landesk.com/patches/GSB431_137.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-31414

 

GSB 145:

http://patch.landesk.com/patches/GSB431_145.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-31861

 

GSB 146:

http://patch.landesk.com/patches/GSB431_146.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-31862

 

GSB 155:

https://patch.landesk.com/patches/GSB431_155.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-32520

 

GSB 157:

https://patch.landesk.com/patches/GSB431_157.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-32767


GSB 158:

https://patch.landesk.com/patches/GSB431_158.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-32831

 

GSB 160:

https://patch.landesk.com/patches/GSB431_160.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-32840

 

GSB 167:

https://patch.landesk.com/patches/GSB431_167.tar.gz

Bulletin:

https://community.landesk.com/support/docs/DOC-34072

 

GSB 169:

https://patch.landesk.com/patches/GSB431_169.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 169) 27-MAR-2015

 

GSB 171:

http://patch.landesk.com/patches/GSB431_171.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 171) 09-APR-2015

 

GSB 172:

http://patch.landesk.com/patches/GSB431_172.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 172) to Facilitate iOS Devices to Enroll and Synchronize with MDM Through the CSA 05-AUG-2015

 

GSB 173:

http://patch.landesk.com/patches/GSB431_173.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 173) 31-AUG-2015

 

GSB 174:

http://patch.landesk.com/patches/GSB431_174.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 174) 25-SEP-2015

 

GSB 175:

http://patch.landesk.com/patches/GSB431_175.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 175) 27-JAN-2016

 

GSB 176:

http://patch.landesk.com/patches/GSB431_176.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 176) 25-FEB-2016

 

GSB 177:

http://patch.landesk.com/patches/GSB431_177.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 177) 13-JUN-2016

 

GSB 178:

http://patch.landesk.com/patches/GSB431_178.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 178) 12-Aug-2016

 

GSB 179:

http://patch.landesk.com/patches/GSB431_179.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 179) 07-OCT-2016

 

GSB 180:

http://patch.landesk.com/patches/GSB431_180.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 180) 27-OCT-2016

 

GSB 181:

http://patch.landesk.com/patches/GSB431_181.tar.gz

Bulletin:

LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 181) 17-NOV-2016

 

GSB 182: (will auto reboot)

http://patch.landesk.com/patches/GSB431_182.tar.gz

Bulletin:

Ivanti Patch News Bulletin: Ivanti has Provided an Update for CSA 4.3 - (Patch 182) 21-FEB-2017

 

GSB 183:

http://patch.landesk.com/patches/GSB431_183.tar.gz

 

Bulletin:

Ivanti Patch News Bulletin: Ivanti has Provided an Update for CSA 4.3 - (Patch 183) 31-MAY-2017


Cannot Activate CSA

$
0
0

We are trying to activate our CSA but when I enter the details and click Activate I get a HTTP 500 error:

 

 

Is this an issue with the CSA?

 

It seems to be working OK but is not activated.

9.6 Cores Fail To Connect To CSA After 184 Patch

$
0
0

Description

 

This doc will cover configuration of the CSA for 9.6 SP3 cores after upgrading to the CSA to 184 ( link to bulletin)

 

Cause

 

CSA update 184 has a bug fix to enforce TLS for all traffic. The cause was 1.1 (default) would fallback to 1.0 with calls from the core- Client side would use 1.1 and 1.2. Since then we have increased the TLS version of all calls by our applications to 1.2 but in 9.6 some application/services would still use 1.0.

 

Resolution

 

Currently in 9.6 you will need to lower the minimum TLS version the CSA allows, this is done on the console shown below:

 

 

As you can see the default is set to 1.1 and will need to be changed to 1.0 for 9.6 Cores only. All future versions (2016.X, 2017.X) will handle the 1.1 and 1.2. 2016.1 does have issues with the console formatting if you change it to 1.2 and would recommend you use a higher core version in case you want to limit all traffic to 1.2 only. 

 

Please see the downloads page to upgrade core and helpful links prior to upgrading your core.

 

Ivanti PXE Representative

$
0
0

Hi, we'd like to make use of this option to improve our bare metal build processes. Does the PXE representative need to run Windows, or can we deploy a Unix PXE Representative?

Cloud Services Appliance - How To Add a Persistent Static Route

$
0
0

Environment

 

LANDesk Cloud Services Appliance 4.3 and 4.4

 

Problem/Issue/Symptoms

 

The Cloud Services Appliance is unable to talk with the Core
The Cloud Services Appliance is unable to talk with the Internet

The Cloud Services Appliance is correctly configured on the Core but is unable to activate online
The Cloud Services Appliance has two network interfaces configured both with a gateway - only one is working

 

Solution 1

 

route add COREIP ethX

 

ethX is the internal NIC. By default this is eth1, however on the VCSA it may be different. The highest numbered nic typically

 

Example:

route add 10.14.115.10 via eth1

 

Solution 2

 

Having two gateways configured on a single device simply doesn't work, as the device will just use one of the two,

If the Cloud Services Appliance has two network interfaces configured, make sure the only one interface, the one talking to the internet, has a default gateway configured.


Then, if the Core Server is on a different network segment than the Cloud Services Appliance, and the next hop to reach the Core server is different than the default gateway, you need to set up a static route to address the traffic to the core via the correct router/firewall.

 

Static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file.
For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file.

 

Example

 

Cloud Service Appliance with two network interfaces configured

 

Interface eth2 connected towards the internet
IP address 192.168.1.3 subnet mask 255.255.255.0 default gateway 192.168.1.1

 

Interface eth3 connected towards the LAN and the Core Server
IP adress 10.1.1.3 subnet mask 255.255.255.0 no default gateway, next hop to reach the Core 10.1.1.1

 

Core Server with IP address 10.20.20.1 subnet mask 255.255.255.0

 

 

csa_network_configuration.png

 

 

What we need to do is configuring a static route to instruct the appliance to reach the network segment 10.20.20.0/24 via our next hop with IP address 10.1.1.1, for the interface eth3.

 

WARNING: Because we are operating on the network configuration of the appliance, it's safe to operate directly on the device's console, or at least having the possiblity to physically reach the device with a local keyboard and monitor in case of the network connectivity problems and especially if the appliance is off site.

 

1) Open the local console command line interface, press CTRL+ALT+F2 or open a SSH session to the appliance with an SSH client and elevate the command line with 'sudo su' and the admin password

2) Create or update the file /etc/sysconfig/network-scripts/route-eth3 with the following line 10.20.20.0/24 via 10.1.1.1

3) Reload your network configuration with the command service network reload

4) Verify the new static route with the command route

5) Verify you can correctly communicate wirth the appliance from the Core Server

 

 

static_route.png

Quick Guide - Gateway (Cloud Service Appliance) Configuration

$
0
0

Prerequisites:

 

Download and install the Cloud Service Appliance.  To download a pre-installed virtual machine CSA, follow this link:

Cloud Services Appliance From 4.4 Upgrade and New Installs

 

Description:

 

This document is meant to validate basic configuration of the Cloud Service Appliance. It takes into account most all potential configuration issues. Please read step-by-step as that is how this document was created.

 

Here is a video of the process that includes core and agent side information: LANDESK - CSA - Installation and Configuration - YouTube

 

 

Note: With the Virtual CSA, you may see eth0 and eth1, or eth2 and eth3, etc… this is normal. The lowest numbered NIC is typically the external NIC.

Additional information: If you use two NICs, you may need to create a static route. Please see: Cloud Services Appliance - How To Add a Persistent Static Route

 

Steps:

  1. Click System > Configure date and time- Click Save to commit changes
  2. Click on System > Network Settings
  3. Remove any references to the 192.168.0.1 and 192.168.0.2
  4. Set IP, subnet, and gateway for your network on eth0
  5. Click add
    1. If you are setting up dual NIC repeat steps 5 and 6 for eth1, else move on to 7
  6. Enter internal DNS server if applicable
  7. Click add
  8. Set the hostname and DNS suffix for your device
  9. Click save
  10. Click on the hostnames tab
  11. Remove any references to the 192.168.0.1 and 192.168.0.2
  12. We will want to add the core server(s) here
    1. Take note of the format as it is different for different items
  13. Core IP, Core FQDN, Core Hostname (no caps) click add
  14. Ping license.landesk.com, patch.landesk.com and patchec.landesk.com to validate the IP addresses as they are always subject to change
  15. Enter  67.199.253.210, license.landesk.com, license.landesk.com click add
  16. Enter 64.40.112.98, patch.landesk.com, patch.landesk.com click add
  17. Enter 67.59.141.4, patchec.landesk.com, patchec.landesk.com click add
  18. Enter 84.51.239.169, patchemea.landesk.com, patchemea.landesk.com click add
  19. Click save
    HostNames.png
  20. Click on the security section
  21. Remove any subnets you use from the blocked list
    1. Take note of the subnets and if they overlap your ranges
  22. Add the core IP to trusted list, even if you plan to disable the firewall it will ensure if for some reason it is turned back on your core will still connect
  23. Add the 204.246.129.106, 64.40.112.98, 84.51.239.169, and 67.59.141.4 IP's in the trusted. These are the LANDESK patch and license servers
    trusted.png
  24. Click save at the bottom
  25. Click on the users section. Make sure you know the service account password; we will need this to configure the core. It will only be used on the core server(s) in one location(Configure > Manage Gateway/Manage Cloud Service Appliances), so if you don't know it go ahead and reset it so you can have the correct password
  26. Click on the Gateway Service Section. In the additional Hostnames section you will want anything the gateway can resolve to or from, FQDN, internal and external IP. DO NOT ADD SHORTNAMES
  27. Click Save
  28. Activate CSA- Click on Activate>Activate Now>Enter your Landesk License credentials.**This must be done over internet for the first activation**
  29. Install Patches (See link for order of operation in regards to 4.2 CSA)
    1. Best Known Method for Configuring LANDESK Cloud Service Appliance (former Management Gateway) version 4.2 and newer
  30. The next steps apply only to 4.3 and 4.4 CSA and only after the first time its patched
  31. Click Manage LDMG Certificates
  32. For self-signed certificates only, click Remove
  33. Click OK to verify you want to remove the certificate
  34. Repeat process to remove the second certificate
  35. Click System
  36. Click Appliance
  37. Click Reboot
  38. Click OK to verify the reboot
  39. If this is a VM take a snapshot at this point as it will be your base configuration
  40. Access CSA via web browser http://CSAIP
  41. Click Cloud Service Appliance Console link
    1. if you see this certificate prompt, click cancel until you get a username and password prompt
      cert.png
  42. Login with the admin user
  43. Click System > Backup and restore
  44. Click Backup Now
  45. Export backup
  46. Your CSA is now ready to have the core server connection configured

How to update the CSA version 4.3 and above (Cloud Service Appliance)

$
0
0

Disclaimer:This only applies to CSA version 4.3.4.2 is no longer supported and will need to be upgraded to 4.3. Please visit: How To: Upgrade the Cloud Services Appliance From 4.2 to 4.3

 

Issue:

The cloud service appliance isn't the latest version. This causes concern for those who wish to make sure security patching is up-to-date. This document also briefly addresses patching and changes to the CentOS operating system.

 

Resolution:

Ivanti has released a new operating system for CSA version 4.4, for those inquiries, please visit:

Cloud Services Appliance From 4.4 Upgrade and New Installs

Cloud Service Appliance 4.4- Creating vCSA 4.4

Cloud Service Appliance 4.4- Upgrading The Physical Appliance

 

To check your CSA version:

  1. Log into the CSA
  2. Click About in the left column
  3. Look to the right of LANDesk Cloud Services Appliance release: (dev-123 is version 4.3)

 

 

 

To update within the CSA:

  1. Log into the CSA
  2. Click System in the left column
  3. Select the Updates tab
  4. Press the Scan For Updates button
  5. Apply any desired patches

 

 

How to manually update the CSA:

Sometimes it is necessary to update manually via SSH. The following document explains how this is done: (This doesn't contain information on how to update the CentOS operating system)

How To: Download and Patch the 4.3 Cloud Service Appliance Manually

 

 

How do I update the CSA's CentOS operating system?:

The CentOS operating system is not meant to be upgraded or patched directly and would void support for the CSA appliance.

There were many precautions taken by the engineers to ensure the security of the appliance. More information can be found here:

CSA 4.3 Hardening

Hosting Files on the CSA

$
0
0

Description:

As part of patch 4.3.1-176; For security reasons, the "Software package upload" capability has been removed.  It will no longer appear as a choice on the CSA main menu page. (See here for more info about this patch - LANDESK Patch News Bulletin: LANDESK has Provided an Update for CSA 4.3 - (Patch 176) 25-FEB-2016). In order to still host files on the CSA (ie, on-demand agents), the files will need to manually be uploaded to the CSA.

 

Resolution:

 

1. Copy file to CSA

     a. Using WinSCP- a free SFTP, SCP and FTP client for Windows (https://winscp.net/eng/download.php), transfer the file (ie, on demand agent, putty, etc) to /opt/landesk/broker/webroot/client/packages.

 

File copied to CSA.png

 

2. Allow web service to offer file for download

 

     a. Still in WinSCP, right-click in the /opt/landesk/broker/webroot/client/packages folder, select New - File from the menu.

ss (2016-03-29 at 12.11.00).png

 

Name the new file as file.exe.desc (ie, putty.exe.desc, ondemand-agent.exe.desc)

ss (2016-03-29 at 12.12.35).png

 

Edit the newly created file, added the full name of the file (putty.exe, ondemand-agent.exe) and save your changes.

ss (2016-03-29 at 12.13.20).png

 

 

To confirm this worked, go to the CSA and select Cloud Services Appliance Utilities - Support Tools from the left-hand side. You should now see your file listed here to download.

ss (2016-03-29 at 12.13.55).png

 

If unable to copy/create folders though WinSCP, it can be done through command line:

*** The example uses putty.exe, you'll need to replace putty.exe with your_file.exe

 

1 .Get file to CSA

Using WinSCP- a free SFTP, SCP and FTP client for Windows (https://winscp.net/eng/download.php), I transferred the putty.exe (the exe I was using for test purposes) to a directory on the CSA that the admin has access to- I used the /home/admin directory in this case.

 

2. Move file to correct folder

After transferring the file, using SSH to connect to the CSA, transfer the file from the home/admin/ directory to the directory in which packages are hosted to be accessed by the web interface-

/opt/landesk/broker/webroot/client/packages.

 

To do so:

sudo su (to ensure you have full root access)

mkdir /opt/landesk/broker/webroot/client/packages

CD /home/admin

ls (to verify the putty.exe package is visible there)

cp putty.exe /opt/landesk/broker/webroot/client/packages

cd /opt/landesk/broker/webroot/client/packages

ls

CustomOnDemand1.exe CustomOnDemand1.exe.desc putty.exe

(as you can see the putty.exe file is present on the device in the proper location.)

 

3. Create .desc for file

After the file is copied- a .desc file needs to be created with the proper contents to allow the web service to offer the .exe for download.

 

To do so:

cd /opt/landesk/broker/webroot/client/packages

touch putty.exe.desc (creates the file)

vi putty.exe.desc (opens up visual text editor to add the publicly visible title of the file- in this case putty.exe)

putty.exe (I added this line)

:wq (closes out of vi and saves changes)


Disable Cipher Suite

$
0
0

Hi

 

We have been alerted that our CSA is showing as running vulnerable cipher suites as below by an external scanning tool, and been asked if we can exclude them.

 

Can anyone advise how to go about this or if we can change an ssl config file on the device itself. It is running the latest OS version.

 

TLS_EDCH_anon_WITH_AES_256_CBC_SHA(0xc019)

TLS_EDCH_anon_WITH_AES_128_CBC_SHA(0xc018)

 

thanks

CSA Brokerconfig Test Fail

$
0
0

Hi,

 

Does any encounter this error during testing the CSA brokerconfig connection?

 

CSA-Error.PNG

What ports are used by the Cloud Services Appliance ( CSA ) / Management Gateway ?

$
0
0

Description

The Cloud Services Appliance ( CSA ) / Management Gateway must have communication to the following locations:

 

  1. Device on the public Internet.
    1. Agents connect from the Internet.
    2. Gateway connects to the LANDesk Activation Servers.
    3. Gateway connect to the LANDesk Update Servers.
  2. The Core Server connects to the Cloud Services Appliance ( CSA ) / Management Gateway with a Secure Connection on port 443.
  3. Management connections, usually from the IT Adminsitrators' workstation to the Cloud Services Appliance ( CSA ) / Management Gateway.
  4. The Cloud Services Appliance ( CSA ) / Management Gateway can send out administrative emails.

 

Port 443 is the only required port for full functionality

 

 

Cloud Services Appliance ( CSA ) / Management Gateway to / from the Internet


HTTP (TCP Port 80)

  • Incoming - Workstations on the internet connect to download tools such as the Remote Control Viewer and the On-demand Remote Control Agent. (this is optional and can also be done over 443)
  • Outgoing - Cloud Services Appliance ( CSA ) / Management Gateway updates and activation. (This can be narrowed down to just connect to license.landesk.com and patch.landesk.com on 80 via external firewall rule)

 

HTTPS (TCP Port 443)

  • Incoming - Agent workstations connect from anywhere on the internet.
  • Outgoing - Management Gateway updates and activation. (This can be narrowed down to just connect to license.landesk.com and patch.landesk.com on 443 via external firewall rule)

 

DNS (TCP and UDP Port 53)

Note: This is not required for functionality as host entries can be made manually as well

  • Outgoing -DNS should only be required for resolving the activation server for online activation and for resolving the update servers for downloading and applying updates.
  • This may also be used to resolve the Core Server name.

 

DNS (UDP Port 53)

Note: This is not required for functionality as host entries can be made manually as well

  • Outgoing -DNS should only be required for resolving the activation server for online activation and for resolving the update servers for downloading and applying updates.

 

Note: The hosts file can be configured with addresses for the Core Server, Activation Servers, and Update Servers.  See this article for more information:The Management Gateway Appliance Now Allows for Adding Host Entries to /etc/hosts through the Web Interface

Core Server to/from the Gateway

HTTPS (TCP Port 443)

  • Incoming - The Core Server establishes secure connections to the Management Gateway.

Management connections

SSH (TCP Port 22)

  • Incoming -SSH is only required for allowing remote administration and/or troubleshooting. This is not required for functionality

 

HTTP (TCP Port 80)

  • Incoming - For access to the web interface allowing remote administration. (this is optional and can also be done over 443)
  • Incoming - Other local workstations may connect to download tools such as the Remote Control Viewer and the On-demand Remote Control Agent.(this is optional and can also be done over 443)

Gateway to a Desired Mail Server

SMTP (TCP Port 25)

Note: This is not required for functionality

  • Outgoing - SMTP is only required for sending administrative emails to the email address configured to receive such alerts.

"Test" in brokerconfig.exe gives SSL Handshake Error

$
0
0

Problem

 

SSLhandshakeError.png

 

Connection through management gateway failed 10 SSL Handshake Error

 

Cause

 

The CSA doesn't have all the certificates that the client has under "Manage Core certificates".

The client has an older broker certificate that isn't signed by all certificates on the client.

 

Solution

 

Check the client certificates (C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\certs) and see if there are any files that don't match what is on the CSA "Manage Core certificates" list. If there are, move those certificates to an Old certs folder and test this again. If this doesn't work, put the certs back and try the next step.

 

On the core server, go to Configure>Manage Cloud Services Appliances... and choose to edit your current CSA. Click Apply and this should repost the core server certificates to the CSA. If your client has more certificates than your core is posting to the CSA, open the client connectivity settings and select the other certificates that the client is using and repost.

 

NOTE: Once you have more than 4 or 5 certificates, I would recommend cleaning those up and only using 3 certificates at most in your environment.

 

You may also be able to resolve this by simply deleting all files under the broker folder (C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\broker\broker.conf.xml) except for broker.conf.xml and requesting a new certificate using C:\Program Files (x86)\LANDesk\LDClient\BrokerConfig.exe "Send Request".

CSA Syslogs - Point to a syslog server

$
0
0

Hello,

Is there a way for the CSA to point to a syslog server for all logs.

Other software vendors are able to do this not sure if it's possible on the CSA.

 

Thanks

Viewing all 418 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>