In the past I’ve always been stuck on what to have set for a devices wallpaper. Since moving to an Apple Mac, I’ve been able to make that decision someone else’s problem :- http://www.kuvva.com
P.S If you want to understand the full power of someone else’s problem, Douglas Adams has a great example of this in “Life, the Universe and Everything” (1982, ISBN 0-345-39182-9)
Summary
In order for Novell Service Desk to accept notes that are emailed to the system and have those notes appended to the request referred to in the subject line, there are a number of requirements that need to be met.
In order for an emailed note to be accepted by Novell Service Desk it must meet the following requirements:
1. The sender of the email *MUST* be a registered user of the Novell Service Desk and their email address must match either the email address on their account or one of the email alaises defined for their account.
2. The Email subject *MUST* contain ONE of these strings:
Incident #{INCIDENT NUMBER}
Change Request #{INCIDENT NUMBER}
Service Request #{INCIDENT NUMBER}
That is the request type, represented by one of these strings, followed by the request number.
Customers and Technicians are able to interact with Novell Service Desk using the email system, although it is anticipated this would more typically be the usage scenario of the Customers, whilst the Technicians would make use of the console to better facilitate access to the tools provided to resolve the request. Technician emails were enabled to make it possible for a registered technician to be able to respond to email and CC the Novell Service Desk email address and have the note sent to the customer and also have it logged against the incident in the Helpdesk/Support system, better assisting mobile technicians to provide assistance.
Before the Christmas / New Year holiday I started looking into Novell Service Desks APIs. This was for a plug-in which is being created for Brainshare 2013. You will be able to see it in action during the Novell keynote and also in the Central IT demo labs. If you’re coming along to Brainshare 2013, please come a take look; I’ll write a blog post on the inner workings at a later date. Without wanting to give away too much, the plugin automates bundle assignment within a workflow.
Back to APIs. Whilst looking at these, it occurred to me that people might want to a little guide to starting to use them. There’s a wide range of functionality available, ranging from obtaining the version of Service Desk to creating purchase orders.
Before we start, here’s the ingredients that you’ll need
1 x Novell Service Desk appliance v7.0 or later
1x PHP editor ( there’s lots of them about , notepad will suffice. Geany is nice or Notepad++ )
1x PHP installed on your computer ( I’m using Ubuntu 12.04, PHP is also available for Windows fanboys and Apple Mac followers of fashion )
You may wonder why we’re using PHP. PHP is installed on Novell Service Desk appliance so you can run the scripts that we’ll create . Mainly its because my Java / C# is doesn’t run to much beyond ‘Hello World’ although I have written interrupt service routines in x86 assemble language. They were the days. //sigh//
We’re going to start by creating an class that will handle communications to the webservice API calls of Novell Service Desk ( anyone mind if I refer to this as NSD from now on? No? Good ). Lets call our class nsdComms.
Our task for today is to create a comms channel to NSD , login, get the version and then logout.
Our PHP code with inline commentary looks like this:-
<?php
class nsdComms
{
// property declaration
public $hostAddress; //IP address or FQDN of NSD appliance
private $objClient;
private $baseService;
// method declaration
public function CreateSOAPClientObj() {
$baseProduct = 'LiveTime';
$baseAddress = '/' . $baseProduct . '/WebObjects/' . $baseProduct . '.woa/ws/';
$this->baseService = 'http://' . $this->hostAddress . $baseAddress;
$this->objClient = new SoapClient($this->baseService . "Authenticate?wsdl", array('trace' => true));
}
public function login($ldapsource,$username,$password) {
// Authenticate?WSDL is required for this operation
$this->objClient->SoapClient($this->baseService . "Authenticate?wsdl", array('trace' => true));
$results = $this->objClient->connect($ldapsource, $username, $password);
$success = $results['success'];
if ($success=="false") {
exit();
}
}
public function logout() {
// Authenticate?WSDL is required for this operation
$this->objClient->SoapClient($this->baseService . "Authenticate?wsdl", array('trace' => true));
$results = $this->objClient->disconnect();
}
public function about() {
// About?WSDL is required for this operation
$this->objClient->SoapClient($this->baseService . "About?wsdl", array('trace' => true));
$results = $this->objClient->version();
$success = $results['success'];
if ($success=="false") {
exit();
}
return $results;
}
//End of class
}
$objNSD = new nsdComms(); //Create nsdComms object
$objNSD->hostAddress = "192.168.2.81" ; //IP address of my NSD appliance, change as required
$objNSD->CreateSOAPClientObj(); //Establish communications channel to appliance
$objNSD->login(NULL,'super','super'); //Login using local NSD account super. NULL indicates that there is not a LDAP source being used.
print_r($objNSD->About()); //Obtain the version information from NSD and display it
$objNSD->logout(); //Logout
?>
Copy and paste the code to a file ending in .php and then save
At the command line, execute the file by typing
php <filename>
and you should see output something like this:-
Success!
Over the next series of blog postings, we’ll do something useful.
The first step in the process of deployment is planning the actual deployment. The following are recommendations on how to plan this process:
Contact departmental leaders and inform them about the deployment.
Make suggestions on how you want to roll out ZFDE to devices, including which departments are going to be targeted by date and time. Make sure you line this up with your planned deployment schedule in your project plan. Ensuring that everyone knows that this is a deliverable of the organization makes it much easier to line up the departments, sites, or groups for deployment.
Identity and notify individuals that are part of the pilot phase of the deployment.
Emphasize that feedback is key to the success of this project. Individuals who are part of the pilot and more wider-scale deployment should provide feedback directly to the IT organization or to the Service Desk.
Make sure your teams are well informed of the deployment. This includes:
Documentation is key to the success of every aspect of the project, including how you plan to deploy the services and agents. Everyone directly involved in the actual deployment, should have documentation that they can reference at all times, eliminating the chance of error.
Documentation regarding the deployment processes needs to be completed during the design phase, and while you are testing the deployment in your test lab facilities. After you have proven the concept and included deployment activities in the design document, you should create a Deployment Assistance Guide that can be used by the individuals who are involved. You might not need to share the entire design document with everyone involved in the deployment of the product. Use your best judgement here.
We recommend that you set aside some time before you perform your pilots to further prove your deployment by running some last-minute tests. Allow enough time so that any adjustments can be made and documented prior to deployment.
Perform the test in your lab facilities, using three or four sample workstations with a sample of line-of-business applications installed. This can be a replica of tests done during your full testing phase.
The first phase of the actual deployment is the pilots. This is where you deploy ZFDE to those devices that you identified and notified as part of the pilot phase. You are looking for feedback from these individuals, and this can be done through a feedback form, e-mail, or face-to-face meetings.
Do not perform the pilots all at once. Use a rolling approach to this phase. If something goes wrong with the deployment, you want to limit the number of people that are impacted. After you are confident that the deployment is going as planned, you can increase the number of devices you deploy to.
After you have completed the pilot deployments, you can move on to a wider deployment. Continuing to use the deployment plan that you have documented. You should execute against your project plan until you have completed the rollout to all remaining workstations on your network.
After you have completed the deployment, you should document all steps you took to deploy across your entire infrastructure. We recommend that you do this outside of the project plan, and include this in your documentation repository as either a separate document or as a part of your existing design document.
In addition, you should validate your success as much as possible. This can be done by doing the following:
Perform physical spot checks wherever you can. Interview individuals briefly to see if they are experiencing any issues with the deployment, and more specifically with the addition of ZFDE
Review error logs in ZENworks Control Center and investigate further from there. Visit workstations to find out more details if necessary.
Monitor Service Desk activity throughout the duration of the deployment phase. Service Desk incidents reveal a lot of information. You are looking for spikes in activity and the details of the individual Service Desk requests.
A “Best Practice” is commonly defined as “a technique or methodology that, through experience and research, has proven reliably to lead to a desired result. “Best Practice” is not about “perfection”, its about getting the job done.
In the context of the next series of paragraphs, sentences, words and occasional doodle, Best Practice is all about sharing knowledge about lessons learned in deploying Novell ZENworks Full Disc Encryption (ZFDE) to ensure the highest degree of success.
Novell Full Disk Encryption provides sector-based encryption for standard IDE, SATA, and PATA hard disks. All disk volumes (or selected disk volumes) are encrypted, including any temporary files, swap files, and operating system files on the volumes. The data cannot be accessed until a valid user successfully logs in, and the data can never be accessed by booting the device from media such as PXE, CD/DVD, floppy disk, or USB drive. Literally, everything is encrypted including that browser history you’d rather not be made public. For an authenticated user, accessing data on the encrypted disk is no different than accessing data on an unencrypted disk.
Encryption can work in two ways:-
1. Hardware-based FDE
This provides support for hard drives that use an on-board hardware encryption chip. All data written to the drive or read from drive passes through the hardware encryption chip first. This approach does not have a performance impact on operating system or applications as all encryption / decryption is done on a dedicated processor on the drive itself. The Encryption Key is supplied on the drive by manufacturer. Currently only Seagate Momentus FDE.x Drives are supported for hardware-based FDE with support in a future release for drives adhering to the TCG’s OPAL Standard.
2. Software-based FDE
Used for machines with “standard” drives in them and can be used on most drive types and sizes. The drive must must undertake an initial encryption process and the time required varies with whether or not entire drive is encrypted or just used sectors. Encryption happens at sector level – not the file level.
There are a number of factors that you’ll need to take into account before commencing deployment. The minimum is given here; you will need to adjust depending on your I.T environment and organizational policies / structures.
ZFDE is fully integrated with and managed by ZENworks Configuration Management (ZCM). The range of supported platforms for ZFDE is a subset of those for ZCM, namely:-
NOTE: Future versions of ZFDE will support Windows 8.
If using Hardware-based FDE, the drive must have 130 MB of disk space available. The free space required when using software-based FDE varies depending if the PBA will be used (Pre-Boot Authentication is a hardened Linux OS that must be authenticated to first before Windows is started). With PBA 230 Mb is needed; without 95 Mb.
The PBA resides on a primary partition on the System Drive and Windows only allows 4 primary partitions. Windows newer than Windows XP, have a 100 Mb disaster recovery partition as the first partition on the System Drive. This leaves 3 partitions available.
The partitions must be Windows basic disc types; Dynamic is not supported.
NTFS must be used for existing partitions.
SATA and SSD drives are supported, including hybrid drives that combine both technologies; SAS / SCSI controllers are currently not supported.
Pre-boot authentication is the process of authenticating a user to a device before the device boots to the primary operating system. For ZENworks Full Disk Encryption, the ZENworks Pre-Boot Authentication module, referred to as the ZENworks PBA, performs this operation on a device. The two primary advantages of using the PBA are:-
1) It adds another layer of authentication before Windows starts, an extra padlock if you like.
2) Protects against attack vectors for devices that have FireWire ports. This simple attack takes advantage of the FireWire protocol and its ability to directly access and modify the RAM of a target machine with a FireWire port installed. Using a simple and readily available forensics software tool, it is possible to connect a FireWire cable to a computer, and within seconds bypass the Windows authentication and log in as a local administrator. This method has also been adapted to capture the security keys used to decrypt and encrypt the disc.
The primary disadvantage of using PBA is hardware support. The ZENworks PBA is hosted by a fully hardened Linux OS installed on the device which is protected against changes. The PBA uses Direct Media Interface (DMI) to do a “soft reset” into Windows after the end user has authenticated. Older or brand new machines, or ones that simply have badly written BIOS may not work properly with the PBA Kernel’s default settings. You can change the settings for those naughty devices so that the soft reset works. Another disadvantage is the hardware support contained with the Linux kernel; very new hardware may not be fully supported.
Also don’t forget that PBA introduces a visible change on users devices. If end users are comfortable with normal Windows login procedures and are resistant to change then this could cause acceptance issues. Whether you use PBA or not, ZFDE is active and prevents disk access until authentication is successfully completed.
You may now be forming the view that the additional security protection offered by using PBA outweighs any potential clash with BIOS and hardware drivers. Deploying FDE without using PBA for devices that have FireWire ports sounds rather building a deep moat around your office complete with a stolid drawbridge which you then leave in the down position.
Unless you’re using ZENworks Endpoint Security Management ( ZESM ) that is. One of the capabilities of ZESM is port control and one of those ports that can be disabled is the FireWire port. With ZFDE and ZESM, you can safely use Windows only authentication and be protect against potential FireWire port based comprise attempts.
Unless you have Seagate Momentus drives which support hardware-based encryption then you’ll be using software-based encryption. With software-based encryption, the drive needs to be encrypted. The time required to do this will vary depending on if you have selected the entire drive to be encrypted or just used areas. As a rough estimate it takes 30 – 40 minutes for every 10Gb worth of data.
If you have already deployed another vendors full disk encryption application, it will need to removed before deploying ZFDE. On removal, it is likely that the drive will be decrypted but you will need to check that this is the case. Allow time for the decryption process to complete before deploying ZFDE.
Chkdsk (Chkdsk.exe) is a command-line tool that checks volumes on your hard disk drive for problems. The tool then tries to repair any problems that it finds. For example, Chkdsk can repair problems related to bad sectors, lost clusters, cross-linked files, and directory errors. Chkdsk must be run by an administrator or as someone who is a member of the local Administrators group. It is critical that chkdsk is run on every device before ZFDE is installed and there is an option in the ZFDE policy definition to do this. Alternatively create a ZCM bundle which installs and runs a batch file that has the following content
CD c:\Windows\System32 Echo Y | chkdsk /r
CHKDSK will run the next time the device is restarted. You may force this as part of the bundle.
Make sure to do interoperability testing on your hardware prior to deployment. You will need gather a representative samples of all hardware and test in a lab environment. This will indicate configuration changes for ZFDE if using PBA. There may be device BIOS changes also required for PBA depending on the hardware.
You are strongly advised to backup any device prior to install a ZFDE policy especially if that device is located in an area that is know to have sporadic power outages. ZFDE will resume encryption following a device power cycle but it is better to have a backup in case of non-optimal circumstances.
The CMDB in Novell Service Desk assigns an unique number to each entry at the time of creation. The main advantage of this is administrative; you don’t need to worry about it. However there are drawbacks.
Consider ACME Corporate who has asset tags on their equipment. End users at ACME are used to reading out the asset tag to the service desk who would then use this to find the item. You would configure Novell Service Desk to store the asset tag as part of an Items details. So far, so good.
When an end user at ACME contacts the service desk, the Technician has to search the CMDB to find the Item for the request. The Technician performs the following procedure
1) Find end user
2) Find Item for the request by selecting the Category, click on Advanced, choose Asset tag and type in the tag
Which is somewhat cumbersome.
Novell Service Desk allows the use of custom Item numbers. You can then use whatever value you desire e.g asset tag, hostnames, serial numbers etc..
ACME technician request logging experience becomes:-
1) Find end user
2) Find Item for the request by typing the asset tag into Item Number box
Much easier and quicker.
Configure this by:-
You’re now able to use custom Item numbers
