Best Practices for a Secure K1000 Deployment Best... · Single Sign-On with Windows Credentials ......

1 Copyright © 2013 Dell | KACE. All rights reserved.

Best Practices for a Secure K1000 Deployment

A Dell Technical White Paper


THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.

© 2013 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

Dell, the DELL logo, and the DELL badge are trademarks of Dell Inc. Microsoft, Windows, Windows Server, and Active Directory are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than its own.

November 2013


Contents ......................................................................................... Error! Bookmark not defined.

Abstract ................................................................................................................... 5

Introduction .............................................................................................................. 6

Recommended Network Deployment ................................................................................ 9

Inside the Intranet ................................................................................................... 9

Within the DMZ ....................................................................................................... 9

Web ...................................................................................................................... 11

User Interfaces ....................................................................................................... 13

Agent ..................................................................................................................... 14

Agent Execution ..................................................................................................... 15

Securing Replication Shares ....................................................................................... 15

Web Feeds ............................................................................................................... 20

Datastore ................................................................................................................ 22

History ................................................................................................................ 25

User Access Control .................................................................................................... 27

Authentication ....................................................................................................... 27

Configuring the LDAP Protocol to Use SSL .................................................................... 28

Configuring LDAP Authentication in a Multiple Organization Configuration ............................. 29

Single Sign-On with Windows Credentials ..................................................................... 30

Appliance Linking ................................................................................................. 31

Session Timeout ................................................................................................... 31

User Roles ............................................................................................................ 32

Import LDAP User Attributes .................................................................................... 33

User Labels ........................................................................................................ 36

File Management ....................................................................................................... 37

Managing Secure Backups of the K1000 .......................................................................... 37

Securely Managing Agent Provisioning ........................................................................... 39

Using a Local Share in Agent Provisioning .................................................................... 42

Email ..................................................................................................................... 45

Securing Inbound Email ............................................................................................. 45


Configuring the SPOP3 Protocol ................................................................................ 48

Configuring the SMTP Protocol ................................................................................. 48

Securing Outbound Email .......................................................................................... 50

Administrative Email Alerts ..................................................................................... 51

Appliance Services ..................................................................................................... 55

Health Monitoring ................................................................................................... 55

Enabling SNMP Monitoring of the K1000 ....................................................................... 55

SSH Access ......................................................................................................... 56

Updating the K1000 .............................................................................................. 56

Logging ................................................................................................................ 58

Console ................................................................................................................ 59

Network Diagnostics .............................................................................................. 60

Tether ................................................................................................................. 61

Other Resources ........................................................................................................ 63

Dell KACE Corporate Background ................................................................................. 63

Dell KACE Headquarters ......................................................................................... 63


Abstract The Dell KACE K1000 System Management Appliance is designed as an easy-to-use, comprehensive, and affordable solution to systems management. The offering tightly integrates all of the services needed to discover, inventory, assess, and manage the systems in your computing environment. Since this offering affords your IT administrators with a high degree of control over your computing resources, a great deal of care has gone into designing the appliance to ensure your computing environment remains secure.

The K1000 utilizes a web interface for administrators and users to interact with the solution, and for endpoint agents to communicate with the appliance. All web communications are encrypted with up to 2048 bit encryption. Users are authenticated to the K1000 using your existing directory services, and may be authorized to perform only certain functions based on their assigned role. Extensive auditing features are provided to ensure all administrative actions may be independently tracked.

Several deployment options exist to accommodate the needs of your computing environment and user community, each with security implications to consider. This whitepaper provides recommendations for those deployment choices as well as alternatives that may better suit your needs. Of course, implementation choices for your environment may exist that were not discussed in this white paper. A review of your implementation plan with Dell KACE is always welcomed.

Finally, please be aware that the underlying operating system and associated services of the appliance have been hardened to eliminate potential security vulnerabilities and minimize risk. Dell KACE Quality Assurance processes continuously evaluate potential vulnerabilities in the software used to deliver the K1000 and provide resolutions to identified vulnerabilities as part of periodic updates to the appliance. As with all software offerings, diligence is required. We at Dell KACE take pride in providing a solution that achieves unparalleled productivity gains for your IT staff while ensuring your assets are safeguarded.


Introduction The K1000 Systems Management Appliance provides an extensive array of options for managing client and server machines within a network. This white paper explores how to best implement these choices with security in mind. The KACE approach to systems management delivers a self-contained web application appliance to provide all of the features required to manage endpoints in a network environment. This approach offers many advantages in simplifying the overall task of maintaining inventory of machines and software, and keeping those machines and their respective software up-to-date and under control. All of the provided features are configurable via an easy-to-use web-based administrative interface. Because of this, system administrators do not need to access the underlying operating system of the K1000 appliance to perform any administrative tasks. Restricting physical access to the appliance in combination with maintaining a secure password on the console ensures a very high level of security with respect to the underlying operating system. As such, this document focuses primarily on the configuration options available within the web administrative interfaces and the network and physical controls that should be put in place to guarantee a secure deployment. The following diagram describes the network protocols that may be used within the K1000. By default, all network protocols and their associated services are disabled except for AMP and HTTP, which are the protocols used to support the user interfaces and agent communications. You must explicitly configure the K1000 to enable any additional services. The arrows indicate whether the communication is inbound or outbound from the K1000 (and correspondingly, will need to be configured as such on any firewalls in the network environment). The dotted arrows indicate the protocols associated with optional services that need to be enabled to be used. The greyed boxes are functionality provided by the Dell KACE K1000 Appliance. Where only an external protocol is illustrated, it is up to the local implementation to provide the client or service that will integrate with the given protocol when desired.


Overview of K1000 Services, Ports, and Protocols

This document will explore each of these services and their respective configurations, and the best practices associated with their deployment. Web – Most communications with the K1000 are conducted utilizing this service, including the agent, the various user interfaces, and communication with external services upon which the K1000 relies. Agent – An agent is installed on computers that will be managed by the K1000. The agent communicates with the K1000 appliance via HTTPS and maintains a heartbeat with the appliance via the KACE proprietary AMP protocol. Web Feeds – The K1000 obtains regular updates for patch signatures and payloads to be deployed to managed systems, Dell driver and firmware payloads, Dell warranty information, news and knowledge base articles from Dell KACE Technical Support. Datastore – The K1000 records current and historical activity within an internal database, which may be remotely accessed in read-only mode if desired. User Access Control – There are multiple options and configuration settings to be discussed regarding authentication and authorization of users for the K1000, including integration with your local LDAP services.


File Management – Most operations for file transfer with the K1000 are conducted over HTTP/S. However, there are some limitations to utilizing HTTP/S for all file transfers, and this topic explores those alternatives. Email – The K1000 provides an SMTP service for configuring service desk ticket queues and managing inbound service tickets, as well as managing outbound notifications to appropriate personnel when an alert triggers them. Email may be transmitted inbound or outbound via the SMTP protocol. POP3/SPOP3 is supported as an option in addition to SMTP to retrieve email from corporate email services. While the email dataflow is inbound to the K1000 appliance when using POP3/SPOP3, the appropriate port must be opened outbound through any firewall because the email is ‘pulled’ from the external POP mail server (*). Appliance Services – KACE appliances are web application appliances. Customers are provided limited console access for initial configuration and troubleshooting. Once configured, all appliance functionality is accessed and managed through the Web User Interface, and OS access is not needed for normal appliance operations. Full access to the appliance operating system is reserved for KACE Technical Support and only with the approval and cooperation with customer personnel. You will see the following notation in the document that will aid in understanding your configuration options:

This symbol indicates a configuration best practice for optimally deploying a particular service

This symbol indicates a “note” or reminder of the implications of a certain configuration to be considered as part of the service deployment

This symbol indicates a warning or implication of a service deployment that may help to decide whether the service should be deployed in your configuration.


Recommended Network Deployment The K1000 may be implemented within your network environment in a number of ways. The following two deployment scenarios represent best practice configurations to accommodate specific needs.

Inside the Intranet When the machines being managed by the K1000 are maintained within a secured network environment, services should be restricted to this environment only. However, the K1000 will need to obtain patches, Dell driver and firmware updates, Dell warranty information, and KACE updates via web services. When the K1000 is deployed within the intranet all available service capabilities may be safely utilized, including remote database access and network monitoring. However, in this type of deployment, the window for collecting inventory and deploying software to mobile endpoints for users that are frequently not on the corporate network will be limited to when they are present on the corporate network.

