LANDesk® Management Gateway

Administrators Guide to Managing the Management

Gateway Appliance version 4.0 and 4.2

Introduction .......................................................................................................................... 3

Scope .................................................................................................................................... 3

Assumptions ......................................................................................................................... 3

Installation, Configuration, and Usage ................................................................................. 3

Security ................................................................................................................................ 3

User Accounts ................................................................................................. 3

SSH: ................................................................................................................ 4

General Security Information: ......................................................................... 4

Backing up the Gateway ...................................................................................................... 5

Configurebroker.exe ............................................................................................................. 5

Brokerconfig.exe .................................................................................................................. 5

Reports ............................................................................................................................... 10

System Logs .................................................................................................. 10

File System Report ........................................................................................ 14

The Connection Table ................................................................................... 14

System Test ................................................................................................... 15

Software Packages......................................................................................... 15

Gateway Service Configuration ......................................................................................... 15

Patching .............................................................................................................................. 16

Activation ........................................................................................................................... 16

Remote Control and Scopes ............................................................................................... 16

The Management Gateway Root Certificate ...................................................................... 17

Conclusion ......................................................................................................................... 17

About LANDesk Software ................................................................................................. 19

Contents

Introduction

Administration of any network device is crucial to its security and efficient usage. The Management Gateway is no

different. This document will help with interpreting logs, security recommendations, backing up the gateway, and

other administrative tasks. At the end of this document information will be provided on training videos for

configuring clients, how the gateway works, and how to use the gateway to track down stolen hardware.

Scope

The scope of this whitepaper will include general administration tasks in managing the Management Gateway.

These tasks will include security precautions, use of tools, analyzing the logs, etc. Other procedures such as backing

up the gateway, installing and configuring the gateway, and using the gateway are covered as well but most

information will reference pre-established online documents.

This document is primarily designed for the following gateway releases but information in this document may be

helpful to other releases as well:

Assumptions

This white paper assumes that the reader has basic knowledge of the Gateway and has a Gateway to use.

Installation, Configuration, and Usage

In addition to this document two other documents will be available, one for installing the Management Gateway and

one for users of the Management Gateway. These three documents will be listed together on the LANDesk

Community. Administrators are encouraged to read each of the three documents.

Security

Many steps have been taken to harden and secure the Management Gateway. The article in the link below

documents many of the steps. However, as with any device there are many steps that should be taken in

addition to the included security features to protect the device and the environment in which it’s located.

What steps have been taken to harden the Management Gateway:

http://community.landesk.com/support/docs/DOC-4336

User Accounts

Two special user accounts are automatically created on the Management Gateway: ―admin‖ and ―service‖

“admin” – This account functions very similar to the root user on a typical Linux machine. The

management of this account is probably THE MOST IMPORTANT TASK to be performed on the Management

Gateway. Several functions can only be performed by this user (such as logging on when directly at the

Management Gateway). A very strong password is highly recommended and the password should be rotated on a

regular basis. A very strong password is one that includes the following:

- Upper Case Letters

- Lower Case Letters

- Symbols

- Numbers

- At least 6 characters in length

- It doesn’t fit a particular pattern. ―Ex@mp!e‖

“service” – This account is for the service level connections coming from core servers. Although not as

important as the ―admin‖ account a secure password is recommended as well and needs to match the password

entered on each connecting core server.

Two creatable account types are available for users of the Management Gateway: Admin and Non-Admin

Admin Accounts – This account type shouldn’t be confused with the ―admin‖ account documented above.

These accounts have access to the GSB web page on the Management Gateway and can make any and all changes in

the GUI. It is recommended to create these accounts only for users that genuinely have a need for this level of

access. (It’s important to note that currently any administrator can change the password for any other administrator

including the primary ―admin‖ account) For most users a non-admin account will suffice as once the Gateway is

configured and in place the GSB web page is typically only accessed for user management, troubleshooting, and

Gateway Management. These users will not have the ability to log in when directly at the Management Gateway.

