Blog Posts tagged with KACE K2000 RSA

Ask a question

Samba CVE-2012-1182, the K1000 and the K2000

On April 10, 2012, the developers of Samba revealed a remote code execution vulnerability with potentially serious security consequences.  The vulnerability is described in detail at https://www.samba.org/samba/security/CVE-2012-1182. The version of Samba used in KACE K-Series appliances contains the vulnerability.

The Dell KACE team is preparing an update to each appliance that will upgrade Samba to a compatible version which does not contain the vulnerability.  We hope to have that update ready soon.

In the meantime, there are precautions that can be taken to mitigate the potential vulnerability:

Dell KACE K1000 and VK1000 Systems Management Appliances, all versions:

Samba file shares are only necessary for provisioning the K1000 agent.  If your security team recommends the disablement of Samba until a patch is available, you can provision the agent through other mechanisms.  Samba can be disabled by logging into the web admin console and navigating to Settings/Control Panel/K1000 Security Settings and unchecking the box for "Enable File Sharing" under "Samba Share Settings".

Dell KACE K2000 and VK2000 Systems Deployment Appliances, all versions:

Samba shares are an integral part of K2000 and VK2000 functionality, and cannot be manually disabled.  Dell KACE recommends that access to appliance Samba shares be limited by means of physical and network security to mitigate this possible vulnerability until the security update is available from Dell KACE. 


Customers with questions or concerns may contact Dell KACE support or reply in this thread.  I'll do my best to answer your questions and update this thread as more information becomes available.
 

 

View comments (3)

I've upgraded to 3.4, now what?

So you have applied the 3.4 update, or are about to, and want to know what changes should be expected?

 

If you have not already installed the update we recommend you follow the procedure outlined here for a smooth update.

  1. Have a backup of your images, scripted installs, media, pre/mid/post install tasks, etc.
  2. Under Settings & Maintenance | Security, enable “Allow SSH Root Login (KACE Support).”  This will allow support to login the box should anything wrong happen.
  3. Reboot the K2000 prior to installing the update.
  4. Apply the update.

 

If your driver/restore share password is anything other than admin, you should start by creating a new KBE with the latest version of the KACE Media Manager, available for download from your k2000 library tab.  This update locks down the petemp and peinst shares that were open in the past and now require authentication to access them.
Also if you have any Mac NetBoot environments you will need to create new ones to access these shares, or if you want to add a Lion NetBoot environment. Again, the 3.4 media manager is required to build these environments.
For instructions on how to create a KBE refer to your admin guide, or this knowledgebase article.

 