Within the DMZ In most deployments, it is desirable to have agents on the endpoints be able to communicate with the K1000 whether they are connecting on your intranet or connecting remotely so that these machines can check in to the K1000 inventory and request their updates from the K1000 in a timely fashion. This


may be accomplished by deploying the K1000 within your DMZ, thereby allowing access to the server from the internet for the deployed agents.

In this type of deployment, access to corporate resources inside the intranet must be restricted to only those services needed to effectively operate the K1000. We recommend that LDAPS be used to access your LDAP infrastructure from the DMZ, and that file backups be transferred to inside the intranet for safe keeping.

In both of the illustrated deployments, it’s possible to integrate with cloud-based email services (e.g. Exchange360, Google Apps) rather than corporate email if this is your approach to deployment email services to your environment.


Web Enable SSL on the K1000 to encrypt all inbound web communications for agents and the user interfaces.

The simplest method for enabling SSL is to complete the configuration before deploying agents to your endpoints, allowing your endpoints to utilize SSL from the beginning.

If you have already deployed agents, complete the SSL configuration on test endpoints with your K1000 on a test network before converting the agents that are already deployed.

Enable port 80 access during agent deployment so that agents can still deploy even if there are issues with the SSL configuration. Once agents have been successfully deployed, this setting may be disabled.

Use a certificate from a vendor in your PCs trusted certificate vendor list, or your organization’s Root CA certificate provided it has already been configured to work with all browsers in your network.

With the K1000 Systems Management Appliance, most of the data traffic is conducted via HTTP/S. The agents deployed to endpoints are web clients that request updates and post processing results to the K1000 using HTTP GET, PUT, and POST. Also, the three user interfaces for end users, administrators, and multi-organization system functions are all designed to work in most commercially available web browsers. All of this traffic is inbound from the endpoint or browser to the K1000. Therefore, the first step to securing a K1000 deployment is to configure SSL on inbound HTTP. Ideally, this configuration is completed prior to deploying agents in your environment. However, it can be completed retroactively as well provided care is taken to follow the steps outlined below.

The steps to enabling SSL on the K1000 are really no different than securing other web servers in your environment. However, there are some specific considerations for KACE to keep in mind.


1) Execute a backup of the K1000 and copy the two backup files to a separate data store. 2) Enable SSH and port 80 access on the security settings (SettingsControl PanelSecurity

Settings). These are precautions to allow the K1000 to be serviceable by Technical Support should issues arise. Save these settings before proceeding with your certificate configuration.

Making a change to the Security Settings will cause the K1000 to reboot in order to register the setting changes.

3) Ensure the K1000 Web Server Name specified in the SettingsControl PanelNetwork Settings is the same as the Common Name specified on your certificate, which is the Fully Qualified Domain Name (FQDN) of your certificate.

4) When you enable port 443, all connected agents will switch to using SSL. If the SSL configuration isn’t correct, this can prevent agents that have already been deployed from connecting to the K1000. Therefore, additional care should be taken to ensure your SSL configuration is correct when you already have deployed agents. You may consider attaching your K1000 to a test network that is separate from your primary network to confirm your SSL configuration with one or more test endpoint machines, before reconnecting your K1000 to your primary network where your production agents are deployed.

5) You may generate a self-signed certificate within the K1000 using the SSL Certificate Wizard or you may upload your own certificate files. Make sure that your Private Key File does not have a password on it, as this will prevent the K1000 from restarting automatically.

The K1000 supports key lengths up to 2048 bits, either as an uploaded certificate, or you may generate a self-signed certificate using the SSL Certificate Wizard within the K1000 itself. However, a certificate signed by a Certificate Authority is advised given that self-signed certificates on any web server can increase the risk of man-in-the-middle vulnerabilities.

6) Also, it is advised to use a certificate from a vendor in the trusted certificate vendor list used by the desktops and servers in your environment, or your organization’s Root CA certificate provided it has already been configured to work with all browsers in your network. Otherwise,


you will need to install your certificate onto your machines via group policy or by other means of distribution.

The Agents and User Interfaces share the same SSL configuration, so it is essential that you use a certificate that will work within your deployed browsers.

User Interfaces Restrict access to the Admin UI (and System UI if you are using a multi-org configuration) to the LAN

environment where administrators will be administering the K1000.

There are three types of user interfaces on the K1000:

1. User UI – Provides access to end users for viewing service desk ticket status and submitting tickets, and for providing self-service to the software library, knowledge base, and other information.

2. Admin UI – Provides access to administrators to configure the K1000 and the various tasks that may be assigned to the endpoints in inventory, as well as the administrative functions of the service desk. The Admin UI accesses one specific organization when multiple organizations have been defined.

3. System UI – Provides access to administrators to configure the K1000 across organizations when multiple organizations have been defined.

As noted above, the agent and these user interfaces share the same SSL configuration. However, you may have a need to restrict access to the user interfaces to specific segments of the corporate network. For example, access to the User UI may be allowed externally, or may be restricted to the corporate intranet and made available to the end user only via VPN. Access to the Admin UI and System UI may be further restricted to only certain subnets within the corporate network.

The K1000 Web Server Configuration settings (SettingsControl PanelLocal Web Server Configuration) provide a method for defining allow/deny directives to specific IP address ranges or DNS domains for the Admin UI, User UI, and System UI interfaces.


Agent Open ports 80, 443, and 52230 outbound on any local firewall in use on your desktop and server

computers that will have the agent deployed on them. This may also include firewalls in the route between the endpoint and the K1000 server.

Enable SSL on the AMP connection to complete the encryption of all agent messaging traffic.

Ensure that you restrict local administrator rights on the endpoints in your environment to only the system administrators that need this capability.

When an agent is deployed to an endpoint, the agent will always attempt to connect to the K1000 server specified in its configuration first via HTTPS over port 443, then via HTTP over port 80. Therefore, if SSL is enabled on the K1000 the agent will connect via HTTPS and proceed with encrypted communications. If SSL is not enabled, the agent will default to unencrypted traffic via HTTP.

Once the HTTP/S connection is established, the agent will open an AMP connection via port 52230 that will be kept alive by the server to maintain communications with the agent. The Read/Write Connection Timeout setting is defaulted to every 120 seconds, but may be adjusted between 30 and 180 seconds depending on local network requirements. This communication channel allows the server to maintain a connection status with the agent in the K1000 inventory, and to notify the agent that work is pending and that the agent should communicate with the server via HTTP/S to obtain the


appropriate instructions and/or payload. While no payload data is transmitted via the AMP connection, it is advised to complete the SSL configuration by also enabling SSL for AMP. This can be done on the SettingsControl PanelAgent Messaging Protocol Settings page.

Beginning with version 5.4 of the K1000 appliance, AMP SSL is automatically enabled when SSL is enabled.

Agent Execution Ensure that you restrict local administrator rights on the endpoints in your environment to only the

system administrators that need this capability.

On each endpoint, the agent runs within the LocalSystem account on Windows operating systems or as the root user on Linux and Mac OSX operating systems to conduct its work. The program files associated with the agent are installed into the appropriate “Program Files” directory on Windows, the “/opt” directory on Linux, and the “/Library/Application Support” directory on Mac OSX. These programs may be viewed and executed by any user; however they won’t perform any of their intended work without the downloaded instructions from the K1000. When these instructions are downloaded, they are written to an output directory as noted below.

Agent output is written to a separate data directory on the endpoint (e.g. c:/ProgramData/Dell/Kace on Windows 7 endpoints) and may have some content that is accessible by users other than LocalSystem or root depending on the work being conducted (e.g. a Kscript may be configured to execute as a specific user on the system to meet certain requirements). However, the directories containing the configuration files and agent execution instructions may only be written to by LocalSystem (or root). As the data is downloaded to these local directories, the agent will calculate an MD5 checksum for each file and compare it to the one retained on the server. This is used to verify files that have already been downloaded in a prior action have not changed and therefore should not be downloaded again, as well as to ensure no tampering as occurred on the files while in transit.

To adequately protect the local configuration, local administrator rights should be restricted to limited staff, typically with domain administration capabilities. End users should not have local administration rights to their assigned machine. Bear in mind that if you allow end users to maintain local administrator rights, they are effectively managing their own machine. Obviously, an environment where everyone has control over their own machine presents many challenges to maintaining a consistent systems management solution.