Non-Admin Accounts – These standard accounts will only have access to remote control devices

connecting to the Management Gateway and should work for most users. These users cannot access the GSB

Administrator Page or log in when directly at the appliance.

SSH:

By default SSH access is disabled and when not needed we recommend configuring the firewall to block access to

this daemon. This is done simply on the Security page of the Management Gateway Web Console. Just like other

servers SSH access is a common channel for attacks on the Management Gateway. Running the statistics and reports

regularly can show various attacks in progress. For more information on using the built-in reports please see the

―Reports‖ section of this document.

It is important to note that the main ―admin‖ account is the only account that can access a terminal session

on the Management Gateway. This can be done by ALT + F2 and then right-click when you are at the

appliance itself or through established SSH sessions when using a terminal program like Putty.exe

General Security Information:

The ultimate purpose and design of any security structure is to be impenetrable to unauthorized access. In many

cases even outside of the computer industry a slight modification to the design by someone who isn’t familiar with

the entire structure can cause security holes to emerge in other areas. Even with proper changes very thorough

testing must be performed. The Management Gateway is designed to be an appliance and shouldn’t be modified by

anyone outside of the manufacturer. Some steps in this document may show you how to gain access to the OS but it

is strongly recommended that nothing be modified outside of support recommendations.

Backing up the Gateway

Backing up the Gateway on the Appliance is relatively easy to do. In the ―System‖ section of the Management

Console and on the ―Backup and restore‖ tab you can create manual or automatic backups. These backups will

persist through a system reimage. Also, after these backups are created you have further options to export the

backups off the Gateway which can then be imported at a later time. This feature can be very helpful if a lot of users

are configured on the Gateway. Without proper backups each user would need to be recreated manually in the event

that service is needed on the appliance.

Configurebroker.exe

Configurebroker.exe is an application that you may run into when configuring or evaluating the Management

Gateway. This application works great but officially it is unsupported due to possible security problems. As with

many similar applications configurebroker.exe will make certain tasks much easier so it’s advisable to evaluate the

security cost to efficiency ratio. Listed below is a community.landesk.com article that discusses

configurebroker.exe, provides the executable, gives security precautions, and its usage.

http://community.landesk.com/support/docs/DOC-1888

Brokerconfig.exe

How brokerconfig.exe works and a detailed process flow is included in the Management Gateway Video referenced

at the end of this document. However, it is a very important process so it will be covered in detail in this document.

Brokerconfig.exe is the application on the client that is used to request certificates from the core server. It is a

common misconception that when running this application we are requesting certificates from the Management

Gateway. The truth is that the Gateway is forwarding the request to the client’s core server. Authentication and

Certificate Management are both handled by the core. The Gateway itself only bridges incoming connections from

the client and core.

When the Management Gateway is configured on the core server the Gateway information is automatically

appended to the .0 certificate file. This certificate file is then installed along with the LANDesk agent. It’s important

to realize that any client that was installed before the Management Gateway was configured will not have this

information. Remote Control will have an option to ―Switch to Gateway Mode‖ if the .0 certificate file has Gateway

information which can then be used to run brokerconfig.exe and request certificates. Once a client has certificates

then Inventory, Security, Policies, etc will be able to contact the core from anywhere on the internet.

When running brokerconfig.exe to request certificates there are a few things to be aware of. The most important

item is the method of connection. Brokerconfig.exe is designed to be run either on the network or while connected to

the internet. No matter where the client is connected it needs to find the core server. Listed below (and in the

screenshots) are the three connection methods along with some additional information:

1- Dynamically determine connection route – This is the default selection. Brokerconfig.exe will attempt to

resolve the core name and if it does so it will stop trying all other methods. It doesn’t matter if

brokerconfig.exe can actually reach the core or not. If the core cannot be resolved then it will attempt a

Management Gateway connection.

2- Connect directly to LDMS core – This option is self-explanatory and seldom used. Typically when the

client is on the network it can resolve the core so the first option will work.

3- Connect using the Management Gateway – This option is a very good option to try if dynamically

