Right on the heels of my last post (here, on a sister site) about the various smart cards, I get an email today that includes the following:

“CAC and Defender are both two factor authentication methods. They can be combined to give you three factor but I haven’t seen anyone do that. CAC uses the DoD PKI structure and Defender uses RADIUS to AD”

So I had to reply with the following:

QAS supports smartcards (and has for years now, including CAC) but doesn’t use Defender for this. Let’s back up and answer exactly what QAS and Defender do.

QAS provides AD integration to Unix/Linux/Mac systems. Defender provides RADIUS authentication using AD as it’s directory. Smartcards (like CAC and PIV) use PKI, not RADIUS, to authenticate the user.

The only time Defender gets involved with smartcards is if the card has a token (not a certificate) on it, in which case, it then provides authentication using that token. There are cards out there that are hybrids, and allow for both tokens and certificates. In that case, Defender only uses the token portion and ignores the certificates.

Now, if someone wants CAC support for QAS, you need to look for the QAS smartcard module, and the related license. To install it, the QAS ISO has a smart card install & admin guide, and you would look for the vassc package to deploy to your particular system. We currently support Red Hat (Linux), Solaris and Mac with the smart card modules.

The other thing that needs to be noted is that nothing that Quest provides can accommodate 3 factor authentication. At least, not on it’s own. As a quick review, the 3 factors to authenticate are:

• Something you know (password, key phrase, hint, account number, username, etc)
• Something you have (a key, a token, a certificate, etc)
• Something you are (biometrics – fingerprint, retinal scan, voice print, etc)

Having multiple instances in the same category (a username, a password, and an account number, for example), does not constitute multiple factors. Now, QAS, Defender, ESSO and other Quest products can all co-exist with other authentication systems, but out of the box, you can get 2-factor authentication from us in a variety of ways, not three.

(edited 2011-11-09 to include link to federalcto.com post referenced in the first sentence)

It’s evident throughout history – inside jobs. Aside from nuclear war and weapons of mass destruction, cyber attacks pose the single greatest threat to US security – and they are growing more and more difficult to prevent. One clear indicator of the threat is the sheer volume of breaches. Cyber attacks on federal computer systems have increased more than 250% over the last two years, according to the Homeland Security Department. Federal computing resources are under constant threats — not only from the outside, but also from trusted partners and internal users. Cyber attacks are a clear and present danger and the potential for both accidental and deliberate breaches of sensitive information is a growing concern. Innocent but careless employee actions can set the table for attacks by more malicious parties. In many cases, the threats are inadvertent, with users unwittingly introducing harmful viruses to your agency or allowing sensitive data to be leaked.  But whether or not there’s malice, the damage from breaches can be great.

Join me for a discussion on Monday, March 29 @ 1:30 pm ET on ways to protect your environment from the inside threat.  We’ll talk about how you can not only improve your security posture, but also meet regulatory and statutory guidelines during audits and reviews.  Plus, you’ll also learn about forensics and tools you’ll need when a breach does occur to minimize the losses and downtime.

You can register here. I’m looking forward to hearty discussion.

I recently got asked to show how someone could use Quest’s ActiveRole Server to temporarily grant access to a CD drive, or USB storage device to a select set of users.  I knew it could be done, and didn’t think it would take too long to demonstrate.  However, I’m now on my 3rd day of devoting some time to this, and it’s turning out to be a tad bit more difficult than I thought.  The problems are mostly with the logistics, and configurations, as you’ll see if you continue reading.

The first problem was that I was using VMs (virtual machines), and the USB and CD-ROM are virtualized.  That made me nervous about making sure that it will actually work ‘as advertised.’ So I went and got a Windows 7 laptop, joined to my lab domain, to convince myself that what I was doing would work in the ‘real world’ since we’re talking about desktops here.  The short version – it does, indeed, work in both cases.

