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)

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.

Some time in Q3 of last year, Stu Harrison (the PM for Defender) got me a beta copy of the latest version of Defender, which was due to have GridSure in it.  Of course, I took the time to record a quick demo of it, but then Stu asked me to delay releasing it.  One thing led to another, and I never got to posting the demo up here.  Today, however, while going through Defender with another architect, I remembered that I had this recording.

Before I go any further, you may be asking, “what is GridSure?”  It is another type of token that is available with Defender, and you can see a 3 minute marketing demo of it in the next URL.  This recording does a good job of explaining how it is used by the end user:

http://www.quest.com/defender/DefenderGrIDsureWeb/DefenderGrIDsureWebVideo.html

Whilst the demo above gives you a good idea of what the end user will see, I recorded a demo showing how to configure the token, and policy and what the user does to register.  In addition, I show the standard Defender desktop token being used with the ISAPI filter at the very beginning of the video.  I’ll apologize now for the microphone settings, and without further ado, here’s the 3 minute, 20 second video:

http://www.idmwizard.com/quest/Defender-GridSure/Defender-GridSure.html

Regards,
Dmitry

With the release of VAS 3.5 last year, there’s been a marked increase in Mac interest and activity for me.  One thing I had to do whilst on-site with an Italian client was give them a way to deploy VAS to 300+ Macs without visiting each machine.  Basically, they needed a scripted way to install an mpkg or dmg file onto the Mac.  In the unix and linux world, this is pretty common.  All of the major vendors have clear documentation on how to do this.

However, Apple’s approach is always through the GUI.  And finding an example on how to do this from the command line took quite some time.  So to save someone the trouble in the future, here is the script I sent over to the client.  Since writing it in March, I’ve had at least a half dozen requests for it inside of Quest, so it made sense to put this out there publicly.  And while this one is specific to VAS (extra bonus if you’re running VAS on Mac), it should work for most Mac packages, and should only require a minor tweaking.

Note: the only requirement is that some sort of remote login option be available – there’s simply no point to using this script if you’re going to sit in front of a Mac inside the terminal window.  The way to do this is to enable ‘Remote Login,’ which is off by default, and that will enable ssh on the mac so you can connect to it with something like Putty.

As an added bonus, here’s a 6 minute video showing this being done: http://www.idmwizard.com/quest/vas35_mac_install_manual/index.html

########################################################################
# install the mac client using the command line
# first, mount the dmg file
hdiutil attach /<somelocation>/VAS-3.5.0.33.dmg

# that should create a new volume which we can cd to
cd /Volumes/VAS-Installer 

# this is the actual install of VAS onto the machine
sudo /usr/sbin/installer -pkg VAS.mpkg/ -target / 

# install is done, so we can now unmount the dmg - change directories first, though!
cd /opt/quest/bin
hdiutil detach /Volumes/VAS-Installer 

# join the machine to the AD domain
# sudo /opt/quest/bin/vastool -u <aduser> join -c "ou=apple,ou=xxx,ou=yyyy,dc=root,dc=dom" root.dom 

# better yet, join the machine with a pre-created account
# HOST=`hostname | awk -F. '{print $1}'`; /opt/quest/bin/vastool -u host/ -w $HOST join -f -n ${HOST}.root.dom root.dom

# update DNS record in AD (DDNS is in the VAS package install)
# but if your mac is not using dhcp, I don't think this is run
sudo /opt/quest/sbin/dnsupdate <IP> 

# since macs are 'personal'
# there's usually 1 user on the machine - and you probably already have
# 1 AD user ready to use
# so copy the default user to the new AD user
# (this may take some time depending on the folder size)
sudo cp -R /Users/<localuser> /Users/<ADUser>

# reown all the files to the AD users (<ADGroup> can also be a local group)
sudo chown -R <ADUser>:<ADGroup> /Users/<ADUser> 

# later, when everyone is happy, and it is all working, run this to get rid of the local user profile
sudo rm -rf /Users/<localuser>