determine is having problems. A gateway connection will be attempted using the gateway’s IP address and

skip resolving the core.

The next important item in brokerconfig.exe is the credentials. For windows based systems credentials are not

required if the client is on the network and has a direct connection to the core server. If the client is on the internet

and is connecting to the core through the Management Gateway then a domain\username and password is required

of a valid account on the LANDesk Core server. If the core is version 8.8 then any user in the LANDesk

Management Suite local group will work. If the core is version 9.0 then a user in the LANDesk Administrators

Group will work or a special account may need to be configured. More information on 9.0 users is found in the

previously referenced configurebroker.exe article and in the community.landesk.com. (Note: In LANDesk 9.0 the

account used will need to specifically have read/write access to the …\LANDesk\ManagementSuite\Brokerreq

folder on the core server so that client certificates can be posted)

There are a few other issues that should be noted. When a client is making a connection through the Management

Gateway the request is made with ―hostname.*‖. Afterwards a DNS lookup is performed and a POST is made to

brokerservicerequest.asmx in IIS. Due to the gateway connection and different ways that IIS and DNS are

configured in environments the coreserver name on a client may need to be modified. The coreserver name is

located in the registry under HKLM\Software\Intel\LANDesk\LDWM\Coreserver. Use the following rule as a guide

to follow: ―Most environments will work with the hostname, some will work with the FQDN, but none will work

with the IP address‖.

The ―Test‖ button in brokerconfig.exe is a great way of troubleshooting certificate request problems but the results

need to be understood. The method of connection (as discussed earlier) determines how the connection is established

to the core and will vary the test results. The screens shots below were all performed using the ―Dynamically

determine connection route‖ option. If one of the other options is selected then several steps in the test may not be

performed.

In this particular screenshot I shut down the core server to demonstrate a 404 error. If I were to read the results of

the test it would be as follows: ―Name resolution to the core was attempted and found. A connection directly to the

core was attempted but failed (this is normal if the client is not on the network) Since a connection directly to the

core failed a Management Gateway connection is attempted. A connection to the Gateway is made (not shown) and

a link request through the Gateway is made. During this link request the hostname (as discussed earlier) is passed to

the Gateway which waits for a response. A response was received ―404 description Not Found‖ which means the

core server was not found on the Gateway. This can be typically caused by an incorrect coreserver name in the

registry or a failure of the core to establish SSL Tunnels to the Management Gateway‖.

In this screenshot I turned the core back on to demonstrate the test results of a client on the domain. As you can see

the core server was resolved and a connection made but no connection to the Management Gateway itself was

performed. A POST to IIS is made followed by a 200 response meaning OK.

In this screenshot the test results of a client connecting from the internet are displayed. (Note: An incorrect DNS

entry of 111.111.111.111 was placed in the HOST file on the client to prevent name resolution to the core) As

discussed before the test was unable to connect directly to the core server and began a connection to the

Management Gateway. In this case a ―201 description created‖ was noted indicating that the core server was found

on the Gateway. A long session begins and the message ―Link to core successful‖ is displayed which indicates that a

tunnel was established to the core server. The POST to IIS on the core is made and a 200 OK response is received

by the client.

As you can imagine there are many more possible error results. Some of those errors may be corrected by restarting

IIS and the Management Gateway Service on the core server. Many of these errors can be researched on the internet

as they are common to IIS and other web servers. However a quick summation of errors is noted below:

500 – Internal Server Error = The error message basically indicates that IIS on the core is not configured correctly.

One possible cause is that .NET 1.1 may be registered on the Default Website.

503 – Internal Server Error = This is again a configuration problem in IIS.

402 – Description Payment Required = Reactivate the Management Gateway

400 – Description Bad Request = Modify the default website properties in IIS on the core to not use an IP address.

Make sure the IP address option is set to ―All Unassigned‖.

403 – Forbidden = A username and password is required for the test. This needs to be in domain\username format

and all other previously discussed requirements met.