Securing Replication Shares Ensure write access to replication shares is minimized to only the system administrators that require

access.

Configure a Destination User and Password for write access the replication share that is not being used for other purposes and ensure that the password is of sufficient length and complexity to meet your specific password policies

Configure a Download User and Password for read access to replication share that is not being used for other purposes and ensure that the password is of sufficient length and complexity to satisfy your specific password policies


Make sure to designate different User and Password values for the Destination User and the Download User

Replication shares are machines that keep copies of files for distribution, and they are especially useful if you have K1000 clients deployed across multiple geographic locations. For example, using a replication share, a machine in New York could download files from another machine at the same office, rather than downloading those files from a K1000 in Los Angeles.

In addition, you can use replication shares to deploy Managed Installations, patches, scripts, and Dell Updates where network bandwidth and speed are issues. The replication share inventory is automatically maintained by the appliance and the replication share agent. When a replication item is deleted from the appliance server, it is marked for deletion in the replication share and deleted in the replication task cycle. Replication shares are good alternatives to downloading directly from an appliance.

Replication shares may be configured to minimize network consumption and optimize payload delivery when deploying content to multiple agents across a WAN into a LAN environment. The replication share is simply an existing network file share accessible within that LAN environment. Data is directed to it by configuring one of the agents in the local environment to act as the Replication Machine. The replication machine then acts like any other agent to retrieve instructions and payloads from the K1000 via HTTP/S. However, it takes on the additional task of writing that data to the designated network file share using the specified Destination Path, User, and Password. Data that is written to the network file share by the replication machine is verified using MD5 checksums.

Machines within the LAN environment are instructed to obtain their content from the replication share when they are included in the Label on the replication share configuration. When the agents on these machines are signaled via AMP to obtain their work assignments, they are redirected by the K1000, again via HTTP/S, to the local network share. They will then retrieve their designated instructions and


payloads by accessing the network file share using the Download Path, User, and Password. Again, the integrity of the downloaded data is verified by the agent on the endpoint using MD5 checksums. Since all of the agents will download from this locally defined file share, it is essential to protect the file share with sound password policies and access restrictions.

The local replication share may be a network file share that is configured on the replication machine itself, or it may be on a separate host. If the replication share is on the replication machine, a Destination User and Password do not have to be specified since the agent on the replication machine is running as LocalSystem.

The Replication Machine may be a machine within the local environment that points to the file server where the replicated files will be stored, or it may be the machine that is hosting the file shares. However, the Replication Machine and its associated file server must be on and available on the network continuously to allow the replication process to work. The following diagram illustrates these two approaches and the resulting interactions that support the Replication Share process:


In LAN A, a desktop computer with the KACE agent installed as been designated within the K1000 as a Replication Machine. The computers within that environment have been added to a machine label called Replication Label A, and that label has been configured within for this Replication Share. The file server being used to store the files locally resides within LAN A and could be a server computer or network file server, as long as its file shares are accessible via the SMB protocol. Payloads such as application installers, patches, scripts, and Dell driver updates are delivered from the K1000 to the Replication Share, and subsequently to the managed machines in the Replication Label, in the following manner:

1) The Replication Machine that is configured for the Replication Share A is notified via AMP to check in to the K1000 to conduct work.


2) The K1000 instructions indicate what files the Replication Machine should download. Any file that is needed to manage one or more machines in Replication Label A will be included in the list of files to download. The download of these files is throttled in accordance with the configured settings on the Replication Share within the K1000.

3) The Replication Machine will write the files to the Destination Path using the Destination Path User and Destination Path Password, verifying file content using an MD5 checksum. This checksum is also used to avoid downloading files that have already been downloaded to the share in a prior transmission.

4) Machines within the Replication Label A will be notified via AMP to check in to the K1000 to conduct work.

5) The K1000 will redirect payload delivery to Replication Share A for the machines in Replication Label A.

6) Machines will retrieve their designated payloads from Replication Share A using the Download Path, Download User, and Download Password configured on the Replication Share within the K1000. Again, MD5 checksums are utilized to verify file content and validity for downloading.

In LAN B, the configuration is slightly different in that a workstation in the environment is also being used both as the Replication Machine and as the host for the Replication Share. Machines in this environment are grouped within the K1000 using Replication Label B and have been assigned to get their payloads from Replication Share B:

1) The Replication Machine that is configured for the Replication Share B is notified via AMP to check in to the K1000 to conduct work.

2) The K1000 instructions indicate what files the Replication Machine should download in the same manner as the prior example.

3) The Replication Machine will write the files to the Destination Path, verifying file content using an MD5 checksum. This checksum is also used to avoid downloading files that have already been downloaded to the share in a prior transmission.

Because the Replication Share is hosted on the same machine as the Replication Machine, the Replication Machine does not require the Destination User and Destination Password in this configuration.

4) Machines within the Replication Label B will be notified via AMP to check in to the K1000 to conduct work.

5) Machines will retrieve their designated payloads from Replication Share B using the Download Path, Download User, and Download Password configured on the Replication Share within the K1000. Again, MD5 checksums are utilized to verify file content and validity for downloading.