After that, I had to find the specific setting.  It turns out there is a lot of information out there, including a few KBs from Microsoft themselves, but nothing really summarizing all the gotchas.  So here is my list, assuming this is all done with native tools and without a COTS (Commercial Off-The-Shelf) product:

1. The only reliable way to block the CD-ROM or USB drive on a large number of machines is through an ADM template that disables access by the system itself to a critical driver.
2. That access will be blocked for all users on the machine; there is no way to fine grainly select which users can use which devices on a given machine.  The GPO is applied to the computer object, not the user object.
3. The ADM template uses double-negatives.  You ‘Enable’ the ability to set the setting and then set it to ‘Disabled’ to turn off the specific drive.  I’ll explain with a short video below.
4. The ADM template will ‘tattoo’ the machines it is applied to. Tattoos are permanent and so is this setting.  Which means that the setting will persist on the machine, even if the GPO is removed/deleted.  It also means that if you apply a setting, you will have to apply another GPO to explicitly reverse the setting.  You’ll see this mentioned by Microsoft as a ‘preference’ rather a policy in their link below.
5. For those of you that do not know, GPOs are not instantaneous.  You do not edit a setting, run to a machine, and see the results right away.  Machines actually PULL settings down, and Active Directory DOES NOT push them by default.  This can be overcome, of course, but the default behaviour is the pull.
6. Because of the pull, and several other factors, it can take minutes and possibly hours to get a setting to a machine.  In the case of hours, it may be that you have to wait for replication to occur from the server where the GPO was edited to the server (domain controller) that your computer is working with.

With all those constraints, I set out to put together the recordings below showing how it can be done.  So what I ultimately have is a group where a machine is added and removed as needed to have these settings applied.  Again, the settings, once applied, cannot be removed, but can be toggled from ‘enabled’ to ‘disabled’ and vice versa.