Important Note: If you are on the domain when running brokerconfig.exe and a message is displayed that you need

to enter credentials then typically the user running brokerconfig.exe won’t have permission to write to the

C:\Program Files\LANDesk\Shared Files\cbaroot\broker folder. During a request brokerconfig.exe will need to write

2 certificate files to this folder. If those files do not appear then local permissions need to be resolved. In summation:

brokerconfig.exe will never ask for credentials and will try the test as instructed.

Reports

Firewall Report – This report was added to the 4.2 version of the Management Gateway. An example of the report is

shown below along with some definitions:

―#‖ = The number of times this entry has been blocked.

―source‖ = The IP address of the packet that was blocked

―destination‖ = The intended recipient…usually the IP address of the Gateway itself.

System Logs

The system logs are very useful and determine several key events on the Management Gateway. Due to the amount

of information being logged a filter should be used. Below is a list of some of the items that you may see in the filter

drop down menu along with some example screen shots. The 4.2 Management Gateway System Logs changed from

the screen shots shown below but messages should be similar.

Note: This will not be a comprehensive list as many programs and other threads may create log entries. Entries such

as: (@ or 0x23428ab) are common but generally mean nothing. Also, some of these examples may not be listed as

they will only log when they are used. Other applications that may appear in the list may be difficult to define as

they have specialized purposes.

- Activate – General information on activation of the Gateway. Below you can see an error in

communication with the licensing server at LANDesk.

- Bootlog – Logs boot information and errors. The warning message logged below is typical when ETH1 is

not configured.

- Broker – On startup the core certificates that the broker daemon loads are recorded here.

- Cron – The local scheduler of Linux. The logs will report when configured hourly, daily, and monthly tasks

are executed. Example below shows an hourly log.

- Dbtool – Database Tool. Events are recorded when database work is performed. The example below shows

repairing and optimizing events as well as a user initiated backup.

- Gateway – Primary connection information: IP address, user account, POST or GET for the web server,

etc. This is perhaps the busiest logger on the Management Gateway and can be difficult to examine through

the GUI.

- Gsb – Logs actions/events that happen in the Web Console (gsb) page on the Management Gateway. The

example below shows the ―test‖ email button that was pressed and a failure message logged when

communication couldn’t be established to the mail server. The example also shows the firewall being

started and the admin user password being changed.

- Init – Linux init and System Initialization. This is a simple log that reflects run level changes within the

Linux OS.

- Kernel – General kernel logging. However, firewall logging also takes place here and will compromise

most of the logging on the Gateway. These logs are denoted as firewall (FW) and anything that touches the

Gateway even if a connection isn’t allowed or established is recorded here.

- Logger – Records the starting and stopping of the firewall. The firewall is designed to start automatically

upon boot up of the Gateway and should remain on as much as possible.

- Passwd – Password change logging from the passwd executable.

- Php-cgi – Web account activities. Example below includes the service account adding certificates, the

admin account changing the number of maximum connections, and account creation and more password

changes.

- Sshd – Logs activity from the ssh daemon. If SSH is never enabled then this log will be blank. If this

account is left enabled then it can be a target for a brute force attack. The screen shot below shows an

example of such an attack and what to look for.

- Sudo – Super User Do (SUDO) logging. This is a standard Linux command.

- Udev – Standard Linux daemon for the /dev directory.

- Useradd – Standard Linux command for adding users.

In summation almost all daemons, executables, and events get logged to some degree. Some of the items on this list

will be on just about every Management Gateway while others will only show up if that daemon or application was

executed.

File System Report

This is a basic report on system files that is produced by the System Update Monitor (SUMO) installed on the

appliance. The report will document hash, size, and other changes. It will also report on new files that were added

and summarize the information at the bottom of the page. This is also the report that you receive when an email is

configured in the Gateway Console. On a typical Gateway this report shouldn’t change much after the initial

configuration. Patches are generally the primary source for changes.

The Connection Table

This table is one of the best tools for troubleshooting connections to the Management Gateway particularly during