Agents may access their associated payloads from the replication share by either using a UNC patch (e.g. \\server\kace) or via the HTTP protocol (e.g. http://server/kace). Beginning with version 5.5 of the K1000, downloading content from a replication share using the HTTP protocol will support throttling controls, allowing better management of network consumption within the LAN environment.


Web Feeds Utilize a proxy for outbound communications to limit outbound firewall rules, and configure the proxy

to accept HTTP Basic Auth authentication from the K1000.

All service updates for operating system and application patching, Dell driver and firmware updates, Dell warranty status, and KACE technical support updates and news feeds also are retrieved using the web. All of this traffic is outbound from the K1000 to the various service URLs in use by the K1000.

Below is a list of the services being accessed by the K1000 and their purpose:

URL Purpose https://api.dell.com Retrieves warranty status for each Dell computer in inventory http://api.support.dell.com Retrieves warranty status for each Dell computer in inventory http://www.kace.com Provides access to product documentation and help files within

the user interfaces http://www.itninja.com Provides integrated access to software installation and

configuration help within the Admin UI http://www.appdeploy.com Provides integrated access to software installation and

configuration help within the Admin UI http://support.kace.com Provides direct access to KACE support for creating service

tickets, as well as news and information from KACE support http://ftp.dell.com Retrieves Dell firmware, driver, and BIOS updates for Dell

computers in inventory https://service.kace.com Primary link for downloading patch content from KACE. It may

redirect to one of the following URLs to complete delivery of patch content.

http://kace.cdn.lumension.com Content delivery network for cross platform application and operating system patches

http://servicecdn.kace.com Content delivery network for kace appliance updates http://download.windowsupdate.com Source for windows patches http://go.microsoft.com Microsoft’s fwlink service to redirect to specific content.

If an outbound proxy is not used, then these URLs must be whitelisted on your firewall for both port 80 and 443.

If an outbound proxy is used, it is configured within the K1000 Network Settings (SettingsControl PanelNetwork Settings or by logging onto the appliance console using username=konfig and password=konfig). HTTP or SOCKS proxies are supported, with the default proxy port set to 8080. The proxy port may be reassigned. The K1000 only supports “basic auth” for authentication to the proxy. Otherwise, no authentication may be specified.


Data that has been downloaded via these web services is not automatically delivered to endpoints by the K1000. To deploy artifacts to their intended targets, a scheduled task must be configured by the administrator with an appropriate machine label specifying which machines should receive the intended patch or driver update.


Datastore If remote access to the K1000 database is required in your implementation, configure the connection to

utilize SSL whenever possible.

Set the read-only passwords for each organization database you have configured in accordance with your password policies.

If you are deploying the K1000 in your DMZ to manage a mobile workforce and also wish to enable remote database access, consider using a secondary K1000 within your corporate network as a reporting database and restoring nightly backups to this appliance to reflect current and historical data from the time of the backup.

The K1000 stores all of its configuration and transactional data within a MySQL database in the appliance. A list of the database tables and their associated functional component may be found in the K1000 Administrator Guide. The K1000 also provides a reporting subsystem to define and schedule reports against all collected data stored in this database. Generally, most customers find this reporting capability to be sufficient to manage their operational reporting requirements. By default, this database is not accessible outside of the K1000 appliance.

However, some customers have a need to integrate the data collected by the K1000 with other data sources for integration purposes (e.g. Dell Boomi) or to use a third party reporting tool because it offers increased functionality (e.g. Microsoft Excel or Crystal Reports). To accommodate this need, the K1000 database may be accessed remotely for read-only purposes.

If you have a firewall between your external reporting tool and the K1000, you will need to open port 3306 inbound to allow remote access to the K1000 database.

Any machine that will be used to connect to the K1000 MySQL database remotely will need to have a MySQL ODBC driver (e.g. MyODBC for Windows) or client tool with a driver installed.

You should never open remote database access to your K1000 when it is deployed within the DMZ.

This connection may be secured via SSL, either with the default certificate provided within the K1000 or by overriding the default by supplying your own MySQL certificate. The configuration may be found within the SettingsControl PanelSecurity Settings page:


On a multiple organization configuration, each organization is its own database and therefore has a separate read-only password for each database configuration. The Report User Password may be changed within the organization configuration in the System UI. The read-only user will be assigned by the system as R1, R2, R3, etc, and will list the assigned database user ID value on the organization configuration page where the password is set.


In a single organization configuration, the database name is always ORG1 and the user is always R1. For this type of configuration, the Report User Password may be set in the SettingsControl PanelGeneral Settings page.

If remote database access will be enabled for your implementation, be sure to set the read-only database password values for all of your organizations in accordance with your password policies.

To further enhance the security of your remote data reporting capabilities, you may consider using a secondary K1000 configured within a separate subnet in your corporate environment. You can keep the data up-to-date on this secondary appliance by restoring your production nightly backup from your primary K1000 to the secondary reporting K1000 on a daily basis. This also has the added advantage of any performance degradation for complex reporting from your production appliance, and allowing your reporting appliance to be dedicated to this activity.


History Set tracking and retention policies for K1000 Settings, Assets, and Objects based on what you are using

and your local risk assessments

Match your retention policies to your audit processes so that you don’t burden the K1000 database with old records you’ve already reviewed.

The K1000 provides an extensive auditing and tracking capability with the History configuration. This capability allows you to track who changed any object within the K1000 and when, the type of change that was performed (e.g. Creation, Modification, Deletion, Addition, Removal, Schedule Removal, Policy, File Upload, Query, Event), and the field that was changed. You may review the before and after value of a field change when data has been modified.

Because of the extensive amount of data that may be retained for historical purposes, it’s important to identify the objects of greatest concern to be tracked. It’s also important to define a retention policy for how long you wish to keep audit records in place. This should be defined in accordance with your planned audit policies. History retention may be defined separately for your K1000 Settings, Assets, and operational Objects (e.g. Labels, Scripts, Software, etc.). For Objects, you should consider tracking changes for objects that you are using within the K1000. You should also consider tracking changes for objects that perform updates to the K1000 database (e.g. Smart Labels) or to endpoint systems (e.g. Scripts) even if you aren’t using these features.


User Access Control In many installations for a K1000, there may only be one or two administrators that are accessing the appliance on a regular basis. This illustrates the power of a K1000 Systems Management Appliance in that an IT administrator can accomplish so much of their day-to-day tasks with this simple to use approach to systems management. But even in these small implementations it’s wise to properly configure user access control so that you know specifically who is accessing the system and can identify the changes that are being made and by whom over a given timeframe. In larger deployments, it’s essential to define roles and segregate responsibilities accordingly, even limiting what certain roles may be able to do in the system to prevent undesired changes. And like in any system, maintaining good password change policies and ensuring that a time limit is set to log the user out when their session is no longer in use is important to preventing unauthorized access.

Authentication Utilize LDAP authentication whenever possible to leverage corporate password change policies.

Set a strong password for the default admin account and only use it for recovery purposes.

Define an access role with minimum privileges to be assigned to authenticated users within the LDAP configuration page. Manually assign elevated privileges to users that require them.

The K1000 provides a capability to define local users and set passwords for users within the K1000 database. However, this capability is limited in that it does not enforce strong passwords and does not maintain password change policies. If you have an Active Directory or other LDAPv3 directory service deployed within your environment, it is strongly advised to configure the K1000 user authentication to take advantage of this.

When external LDAP authentication is configured, the validation of credentials is performed by the LDAP server rather than the K1000. The K1000 binds to the LDAP server using an LDAP login and password that has read-only access to the Search Base DN specified on the LDAP configuration. The password configured for this user should be changed periodically and should follow your password policies. However, be aware that when this read-only password expires, users will not be able to authenticate to the K1000 until the new password value has been assigned in your directory and in your K1000 Authentication Settings.

When this LDAP read-only password expires, users will not be able to log in and the “admin” user credentials will need to be used to reset the LDAP connection.

It then passes the Login ID value supplied on the authentication page in a variable called KBOX_USER to

be used in the Search Filter to the Search Base DN. Notice that by using the option, multiple LDAP configurations may be specified to accommodate environments where multiple domains, multiple forests, or even multiple directory technologies (e.g. Active Directory, eDirectory, OpenLDAP, etc.) are being used. These configurations are processed in order, so that if a user is authenticated by one of the configurations, the subsequent configurations will not be processed.

When a user is authenticated, they will be created as a user in the K1000 USER table (Service DeskUsers). Only during this initial authentication, the default Role from the configuration will be


applied. From this point forward, any change to the user’s role would be applied within that user’s record in the K1000 USER table (Settings Users). This is one technique for assigning user roles, and the only technique that may be applied during authentication. For this configuration, it is strongly recommended that the default role assigned to authenticated users be a role with minimum user privileges for your environment. The User record may then be manually edited for users that require elevated privileges. Other role assignment alternatives are described in the next section.

Configuring the LDAP Protocol to Use SSL In order to utilize the secure LDAP communication protocol, preface the LDAP Server Hostname (or IP) in the LDAP configuration with “ldaps://” (e.g. ldaps://192.168.2.20 in the example above). This will also require that Secure LDAP port (default is 636) is allowed on any firewall between the K1000 and the LDAP Server Hostname (or IP).


If you have a nonstandard SSL certificate installed on your LDAP server such as an internally-signed or a chained certificate not from a major certificate provider (e.g. Verisign), you will need to contact KACE Support for assistance prior to proceeding.

Configuring LDAP Authentication in a Multiple Organization Configuration LDAP authentication is specified separately in each organization in a multiple organization configuration. Therefore, each org may have its own sequence of Search Base DN configurations and default role assignments. Because orgs are effectively in separate databases, nothing about the LDAP configuration in one org is used by another org.

Because LDAP configurations are part of the org structure, LDAP authentication is not used to authenticate a user to the System UI. When you are using LDAP authentication in all of the orgs, you must set the User Name, Full Name, and Password value for the handful of users that require System UI access to be the same as their domain credentials.

The user credentials for users in the System UI are defined within K1000 SettingsControl PanelUsers tab within the System UI.

The default admin account within the K1000 should be used only in situations where you cannot access the K1000 using user credentials due to configuration issues, such as a service interruption with LDAP authentication. The password for the admin account password should be set to a strong value and kept in a secure location by the K1000 system administrators. Next, each system administrator should be provided an account within each org they will administer. These accounts should use their LDAP


credentials to authenticate them and have the admin role assigned to their account. Finally, for administrators with full system rights across all orgs, they will also need to set up and maintain their credentials within the System UI as described above. Managing full administrative rights in this fashion will allow for proper change management controls and tracking.

Single Sign-On with Windows Credentials To utilize Active Directory Single Sign-On for users that will access the K1000, ensure that you join the

K1000 to your domain using an account that the rights to create a machine DN and a user DN.

If possible, utilize the same authoritative time source for your K1000 appliance that you utilize for your Active Directory configuration. Ideally, you should have one authoritative time source for your entire organization. Proper time synchronization is essential for single sign-on to work effectively.

Beginning with version 5.5 of the K1000, you may join the K1000 to your domain and configure single sign-on for your users. This allows your users to access the functions they have been assigned within the K1000 without having to re-authenticate to the K1000.

The SSO functionality within the K1000 will also recognize a user as authenticated when you utilize two-factor authentication to authenticate users to your Windows environment (e.g. smartcard, FOB, etc), and not require reauthentication to access the K1000 web user interfaces.


With version 5.5, only one domain may be configured for single sign-on. This limitation is true even if you have configured multiple organizations to support the different domains.

Please refer to the K1000 5.5 Administrator’s Guide for additional information regarding how to configure single sign-on for your appliance.

Appliance Linking Configure appliance linking when you have more than one KACE appliance in your environment and

wish to implement shared authentication between the appliances.

If you do not have more than one KACE appliance within your environment this topic does not apply. If you do have more than one appliance (e.g. more than one K1000 or a K1000 and a K2000), you may wish to establish single sign-on between the appliances for the convenience of your administrators.

When appliance linking is enabled, all communication between the configured KACE hosts is encrypted using public-private key encryption based on the RSA algorithm. Therefore, SSO credentials are secure even if you have not enabled TLS/SSL on one or more of the configured hosts. All of the hosts that have been configured via appliance linking will appear in the Organization drop down list in the far upper right corner of the Admin UI. In the same manner that you switch between different organizations on a single appliance, you may also switch between appliances. Detailed instructions for configuring appliance linking may be found in the K1000 Administrator Guide.

In order for single sign-on between appliances to function, you must have the same credentials configured for each user on each appliance, typically by configuring LDAP integration identically on each appliance. When appliances are linked, the authenticating appliance (where the initial login screen is processed) will pass the user ID and password values using the encrypted link to the linked appliances. Each linked appliance will then process the user authentication using its own authentication settings.

Session Timeout Set the session timeout limit to a reasonable value so a session left open doesn’t invite unwanted

guests.

One final aspect of managing authentication is to ensure that the user interface times out after a reasonable amount of time to avoid access to the K1000 by an individual that hasn’t actually authenticated with their own credentials. The session timeout value may be set on the SettingsControl PanelGeneral Settings page:


User Roles Utilize the pre-defined Admin role to authorize only those users that will function as K1000 system

administrators

Utilize the pre-defined “User” role to authorize users that will be accessing the User UI for self-service

Define specialized roles for users that only have responsibility to view or update certain aspects of the K1000

Define a specialized role for IT administrator for any administrators that will use many features of the K1000 but will not act as K1000 system administrators.

Import user attributes from LDAP to more effectively manage role assignments, create user labels, and assign asset ownership.

A user role defines the capabilities that a user may have within the K1000 Admin UI. Roles within KACE provide access to specific functions within KACE as defined by the tabs found in the user interfaces. That is, you may specify whether someone can read from, write to, or even see the InventoryComputers tab. However, you cannot restrict which computers they will see in the listing. Despite this limitation, roles are a very important aspect of implementing a secure K1000.

Administrators that have access to a specific tab in the Admin UI may see all entries in that tab (e.g. All Computers in Inventory). Additionally, if an administrator has write access to a specific tab, they may modify any entry in that tab. Only within the User UI may data be restricted by user by applying a User Label.

Roles are defined within the Service DeskRoles page of the K1000 Admin UI. As examples, if you are using the K1000 service desk functionality, consider having a role for a Help Desk Administrator that may not have the rights to operate on other aspects of the K1000. Similarly, if you are using the Asset module to track your own assets, you wish to have an Asset Manager role that is allowed to create, delete, and update assets while other roles may only be able to read the asset configuration. The following table provides examples of specialized roles you may consider when configuring authorizations in your K1000:

Role Purpose Read Write Hidden IT Admin Supports systems

management but cannot configure the K1000

Home->Label Asset

Inventory Distribution Scripting Home->Search Scripting Security Reporting

Service Desk Settings

Help Desk Admin

Supports configuration of the K1000 service desk

Asset Inventory Home

Service Desk Reporting

Distribution Scripting Security Settings

Asset Manager Supports configuration of asset types and their asset data

Inventory Home

Asset Reporting

Distribution Scripting Security


Service Desk Settings

Reviewer Reviews system updates and activity but does not update (e.g. auditor)

Reporting Settings->History Settings->Logs Assets Inventory

Distribution Scripting Security Service Desk

Beginning with version 5.5 of the K1000, Roles will be defined within the SettingsRoles and Users will be defined within the SettingsUsers page.

There are two functions within the K1000 that allow an administrator to perform SQL updates within the database. The first is within Service Desk Configuration within the Customize Ticket Rules page on a queue. This feature allows the administrator to define specialized ticket processing as the result of events that occur within the service desk. One of the configuration options allows the processing of an update query to record the results of this specialized ticket processing within the ticket itself.

The second is within HomeLabelsSmart Labels. Smart labels allow the dynamic grouping of objects by processing an administrator defined SQL statement when specific events occur within the system (e.g. machines check in to inventory, users log onto the system). Typically, smart labels are managed using the label wizards provided throughout the UI. However, the HomeLabelsSmart Labels page provides access to manipulate the SQL in the event that the wizard does not provide sufficient control to defined the desired grouping.

Assignment of HomeLabelsSmart Labels and Service Desk Configuration capabilities should be kept to a minimum number of your K1000 staff, such as your K1000 administrators.

Import LDAP User Attributes In the section on authentication above, we discussed how default roles may be assigned to a user from within a specific Search Base DN in the LDAP configuration when the user authenticates to the Admin UI in KACE. This assignment is made only once, when the user authenticates for the first time and a new user record is created for that user within the K1000. Another alternative for assigning default roles is to configure the assignment as part of LDAP import. Users may be imported from LDAP once the LDAP configuration has been completed, thereby creating all user records rather than waiting for each user to authenticate.

As described in the Authentication section above, you may define multiple Search Base DNs for managing authentication and default role assignments. However, there can only be one LDAP import schedule defined for each LDAP domain within each org.

For a given LDAP configuration, the import is defined by identifying the attributes to retrieve from LDAP, whether an LDAP label should be generated as part of the import of a specific attribute (e.g. memberof).


The specified user attributes are then mapped to the USER table fields contained within the K1000. This table is not customizable, but does have four custom fields in addition to the most common user attributes that are typically needed on an import. You may map your LDAP attributes to any of these fields, though LDAP UID, User Name, and Email should be mapped with their associated unique values.


Beginning in version 5.5 of the K1000, Users will be defined within the SettingsUsers page. In prior versions, these settings may be found in Service DeskUsers.

A default Role may be assigned as part of the import in the same fashion as it’s defined as part of authentication. If the role is reassigned within SettingsUsers, this new manually applied setting will override what is defined as a default in the user import.


Once the import is defined, you may wish to set up the import on a scheduled basis. This can be configured in the SettingsUser Authentication page by clicking on the schedule icon for a particular LDAP configuration.

User Labels Now that user records are created in the K1000, you may define user labels to control the content a user will see when they log in to the User UI. User labels may also be used within Service Desk to control assignments, ownership, approvals and other settings within the K1000 Service Desk. You may also define dynamic user labels that rely on verifying LDAP attributes from the external LDAP server when the user authenticates to the K1000. Please see the Service Desk Administration Guide for more details on configuring user labels within the K1000 Service Desk.


File Management

Managing Secure Backups of the K1000 Enable ‘Secure Backup Files’ to prevent backup files from being downloaded via HTTP/S without

authentication.

Utilize FTP to retrieve backups to external storage on a nightly basis in accordance with your defined backup schedule.

Set the FTP password in accordance with your password policies and change it on a periodic basis. This should be a new password used solely for this purpose rather than reusing a common service password.

Fundamentally, you should know explicitly where you last good backup is located, and that access to that backup is properly secured.

Only enable ‘Make FTP Writable’ when you need to conduct a restore and either of your backup files exceeds 2 gigabytes. Once the restore is complete, disable ‘Make FTP Writable’.

Evaluate your history retention policies and make adjustments if possible to reduce the size of your backup files.

The appliance automatically generates daily and monthly backups every day at 3AM local time for the appliance. This generates two files, k1000_dbdata.gz and k1000_file.tgz, that may be used to perform a restore of the appliance at some point in the future. You may alter the time when backups are run and specify how many instances of the daily and monthly backups to retain within the SettingsControl PanelBackup and Restore tab.

However, these backup files are retained on the K1000 so a process should be established to copy the backup files from the K1000 to external storage, preferably also on a daily basis. By default, backup files may be downloaded without authenticating to the K1000 to allow for local processes to be used to retrieve these files and place them in a good location. But generally, this is considered a poor practice for protecting access to your backup files. Therefore, you should explicitly enable Secure Backup Files so that authentication is required to download the files.

You may always retrieve the files directly from within the K1000 administrative UI by going to SettingsControl Backup and Restore, however this process would be manual.


Changes to these settings will cause the K1000 to reboot to properly register the new settings.

Alternatively, you may configure FTP on the K1000 to allow retrieval of the backup files by an external script or program. This can be done by going to SettingsControl PanelSecurity Settings and selecting the checkbox to Enable Backup via FTP. The FTP service has a default set of credentials that are published in the K1000 Administration Guide. You should modify the password value on this same settings page to one you retain and that follows your local password policies. With this configuration, you may set up an external process to automatically retrieve backup files to secondary storage. These files are not encrypted, so they should be placed in a storage location that is secure in accordance with your file management policies. Finally, the outbound protocol for retrieving backup files utilizes port 23. This port will need to be opened if a firewall is to be traversed.

The FTP service may also be used to write large files to the K1000. This is useful if you have large backup files and need to conduct a restore to your primary K1000 (i.e. if your backup files are larger than 2 gigabytes), or if you are using a secondary K1000 for reporting purposes. If you are restoring to your primary K1000, you should only enable the service long enough to complete the upload. If you do have backup files that exceed 2 gigabytes, you may also want to evaluate your history retention and alter how you archive history data to reduce the size of your backup files. Finally, the inbound protocol for making FTP writable utilizes port 21. This port will need to be opened if a firewall is to be traversed.

When you use a secondary K1000 for reporting purposes, special consideration must be made to ensure that the network settings for the K1000 are not overridden by the restore of the backup files from the primary K1000. Contact KACE Technical Support for assistance in this configuration.


Securely Managing Agent Provisioning Enable file sharing only when you need to transfer files to or from the K1000 (e.g. if you will be using

the K1000 Agent Provisioning to distribute and install agents to machines in your environment).

Consider utilizing GPO scripts or any other existing distribution mechanism already in place in your environment to avoid having to configure file shares to distribute the agent.

Alternatively, you may copy the agent installation files from the onboard SAMBA share to an established network share in your environment, and configure the agent provisioning to reference that network share.

Establish a password that follows your local password policies and assign this to the SAMBA share when files need to be uploaded to your K1000, such as large installers, kbin packages from KACE Technical Support, or artifacts from another K1000 that need to be imported into the current K1000.

When provisioning agents via the K1000, provisioning by DNS Hostname is the most reliable method for ensuring the appropriate endpoints are being configured with the agent.

The first task to deploying the K1000 Systems Management Appliance, apart from connecting the appliance itself to the network, is to deploy the KACE agent to the endpoint systems to be managed. The K1000 utilizes an onboard SAMBA file share to deliver and install the agent to the endpoints within the network. For Microsoft Windows based endpoints, this file share may be mounted via NetBIOS or SMB over IP. For Mac OSX and Linux based endpoints, the file is transmitted via SSH.

A K1000 file share may be enabled to require NTLMv2 authentication within Microsoft Windows environments, however, the K1000 does not support NTLMv2 level 5 authentication. Additionally, the K1000 file share must be made available to all endpoints in the enclave, while an alternative method may use file shares or methods that are restricted to the LAN environment where the endpoints reside. For these reasons, identifying an alternative method for agent provisioning is recommended in these kinds of environments. If you require NTLMv2 level 5 authentication for your file shares within your environment, an alternative method that still uses the K1000 to manage the provisioning process is discussed in the Using a Local Share in Agent Provisioning subsection below. Despite this recommendation, a discussion of agent provisioning from the K1000 is warranted and therefore is provided here.

The SAMBA Share on the K1000 is enabled via SettingsControl PanelSecurity. When a multi-org configuration is being used, this setting will enable file sharing for all orgs within the K1000. Toggling this setting to off will disable the Samba Share in all orgs, but will not impact the org specific settings such as each org’s share password. This is an effective means of controlling access to the K1000 file shares to only when access is needed.


A K1000 file share may be enabled to require NTLMv2 authentication within Microsoft Windows environments, however, the K1000 does not support NTLMv2 level 5 authentication. If NTLMv2 level 5 authentication is required in your environment, please refer to Using a Local Share in Agent Provisioning below.

Within each org (or within the General Settings on a single org K1000), the file share may be enabled or disabled independently from the other org file shares on the K1000. Each org has its own share password and should be set in accordance with local password policies to govern access. This password is assigned to the admin user where the number of the org is appended to the name of the admin users (e.g. admin_3). The password is only used when data will be uploaded to the share using the appropriate file share folder for the org (e.g. \\myk1000\clientdrop_3\ when my org is Org 3).


The assigned org number for the admin user and file share folder are clearly indicated in the K1000 Settings page of each org.

In a Windows environment, agents are provisioned by providing Windows network administrative credentials for the Active Directory Domain, Admin User, and Password for the endpoints being provisioned. The K1000 will use these credentials to authenticate to the endpoint and open the appropriate share on the K1000 using either NetBIOS or SMB over IP. Once the share has been opened the MSI installer for the agent will be downloaded and executed. Endpoints to be provisioned may be designated by specific IP address, IP address range, or a list of DNS host names.

If DNS host names will be used, the appropriate DNS name server must be configured for lookup.

NetBIOS is effectively becoming a legacy protocol as environments move further way from Windows 2000 / NT. In most installations, NetBIOS has been disabled and subsequently port 139 is blocked on most firewalls. SMB over IP will also typically be blocked on most firewalls and therefore may need to be enabled if you wish to use the K1000 for agent provisioning. Either port 139 or port 445 may be used, and it is advised that only the one designated by your network administrators be used. This is a one-time task that only takes place when first deploying the K1000. Once agent provisioning is completed, the appropriate configurations on endpoint and network firewalls should be re-established.

If you have another means to distribute and execute the agent installation on your Microsoft Windows machines, it is advised to utilize this established method. This will minimize any impact on your internal network configuration.


Using a Local Share in Agent Provisioning One alternative that may be employed to deploy agents using the K1000 and potentially minimize the impact on your network is to configure an established network share for delivering the agent installation files. This approach allows you to manage the provisioning tasks from within the K1000 while using existing file shares in your environment that comply with your established policies.

To do this, copy the agent installation files from the onboard SAMBA share to your established network share, and configure the K1000 Server Name and K1000 Client Share Name to be the hostname and share name of your established network share.


Once the files have been copied off and placed on the new source file share, edit the agent_msi_provision.bat file to direct the agent installation to the DNS name or IP address of the new source file share by changing the line > set KBOX_SERVER=%4

to

>set KBOX_SERVER=myfileshare.mydomain

To complete the provisioning configuration, go to SettingsK1000 Agent Advanced Provisioning to create a custom configuration task that will reference the new source file share. Provide a Config Friendly Name and a Provisioning IP Range (Auto Provisioning), a list of specific Target IP addresses (Manual Provisioning by IP) or a list of Target Hostnames (Manual Provisioning by Hostname), and click Configuration Enabled. Next, specify the K1000 Server Name or IP Address and the K1000 Client Share Name as the host of the new local source share host and name. If a list of Target Hostnames are being used, be sure to enable DNS Lookup Enabled to resolve the target hostnames. Set the Windows Platform Provisioning Settings as indicated in the screenshot below.


This works provided the established network file share is accessible by the range of IP addresses or machine hostnames defined in the provisioning configuration.

For Linux and Mac OSX endpoints, the agent is provisioned by providing Network Root Credentials for the User Name and Password for the endpoints being provisioned. The K1000 will use these credentials to authenticate to the endpoint and open the appropriate share on the K1000 using SSH. Once the share has been opened the appropriate installation file (.rpm, .deb, or .pkg) for the agent will be downloaded and executed. Endpoints to be provisioned may be designated by specific IP address, IP address range, or a list of DNS host names.

Additional information regarding alternatives for agent provisioning may be found at

http://blog.kace.com/2012/05/24/options‐for‐deploying‐the‐k1000‐agent/


Email The K1000 provides an onboard SMTP server to manage service desk queues for communication and assignment of service desk requests to the appropriate service desk agents, and to send notifications to administrators or other users when certain conditions exist. Note that this is not a general purpose email solution. No mailboxes are assigned to any users directly on the K1000. Rather, it is a ticket queuing mechanism to organize service desk work, and an outbound email service for notification delivery. However, for these features to work effectively it is necessary to integrate the service desk SMTP server with your organization’s email services so that email requests may be submitted by end users and email notifications may be managed within each user or administrator’s assigned email.

Securing Inbound Email Use an Alternate Email Address defined in your existing email services that will be mapped to the

K1000 service desk queue.

Only accept email on the service desk queue from users that have been configured within the K1000 as users of the appliance.

If possible, locate the K1000 and an MTA for your existing email services within the same subnet and with MX records in DNS defined to exchange SMTP messages between your MTA and the K1000.

If encryption of email is desired, utilize the SPOP3 protocol for retrieving inbound email from your existing email services.

Inbound email for the K1000 is restricted to new service desk ticket requests and processing responses to service desk tickets. A service desk ticket may be initiated when an end user emails a request to a configured service desk queue. Once this communication is initiated, assigned service desk agents, request approvers, notified users, and the original ticket submitter will receive outbound email as the ticket is processed according to how the following rules are configured on the queue:

Owners, submitters, and approvers may then respond to these generated emails to alter the state or provide additional context to the service desk ticket. Greater detail on the configuration of the service desk is discussed in detail in the K1000 Service Desk Administrator’s Guide.


Inbound email is delivered to the K1000 using either SMTP (email addressed for the service desk is forwarded from your organization’s primary email services) or S/POP3 (email is pulled or ‘fetched’ from email services into the K1000). Which protocol is used depends greatly on the email services in use by the organization and what is supported by these existing services. By default, the K1000 supports inbound email via SMTP using the onboard SMTP server. If S/POP3 will be used, an additional setting must be made within the SettingsNetwork Settings page (the appliance will reboot when these settings are saved):

Regardless of the protocol used, there are similarities in the service desk queue configuration that should always be applied.

When configuring a service desk queue, the underlying queue will have an email address generated for it that is comprised as <org#>.<queue#>@<hostname>.<domain>, where org# is the org where the queue is configured in a multi-org configuration, queue# is a generated name for the current queue being configured, and hostname and domain are the values provided when the K1000 was initially configured on the network (see the Console subsection of the Appliance Services section below). This is a cumbersome email address to use for a service desk, therefore an Alt. Email Address should be


defined for the queue and used as the known email address for the helpdesk within existing email services. For SMTP, this email address on the existing email service should be configured as a ‘contact’ address as a mailbox is not required. For SPOP3, this email address will need to have a mailbox on the existing mail server.

The following screenshot illustrates the configuration when SPOP3 is selected as the protocol. The POP3 Server, POP3 User / Password, and Use SSL fields will not appear when SMTP is being used as the protocol.

Additionally, ensure that the Accept Email From Unknown Users is unchecked (this is the default setting). This will require that a record for every known user within the organization that will be using the service desk be imported from Active Directory into the K1000 on a schedule so that the service desk is able to process requests from all users (see the Import LDAP User Attributes subsection of the User Roles section above). This setting ensures that only users that are defined within Active Directory and have valid email addresses in your email services may submit email to the service desk. Also, note that the default setting for Grant Read/Edit Permissions to Users with an Admin Role is checked on. Depending on local requirements for separation of duties, it may be desirable to uncheck this box so that only helpdesk admins may edit tickets. The rest of the queue configuration attributes will depend greatly on the desired design of the helpdesk implementation and are not discussed further here.


Configuring the SPOP3 Protocol To configure SPOP3 on your existing server, ensure that your existing email service supports the SPOP3 protocol and that you’ve created the email address specified in the Alt. Email Address as a mailbox on your existing email server. This must be a mailbox rather than a contact address so that mail may be received on your existing email services. The user name and password for this mailbox will be configured in the POP3 User / Password fields when the service desk queue is initially set up.

POP3 is a ‘pull’ protocol, so the K1000 will periodically fetch email from the mailbox to process service desk tickets. When Use SSL is selected, all inbound communications is encrypted from the existing mail services to the K1000. The certificate supplied in the configuration for web services is used in the encryption for SPOP3. All traffic for this protocol is transmitted over port 995 when SSL is used, or port 110 when SSL is off.

Configuring the SMTP Protocol As noted previously, configuring the SMTP protocol for inbound mail doesn’t require any configuration changes on the K1000 as this is the default setting. However, there are configuration changes that need to be made on your existing mail server. Specifically, you will need to configure the email address for your service desk queue as a contact on your mail server with the appropriate routing rules to forward mail for the contact to the K1000. As an example, Exchange 2010 would be configured to define a Send Connector to route emails to the K1000 by using a smart host:


The SMTP address for the smart host would be the FQDN of your K1000:

Next you would define a mail contact in Exchange that would be the address your end users would mail

to when opening a new service desk ticket:


Finally, the external email address of the newly created Contact would be the system generated email address of the queue that you have created on the K1000:

Ideally, you should have an MTA for your existing mail service within the server subnet where the K1000 is deployed. You may then configure MX records within your DNS that are restricted to that subdomain and define the message exchange between your existing mail server and the K1000.

Securing Outbound Email Consider configuring an SMTP server within your existing email services to receive outbound mail from

the K1000 if additional security is desired for outbound mail transfer.

Outbound mail for the K1000 is only transmitted over SMTP. Outbound email consists of messages delivered from the service desk to message recipients for a specific ticket or condition on a ticket. They are also generated for notifications and scheduled reports that may be configured in multiple places within the K1000. Outbound mail is transmitted via port 25 or port 587 if no port is specified, or the port you designate if you specify an external SMTP server for routing. All outbound email traffic unencrypted.


You can configure an external SMTP server to manage the routing of outbound messages to the rest of your email services by specifying the SMTP Server, User Name, Password, and Port in the SettingsNetwork Settings page as follows:

You may utilize both SPOP3 for inbound mail and SMTP for outbound mail, and the host for both protocols may be the same or different servers depending on your local mail implementation.

Administrative Email Alerts Configure an email alias for your K1000 system administrators that will receive daily status emails for

the K1000 services and will notify your administrators of any potential security breaches.

The administrator email is configured on the SettingsGeneral Settings page and enables administrative email alerts to be delivered to your administrators.


Multiple checks are applied on a daily basis on the K1000, and are transmitted to the K1000 appliance administrator. Checks include:

1. Available disk space warnings 2. Unauthorized introduction or modification of setuid, getuid, or device files 3. Root UIDs (i.e. has a new user id been created that has root access?) 4. Passwordless accounts that have been created 5. Login failures to the console 6. Refused connections from the server 7. General system maintenance, such as

a. Cleanup of stale temporary files b. Disk usage statistics c. Network interface status d. System uptime and load statistics e. List of any rejected mail hosts, denied zone transfers, or rejected mail f. Backup status g. Database integrity status

An example of an available disk space warning appears as follows:


An example of the daily security email appears as follows:


An abbreviated example of the daily system maintenance email appears as follows (note that the actual message is longer than should be pasted in this document):


Appliance Services KACE appliances are web application appliances. Customers are provided limited console access for initial configuration and troubleshooting. Once configured, all appliance functionality is accessed and managed through the Web User Interface, and OS access is not needed for normal appliance operations. Operating system and service patches are also applied via the administrative web UI by applying a digitally signed and encrypted update package that is provided periodically from Dell KACE Technical Support. There are two console logins that are provided to allow for the configuration of network services (‘konfig’ account) and network diagnostics (‘netdiag’ account) when the administrative web UI is not accessible (e.g. during initial configuration). This section describes the available system monitoring and troubleshooting utilities, and the system update facility.

Health Monitoring The Admin UI provides a number of features for monitoring the health of the K1000 during normal operations. All options and capabilities for monitoring and troubleshooting K1000 system health is beyond the scope of this document. The discussion here focuses on ensuring that health monitoring is conducted in a secure fashion in compliance with all security policies.

Enabling SNMP Monitoring of the K1000 When utilizing SNMP Monitoring, alter the SNMP Community String to a value that is specific to your

environment.

SNMP Monitoring allows the K1000 appliance to be scanned by an SNMP Management tool utilizing the SNMPv2 protocol. By default, SNMP is not enabled on a K1000 and must be explicitly enabled in order to monitor the health of your K1000 via an SNMP Management tool. If this service is needed for a given deployment, it is recommended to change the SNMP Community String to a locally defined value that is specific to your deployment.

There is no provision within the K1000 for configuring SNMP traps to be sent to your SNMP Management tool. Therefore, you may only scan the K1000 periodically for SNMP information.

If you enable SNMP Monitoring, you will need to open Port 161 outbound from the K1000 for the UDP protocol on any firewall that must be traversed.


An SNMP based scan of the devices on your network may be defined within InventoryIP Scan and utilized to manage device discovery as part of agent provisioning and asset management processes. These configurations are distinct from enabling SNMP monitoring on your K1000, and are not discussed further in this document.

SSH Access Always enable SSH when you are planning periodic maintenance of your K1000, and disable SSH during

normal operations.

Occasionally, you may need assistance from KACE Technical Support that extends beyond advice provided via phone or email, or by patch updates delivered by Technical Support. In these instances, you may want to allow KACE Technical Support Personnel to access your K1000 via SSH to resolve issues. Any time you are planning to perform any kind of maintenance on your K1000 (e.g. upgrade of your K1000 from KACE, performing a restore from a prior backup, making significant changes to patch subscription settings, etc), you should turn on SSH by going to Settings->Control Panel->Security Settings. Be aware that altering this setting will require your K1000 to reboot to register the change. During normal operations, you may leave this option disabled.

This setting requires port 22 inbound to be opened on any firewall that must be traversed to get to the K1000. You may not need to alter your firewall rules if your K1000 technical administrators are able to access the network where the K1000 is homed and may open an SSH session that can be shared with KACE Technical Support via some other remote access technology (e.g. webex.com).

Updating the K1000 Review and retain the update log after applying any KACE provided ‘kbin’ update file.

As part of the Dell KACE Software Quality Assurance processes, vulnerability assessments are processed on core services and appropriate updates and patches are applied into periodic appliance updates along with bug fixes and enhancements. These updates are delivered to customers as a digitally signed and encrypted update package that may be retrieved manually from the Dell KACE support website or downloaded directly from within the K1000. These updates are applied via the administrator web interface, and produce logs that are also accessible via the web interface.


Once the update file has been retrieved from the KACE website, it may be applied to update the

K1000. To apply an update the K1000, go to SettingsServer Maintenance page, and click to select the file from the local file system of the workstation where the web UI is being accessed.

Click to perform the update. The system will typically reboot as part of this process.

Once the update has completed and the system has rebooted, the results of the update may be viewed in the Updates log. This log can be found by going to SettingsLogs page and selecting the Updates log from the dropdown list.


This log should be reviewed closely and retained for your records.

Logging There are two locations where system logs may be obtained. Within the admin web UI, go to the SettingsLogs page. Multiple logs are available to view, and are discussed further in the Maintaining the Appliance section of the K1000 Administrators Guide. This list of logs are the current logs on the appliance and may not contain the depth needed to analyze a particular issue since the logs rotate at least daily, and more frequently for larger logs.

To obtain all of the logs on the system, go to the SettingsSupport Troubleshooting Tools page and select the K1000 Troubleshooting Logs for download. This will download a zipped file containing all logs on the system.


Console Ensure that access to the K1000 console is restricted to the K1000 system administrators only.

If a remote access technology (e.g a remote access card (e.g. DRAC), vSphere console, KVM, etc.) is being used, ensure that access to the K1000 from these utilities is password protected.

The K1000 Network Settings identify the appliance on the network. There are two places where these settings may be applied:

1) Within the appliance console, using the login user ‘konfig’ and password ‘konfig’; and 2) Within the administrative web UI, within the Settings->Network Settings tab.