I got my adm template together, and went ahead and imported it in.  The template I used can be downloaded here (http://www.idmwizard.com/quest/wb/block_drives.zip).  However, after I imported, I found I couldn’t edit it in GPO Editor.  Specifically, I couldn’t see the settings I needed to edit. So with some more searching, I discovering that I had to disable some filters in the view.  Here is a video where I do all this, starting with the text of the ADM copied and pasted into Wordpad:

http://www.idmwizard.com/quest/wb/add_adm.mp4

Next, I actually looked at how computers could be added to groups in 2 different ways.  The easiest way is through regular group membership.  So in this video, I will simply show a computer getting added and removed from a group.  The difference from native tools is where ActiveRoles Server comes in.  You will see in the video that I can select a machine to be added temporarily.  I can set the addition, and the removal into the future, allowing me to only have the membership be active for a limited amount of time:

http://www.idmwizard.com/quest/wb/temp_group_membership.mp4

Another option, though, is through a dynamic group.  Dynamic groups are also an ARS feature which allows you to construct a query-based group.  The cool thing in this next video is that I also use a Virtual Attribute.  That is, I create a flag for the policy to be applied to the Computer object class, but there is no schema extension involved.  ARS keep the attribute tied to the AD object internally, and allows you to work with it as if it were any other property of the particular class.  This is cool because you can have someone toggle this setting to put the machine in as needed:

http://www.idmwizard.com/quest/wb/dynamic_group_membership_with_VA.mp4

Having shown all this, I still need to point out that a CD-Burner or a USB device is not the only way to get data out of a building.  Most desktops still have a floppy drive (which is also covered by the policy), a printer (local or networked) and some additional ports in the back.  That parallel port can still take some older devices, such as those Iomega Jazz and Zip drives I used back in the day to make backups.  And then you have all sorts of other devices, like smartphones, that may use different drivers, as well as have cameras built into them to take ‘screen shots’ if push comes to shove.  If you know the driver to target, you can always disable it, but it feels like an arms race, to some degree.

After all of this, I’d probably suggest that you just look at something like ScriptLogic’s Desktop Authority for doing this (full disclosure – ScriptLogic is owned by Quest Software).  That tool may seem like overkill for this sort of task, but with all of the hoops one has to jump through to make it happen, it’s much simpler to use a COTS product, and get onto other things.  It won’t cover the ‘someone taking a picture of the monitor’ scenario’ but it holds up much better than my demonstration which was quite cumbersome to work out and deploy.  Plus, it will let you roll things out closer to ‘real time’ rather than waiting for group policies to be replicated and applied.

As for a list of references, there are a number that I could list, but this page was the most useful, not just for the article but for the comments as well: http://oreilly.com/pub/a/windows/2005/11/15/disabling-usb-storage-with-group-policy.html

The MS KB article that everyone references can be found here: http://support.microsoft.com/kb/555324 and this is where I got my ADM template.

As a follow-up to the last post, here is the full text of the session for another imported fusion disk.  I actually imported the whole thing using the datastore browser within vSphere, and then got rid of the Applications and appCacheList folders that Fusion creates.  Once the import was done, I logged into the ESXi host using SSH, and here is what I did.

login as: root
root@twesx01's password:
You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.
VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.
Tech Support Mode may be disabled by an administrative user.
Please consult the ESXi Configuration Guide for additional
important information.

~ # cd /vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # ls -al
drwxr-xr-x    1 root     root               2800 Dec 30 14:18 .
drwxr-xr-t    1 root     root               1680 Dec 30 07:38 ..
-rw-------    1 root     root         1625423872 Dec 30 07:51 dc04-s001.vmdk
-rw-------    1 root     root          862584832 Dec 30 07:58 dc04-s002.vmdk
-rw-------    1 root     root             327680 Dec 30 07:58 dc04-s003.vmdk
-rw-------    1 root     root         2144010240 Dec 30 08:15 dc04-s004.vmdk
-rw-------    1 root     root         1950875648 Dec 30 08:30 dc04-s005.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s006.vmdk
-rw-------    1 root     root            1048576 Dec 30 08:30 dc04-s007.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s008.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s009.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s010.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s011.vmdk
-rw-------    1 root     root             327680 Dec 30 08:30 dc04-s012.vmdk
-rw-------    1 root     root             131072 Dec 30 08:30 dc04-s013.vmdk
-rw-------    1 root     root               8684 Dec 30 08:30 dc04.nvram
-rw-------    1 root     root                956 Dec 30 08:30 dc04.vmdk
-rw-------    1 root     root                  0 Dec 30 08:30 dc04.vmsd
-rw-------    1 root     root               2585 Dec 30 08:30 dc04.vmx
-rw-------    1 root     root               1623 Dec 30 08:31 dc04.vmxf

/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # vmkfstools -i dc04.vmdk -d zeroedthick dc04-1.vmdk
Destination disk format: VMFS zeroedthick
Cloning disk 'dc04.vmdk'...
Clone: 100% done.

/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # rm dc04-s0*
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # rm dc04.vmdk
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # mv dc04-1-flat.vmdk dc04-flat.vmdk
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # mv dc04-1.vmdk dc04.vmdk
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # vi dc04.vmx

During the vi session, I edit the one line that reads:

 RW 50331648 VMFS "dc04-1-flat.vmdk"

to:

 RW 50331648 VMFS "dc04-flat.vmdk"

After all that, here is the end result:

/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 # ls -al
drwxr-xr-x    1 root     root               1120 Dec 30 14:34 .
drwxr-xr-t    1 root     root               1820 Dec 30 14:22 ..
-rw-------    1 root     root        25769803776 Dec 30 14:32 dc04-flat.vmdk
-rw-------    1 root     root               8684 Dec 30 08:30 dc04.nvram
-rw-------    1 root     root                518 Dec 30 14:35 dc04.vmdk
-rw-------    1 root     root                  0 Dec 30 08:30 dc04.vmsd
-rw-------    1 root     root               2585 Dec 30 08:30 dc04.vmx
-rw-------    1 root     root               1623 Dec 30 08:31 dc04.vmxf
/vmfs/volumes/4d1b685e-858363b3-5fba-0026b9799581/twdc04 #

That is it.  dc04.vmdk is now ready for use by ESXi as part of a new VM.  Hopefully, this is of some help to someone out there.

After a few fits and starts, I decided I needed a bona fide server to do everything I’ve been wanting to do with virtualization.  On Christmas day, I found a good ‘scratch and dent’ deal on a Dell T105 in their Outlet store.  And then . . . I waited.

Until today.  The server arrived, and I got right to work (whilst also doing some work with our latest acquisition, QCAP which is very slick, and can be found here: http://www.quest.com/cloudautomation/ ).  Initially, I thought I was going to use VMware ESX 3.5, but after some consideration, and the fact that I had 64-bit hardware, I opted for ESXi 4.0.  Which mean I had to build another USB boot drive, as I decided to use the internal USB adapter and dedicate the 2 SATA drives to being VM stores.

Up until now, I’ve actually been running 3 AD domain controllers at home, 2 of which were actually running on Macs using Fusion.  The third, which ran on a Windows XP laptop, was extremely quirky, and seemed to fall off the network quite a bit.  And this seemed to be the result of VMware’s bridged network settings within Workstation and Player.

After about an hour of configuring the hypervisor, configuring the AD integration, and getting comfortable with the environment, I decided to shut down DC02, and bring it over onto the server.  DC01 is my main server, and that was going to stay up and running for at least a few more days until I was sure this cutover was feasible, but DC02 and DC03 were fair game.  Surprisingly, the 6 GB disk took quite a while to bring over, even on a switched, and fairly idle network.  So after about 45 minutes, I was able to get started, and turn on the VM.  At which point, I got the following error:

Module DevicePowerOn power on failed.
Unable to create virtual SCSI device for scsi0:0, '/vmfs/volumes/<long GUID>/dc02/dc02.vmdk'
Failed to open disk scsi0:0: Unsupported or invalid disk type 7. Make sure that the disk has been imported.

With a few quick Google searches, I found that because I had the disk set for a total of 24 GB, but only used 6 GB, ESX did not like this.  There were quite a few posts on the topic, but this one was the most clear, and gave me exactly what I needed: http://blog.learnadmin.com/2010/09/solution-vmware-vm-import-failed-to.html .  Until I found this article, I knew I had to import the VM using the “zeroedthick” argument for the “vmkfstools” command but that seemed like a lot of work, and I didn’t see the setting in the import UI.  Thankfully, the article above let me know that I could SSH into the box (yes, I set it up for remote Tech Support), and run the following commands:

cd /vmfs/volumes/<long GUID>/dc02/
vmfstools -i dc02.vmdk -d zeroedthick dc02-1.vmdk
rm dc02-s*
rm dc02.vmdk
mv dc02-1-flat.vmdk dc02-flat.vmdk
mv dc02-1.vmdk dc02.vmdk
vi dc02.vmdk

I actually had to edit the dc02.vmdk file because of the line that reads ‘mv dc02-1-flat.vmdk dc02-flat.vmdk’.  I wanted to get rid of the -1 entry in the new file names.  There were a few other quirks during the ‘New VM’ dialog, such as the new VM had to have the same name as the old VM, but I got past it, and got everything set up.  One other thing I learned – don’t change the SCSI controller to the SAS one, but stay with the LSI Parallel one. I was hoping to use the ‘latest and greatest’ and got into a blue screen reboot.  After all this, the VM seems to have come up, and is running.  It now has a new NIC (ESX didn’t like the MAC address I originally created so I had to add a new card) and I’m going to wait it out a day or two before I do any more.

Feel free to drop me a line if you have questions, or have other suggestions.  I’ll keep updating this as I make progress in the conversion to using ESXi.