The driverfeed has been updated to version 2. Drivers that have been downloaded them from the feed will automatically get installed on your scripted installs.
There are a few changes though that you should be aware.  If you had implemented driverfeed in the past then you should refer to this knowledgebase article [http://www.kace.com/support/resources/kb/article/K2000-3-4-Drivers-Postinstallation-Structure ] to straighten out your driver feed.
If you have models other than Dell, you can implement those into the drivers_postinstall directory manually, just follow this knowledgebase article [http://www.kace.com/support/resources/kb/article/K2000%20-Setting-up-Driver-Feed-with-non-Dell-Systems-in-3-4].
The driverfeed is not automatic with your images, but you can still use the driverfeed workaround with your images, look at this itninja post.

The drivers_postinstall directory now will automatically sync with your RSAs, so if you created this directory on petemp in the past, you can now remove them.  Don't forget to upgrade your RSAs though.  You can do this right from the K2000.  Browse to Deployments | Remote Sites.  Click on the detail page of an RSA, then click on "Check for Update." Once it reports an update is available, you can then click on "Apply Update."  Remember this will reboot the RSA.

 

If you've been waiting for SSL, then you’ll find the ability to add certificates under Settings & Maintenance | Security.

 

If you want to explore the KACE Native Imaging Toolkit, check out those videos to get started and implement the limited feature on your system.

 

Are you running out of space on your K2000? Or afraid you will after implementing the KACE Native Imaging Toolkit? Then you’ll be interested in using our offboard storage feature in 3.4.  Review this knowledgebase article for additional information.

 

Want to add features to KBE? Or upload a custom boot environment, check out the KBE Manipulator add-on application and videos on how to use it.

 

Unfortunately, we did find a bug or two with the 3.4 update, but they are minor, dealing only with sysprepped image, and we have fixes that you can implement if needed.

  1. KCleanup does not run in a 3.4 Sysprepped image
  2. K2000_deployment_info.conf file is not copied in a sys prepped image

 

What else is new with 3.4? Here is a mini video tour demonstrating the tweaks that we made to the K2000.

Be the first to comment

Fix for slow network performance on K2000 RSA for version 3.4

Situation:

I deployed 4 RSA VM's across my multiple subnets, configured syncing, and started syncing my images. I noticed that a 7gb image took about 24 hours to sync and came to the realization that it's not, in fact, utilizing gigabit. I changed the network speed from auto-negotiated to 1000mbit full duplex and the device became totally unresponsive. I tried removing the RSA and creating another one with the same results. This is pretty hard to troubleshoot without real access to a command line, so I had to call KACE.

 

Problem identification:

I engaged the KACE support team and eventually determined that when you manually force the speed, it removes the IP address (verified via ifconfig). It would work properly after that point if you manually assigned an IP using ifconfig. The issue was taken to engineering and the determination was made that the current OVF downloaded with a k2000 running 3.4 has the vmware nic set to "Flexible" instead of the normal E1000.

 

The fix:

The fix was to remove the Flexible NIC and replace it with an e1000. After making the change (and the requisite reboot) the RSA booted in about 30% the previously required amount of time, and in Konfig reports the currently negotiated speed (i.e. Speed: Auto-negotiated (1000mbits full duplex)).

 

Our configuration:

HP C7000 blade enclosure, 8 of 16 blades installed, 10gig backplane. VMware ESXi 5, Veeam.

 

Feel free to post any questions and I'll answer as best I can.

View comments (3)

WIM Imaging with multiple RSAs using a single share

Just wanted to share this in case anyone else could benefit.  In our environment we use multiple RSAs, which allows technicians at each site to save their own images.  However, we want them all to use the same gold master WIM image as their starting point.  Since the K2 doesn't auto-sync WIMs yet, we had to copy this image file out to each RSA manually.  This image gets updated sometimes monthly, and it was getting very cumbersome to continue copying out.

We recently implemented this: http://www.itninja.com/blog/view/wim-storage-freeing-up-space-on-your-k2000-if-you-are-using-wim-s which I HIGHLY recommend.  It also gave me the idea that if we could set up offboard storage on a network share, then why couldn't we just store the gold master WIM image on a single share instead of copying it out everywhere?

The answer was very simple.  Create a preinstall task for that system image that deletes the T: mapping and redirects it to the share.  The blog post above shows you how to set up the entire KBE to do that with the KBE Manipulator, but we still wanted technicians to be mapped to their own RSA and network share for the other images they use.  So adding the redirect preinstall task to the gold master system image was the perfect solution.

You can see above that this is a BAT Script using simple "net use" commands.  There are just the two lines (the second line has a break due to length) that delete the T: mapping and then redirect it to the share.

I placed it first in my preinstall task list, however you could place it elsewhere in this section so long as it runs before the "applywim.vbs" script needs the T: mapping.

Now I only have to upload my WIM image to a single location, and everyone else is redirected to that location when they need it but not when they don't.  Even if the next K2 update syncs out WIM images, I may just continue to use this method.

View comments (3)

Optiplex 980 delay when PXE Booting

I have recently found that the Optiplex 980 with Bios A09 and A012 experience a extremely delay when PXE booting.  The delay was anywhere between 1-2 hours but it would eventually boot the KBE Main Menu. 

I believe there are other Bios versions effected due to my research on it from other users but for sure what I tested was A09 and A012.  

The newest revision of the BIOS A13 release Feb. 1, 2013 fixes this issue.

Flash the bios to A13 and this will fix the issue.

http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/optiplex-980?driverId=MMTX7&osCode=W764&fileId=3114093175

Also this link is to flash a bios without having the OS on it.

http://ubuntuforums.org/showthread.php?t=1901977

Be the first to comment
Showing 1 - 5 of 12 results

Top Contributors

Talk About Microsoft App-V