Basic Network Configuration is initially accomplished via the appliance console. Once these settings have been made, they may be updated via the web-based administrative UI or the appliance console. Additional information regarding the configuration of network settings for the appliance may be found in the K1000 Setup Guide (Physical or Virtual). This section will focus on utilizing the appliance console for the basic network configuration.


All of the same settings are available in both locations and may be used interchangeably, though the administrative web UI won’t be accessible until the network settings have been properly configured on the appliance console, thereby allowing the web server within the appliance to respond to browser requests.

Any change made to these settings in either location will cause the appliance to automatically reboot in order to properly register the changes.

Network Diagnostics Additionally, network diagnostics for troubleshooting issues the K1000 configuration within the network are attainable in two places:

1) Within the appliance console, using the login user ‘netdiag’ and password ‘netdiag’; and 2) Within the administrative web UI, within the Settings->Support->K1000 Troubleshooting

Tools tab.

However, there are several differences in the diagnostic utilities that you’ll find in each of these locations. The following table summarizes these tools, where they can be found, and their purpose:

Utility Netdiag Troubleshooting Tools

Purpose

arp + + Displays and modifies the Internet-to-Ethernet address translation tables used by the address resolution protocol

dig + + Performs DNS lookups and displays the answers returned help + Redisplays the list of available commands on netdiag httpd80 + Starts httpd on port 80 only, disabling all redirects ifconfig + + Queries configured network interfaces within the K1000