install and configuration. Three primary types of connections are shown and explained below. The table refreshes

automatically.

UserAgent:

Broker Service – These are service connections coming from core servers posted to the Gateway. At least 6 of these

are established from each core server at any given time but more connections are opened up as needed. If these

connections are not showing up then the Management Gateway Service on the core needs to be restarted or fixed.

The Management Gateway Service on the core will shut down automatically if these service connections cannot be

established. Typical causes for problems are an incorrect or bad ―service‖ account password or port 443 being

blocked in either direction between the Gateway and the core server. Proxies, DNS, and other related networking

issues can also cause problems.

Mozilla/4.0 etc. – This is a browser connection to the GSB management page on the Gateway. The particular page is

noted under the URL section of the table and the connection used to view this table will also show up.

LANDesk Remote Control Agent/8.6 – This connection is from a managed device. The remote control service on the

managed device is posting itself so that it’s available for remote control.

Gateway Service Status:

This is another summary and statistics page that contains some good information. Some of the information located

on this page includes:

- Current connections and type

- The last failed authentication

- The number of accounts locked out

System Test

This report is a basic test of services, firewall, processes, etc. The test includes a list of the tested items as well as if

they ―passed‖ or ―failed‖. A summary of the results are included at the bottom of the displayed page. On the 4.2

version of the Management Gateway the ―fluxbox‖ and ―firefox-bin‖ processes will fail. This is normal as usually

they fail when running the report from an Internet Explorer window.

Software Packages

This report that is available on the 4.2 version of the Management Gateway is a simple list of software packages that

are included on the gateway. The version and architecture are included as well. As patches are applied and

components updated this page should update as well.

Gateway Service Configuration

The screenshots below were taken from a 4.2 Management Gateway so some of these shots/options may not reflect

the 4.0 appliance. Also, some settings are not explained in detail below as they are self-explanatory.

The Management Gateway by default will log all connections and includes connections that are rejected by the

firewall. Actions are logged as well. The setting above will increase the detail of such logs however it should only

be used when necessary. Increasing the verbosity will greatly increase the size of the logs and the performance

demand on the Management Gateway.

This setting is for clients that do not support 128-bit encryption. Enabling the setting will tell the gateway to respond

to such requests instead of rejecting them. If security is a concern then this setting should be left disabled.

This setting was added to the Management Gateway in version 4.2. It was designed for future use in regards to

increasing security. As older technologies (MD5 for example) experience vulnerabilities and are no longer secure

this setting will allow the encryption level to be changed on the fly. However, Windows 2003 will not accept SHA-

256 connections so the Core and Clients need to be evaluated before this setting is changed.

This setting only needs to be changed if it appears that the client is having problems reaching the Management

Gateway. Typically the default setting will suffice for most installations but increasing this may be necessary

especially if the Management Gateway is supporting multiple core servers.

The Additional Hostnames field is typically one of the most important in regards to initial setup and configuration of

the Management Gateway. As stated in the explanation the rule of thumb is ―anything that the gateway itself can be

resolved to should be entered in this box‖.

Patching

Ports 443 and 80 in both directions are required in order for patching to function correctly. Proper DNS resolution

for the LANDesk patch servers listed below is required. Ports, Firewalls, and name resolution are the most common

cause of problems when attempting to download patches.

Patch.landesk.com

Patchec.landesk.com

Patchemea.landesk.com

Some installations of the Management Gateway will not have the luxury of having port 80 open. For this reason the

following document has been created and will be continually updated as patches are released. This document will

advise on downloading and installing patches manually on the Gateway Appliance. The document will also provide

an updated list of patches that are available to the appliance. As stated in the article manually installing patches to

the Management Gateway is not supported.

http://community.landesk.com/support/docs/DOC-9225

Currently the GUI interface for the Management Gateway doesn’t contain a quick and easy way of checking what

patches have been installed. If you are unsure of what patches have been installed on the Management Gateway then

the following log will document each patch installation.

/var/log/rpmupdate.log

Activation