iostat + + Displays I/O statistics on devices and CPU operations krestore + Command line restore from K1000 backup or to factory klogin_reset + Reset login for ‘admin’ using login of user with admin

role netstat + + Displays network connections, routing tables, interface

statistics, masquerade connections, and multicast memberships

nslookup + Queries Internet domain name servers to validate entries ping + + ICMP request to validate a host or ip address is reachable purgepatches + Deletes all patches from your K1000 reboot + Soft reboot of the server route + Manipulates the K1000’s IP routing tables startftpd + Start the File Transfer Protocol Daemon startsshd + Start the Secure Shell Daemon systeminfo + Shows the system information top + Displays list of most CPU-intensive tasks uname + Displays operating system information database + Displays database health statistics smbstatus + Displays smb.conf information for the samba share email sending + Sends a test email to the specified email address services + Displays K1000 services status

These two appliance console accounts are restricted accounts and the only ones available to the end customer.

Tether Open port 22 for SSH outbound on your firewall and enable a Tether to connect to KACE Technical

Support when you and KACE Technical Support agree that deeper evaluation of the health of your K1000 is required. Disable the Tether once all issues have been resolved.

Alternatively, you may open SSH (port 22) outbound from the K1000 on your firewall rule settings, and then utilize a Tether to connect to KACE Technical Support. This approach uses a one-time key that is generated by KACE Technical Support and allows support to login directly to your appliance. Once the tether connection is disabled, they connection and its associated key are invalidated. This approach is a more secure technique to maintaining an SSH session since it originates from the K1000, requires a key to function, and may be enabled and disabled only by the customer. Additionally, it is a more effective approach for KACE Technical Support to provide assistance and will typically greatly reduce the time required to resolve technical issues.

You should only enable a tether when directed by Dell KACE Technical Support. To enable a tether, go to the Settings->Support->K1000 Troubleshooting Tools page. Select Enable Tether and paste the RSA key value provided to you by Dell KACE Techical Support. Once the key has been applied, a Technical Support Engineer will be able to access your K1000 for service. At the conclusion of this activity, you may return to this page to disable the tether which will invalid the key that was used.


Other Resources

Dell KACE Corporate Background Dell (NASDAQ: DELL) creates, enhances and integrates technology and services customers count on to provide them reliable, long term value. Dell provides systems management solutions for customers of all sizes and system complexity. The award-winning Dell KACE family of appliances delivers easy-to-use, comprehensive, and affordable systems management capabilities. Dell KACE is headquartered in Mountain View, California. To learn more about Dell KACE and its product offerings, please visit www.dell.com/kace or call 1-877-MGMT-DONE. Helpful Links: • KACE Systems Management Appliances • KACE Systems Deployment Appliances

Dell KACE Headquarters 2001 Landings Drive Mountain View, California 94043 (877) MGMT-DONE office for all inquiries (+1) (650) 316-1050 International (650) 649-1806 fax [email protected] European Sales: [email protected] Asia Pacific Sales: [email protected] Australia New Zealand Sales: [email protected] While every effort is made to ensure the information given is accurate, Dell does not accept liability for any errors or mistakes which may arise. Specifications and other information in this document may be subject to change without notice.

Best Practices for a Secure K1000 Deployment Best... · Single Sign-On with Windows Credentials ......

Documents

Transcript of Best Practices for a Secure K1000 Deployment Best... · Single Sign-On with Windows Credentials ......