Ports 80 and 443 are also required for Activation. The article listed below can assist with troubleshooting

Management Gateway activation problems. If problems persist then re-image the Management Gateway again and

attempt to activate before using any backup/restore points. Be sure to configure the network settings and firewall

prior attempting activation. Disabling the firewall on the Management Gateway is also a good test for activation.

http://community.landesk.com/support/docs/DOC-2129

Remote Control and Scopes

When scopes are used in LANDesk they are applied to the 32-bit console during login and therefore filter out

systems that not in the users scope. This prevents the user from performing tasks or taking remote control of

machines not in their scope. However, at the time of this writing user accounts on the Management Gateway are

different from accounts used on the LANDesk Core. Therefore scopes on the core are technically not applied

through the Gateway. The technical reason for this is due to Integrated Security for remote control. Integrated

Security forces the remote control viewer application to contact the core and request permission. As part of the

permission process a signed rights document is sent to the client system giving access. However, when the

Management Gateway is involved the signed rights document cannot be sent through the gateway and out to the

client. The core can only respond in request coming from the client.

If scopes are required in order to use the gateway another option is available. The ―Organization Setting‖ for each

user on the gateway has the ability to filter out what a person sees for remote control. The default setting of ―*‖ will

allow all devices posted to the gateway to be visible. The LANDesk Community document below will outline the

details on configuring the Organization setting. Certain steps will be required on each client and user in order for it

to function properly.

http://community.landesk.com/support/docs/DOC-8724

In addition to Integrated Security other security settings (such as Local Template and NT Security) will also work

through the Gateway. Local Template is basically open security. This is the same thing the On-demand remote

control agent uses. However, NT Security is local to the machine itself so a user must be in the local Remote Control

Operators Group in order for this security type to function. One misconception when using NT Security is the

inclusion of domain accounts. Domain accounts will work fine with NT Security as long as the device is on the

network but if the device is connecting through the Management Gateway then the client will be unable to verify the

domain credentials with a Domain Controler and fail in authentication.

The Management Gateway Root Certificate

By default the Management Gateway uses a self-signed certificate. In some browsers this self-signed certificate can

result in a security warning as shown below:

This warning is bothersome but in general harmless. If clients are concerned about the message then perhaps

creating a self-contained on-demand remote control executable as mentioned previously and hosting it on a different

website may be recommended.

Conclusion

Effective management of the gateway can help with maintaining security and efficient usage. The training video

links below will provide much greater detail on how the gateway works and how to use the gateway to recover

stolen hardware.

Training video on how to install and configure the management gateway as well as information on how it works and

how to request a broker certificate: http://community.landesk.com/support/docs/DOC-5104

How to use the gateway to recover stolen hardware: http://community.landesk.com/support/docs/DOC-6045

About LANDesk Software

The foundation for LANDesk’s leading IT management solutions was laid more than 20 years ago. And LANDesk

has been growing and innovating the systems, security, service and process management spaces ever since. Our

singular focus and our commitment to understanding customers’ real business needs—and to delivering easy-to-use

solutions for those needs—are just a few of the reasons we continue to grow and expand.

LANDesk pioneered the desktop management category back in 1993. That same year, IDC named LANDesk the

category leader. And LANDesk has continued to lead the systems configuration space: pioneering virtual IT

technology in 1999, revolutionizing large-packet distribution with LANDesk® Targeted Multicast™ technology and

LANDesk® Peer Download™ technology in 2001, and delivering secure systems management over the Internet and

hardware-independent network access control capabilities with LANDesk® Management Gateway and LANDesk®

Trusted Access™ Technology in 2005.

In 2006, LANDesk added process management technologies to its product line and began integrating the systems,

security and process management markets. LANDesk also extended into the consolidated service desk market with

LANDesk® Service Desk, and was acquired by Avocent to operate as an independent division.

Today, LANDesk continues to lead the convergence of the systems, security, and process and service management

markets. And our executives, engineers and other professionals work tirelessly to deliver leading solutions to

markets around the globe.