www.idmwizard.com

I’ve been working with VAS for quite a while, and have gone through all the versions since 2.6, and this has to be the biggest thing I’ve seen in over 4 years of working with the prodct. And the big thing is not VAS (or QAS, as its now known) itself, but a free add-on call Identity Manager for Unix (IMU). You can download your copy from here.

And the cool thing is that you can use the product without buying VAS.  What is it?  Its a free, web-based console for managing unix, linux and mac users & groups.  Obviously, if you buy VAS, you get a lot more functionality, but just the core functionality alone makes it a cool download.  If you have more than 2 unix boxes, this makes life a lot easier.  You can now assess all your *nix boxes, get a list of all your users and groups, and make changes right there, in a browser window.

And how do I know its cool?  Because I was on-site with a customer that had been evaluating VAS 3.5 for about a month, and they confirmed it.  They were going to have me go through and show them all the commands, tips & tricks and refresh them on all the things I’d shown them the month before.  Well, after installing IMU, and running through how it worked, they simply replied with “we got everything we need.  You answered all the questions we had with this console, and we feel pretty good that we can drive everything through this instead of the command line.” And that was the goal . . . make unix account management easy to drive from a single point, with no need to script or even log onto multiple boxes. Everything is dead easy . . . and did I mention its free?!?!?

I just wrote a very long email to a client describing how VSJ supports Federation and thought it would help those looking for a simple (albeit long) explanation of Federation. At some point, if I have some time, I’d love to put together some animations to show all this and cut down on the verbiage. But this is what you get in the meantime.  Its actually an email thread that I’ve purged of customer names and references. Enjoy.
—————-

From: Joe at Acme
Sent: Thursday, July 08, 2010 16:10
Subject: SSO for Java

Dmitry,

[...] sorry to be duplicating my questions but I lost my notes from our June 8 conversation.  As I read the SSO For Java specs, it describes an integration of JBoss and JAAS environments with AD content.  I don’t know the Java world that well any more, but will the java environments have the security context information that is supposedly in the Windows “Claims Aware Programming” environment for Windows developers?

Information like what LOA was used in authentication, what identity credential was used, what is the user’s rank that was passed in the identity federation profile, was the rank passed via an encrypted path, was the encryption network level or was it an end-to-end message-level approach, etc etc.

Thanks.
Joe

________________________________________
From: Dmitry Kagansky at Quest
Sent: Friday, July 09, 2010 12:00 AM
To: Joe at Acme
Subject: RE: SSO for Java

Joe,

Let’s do a quick summary, and also send you some additional information since our discussion.
1. VSJ has lots of flavours.  Of note:

* The ‘Standard Edition’ is the most common one, and is usable in all comercial app servers (WebLogic, WebSphere, Tomcat, JBoss, Oracle App Server, JRun, etc).  Its most common uses is as a servlet filter or as a JAAS authentication module.

* There is a ‘JBoss Edition’ which allows VSJ to be installed as a valve.  A valve is specific to Tomcat and JBoss, and if you have an app that requires a valve for authentication, then you’ll need to use this edition.  Otherwise, you can make use of the standard one.

* There are other editions that provide custom connectors for the specific platforms, just like the JBoss one.  For example, with the WebSphere edition, you can install VSJ as a TAI (Trusted Association Interceptor) and be able to consume LTPA (Lightweight Third Party Tokens) which are proprietary to Websphere.  Just like the JBoss edition, if you don’t need a TAI, then you can use the standard edition.

2. In all of the editions, except for the one below, a user comes in with Kerberos, NTLM or Basic Auth credentials (depending on the config), gets authenticated against Active Directory, and then has a Java Security Principal created within the application.  The authentication mechanism (servlet filter, valve, TAI) dictates which version you need to use.

3. Now, for the oddball, which is for Federation and claims. There is a ‘Federation Edition’ which ships with the Standard Edition, but is a separate set of jar files, and supports ADFS 1.0.  ADFS 1.0 is SAML (1.x) claims and tokens.  Should you want SAML 2.0 support, then MS provides a SAML 2.0 to 1.x adapter allowing you to use VSJ with your java apps to receive either SAML 1.x or 2.x tokens.  With SAML 1.x, your encryption is using SSL, and the schemes used are whatever you specify in securing the site with an SSL cert.  The web server is the one responsible for providing the security.

With SAML 2.x, the payload itself is encrypted before it is sent out.  It is still encrypted using a cert, and what type you select determines the encryption level which then allows you to send everything over port 80.  While the data may seem like its in the clear, because the encryption happens before the transmission starts, it is still jibberish going across the wire.

That should cover a good amount of the conversation we had last month.

Now, for some new information.  We have since released a version of Webthority, and that version supports using VSJ in both the front and back end.  What is Webthority?  It is a reverse proxy which can secure your applications but proxying the content, rewriting URLs and managing a session, as well as providing Single Sign On to numerous apps, using numerous authenticators.  What that means is that you can use it to log in with LDAP credentials, a smart card or certificate (PKI), a Kerberos ticket, a database login, or a SAML token, and establish a session across multiple applications through a common ‘gateway.’  Its a way to consolidate your URLs as well, where you can go from:

http://expenses.internal.acme.org

http://dev.acme.org

http://external.partner.gov/federate

to something like:

http://webapps.acme.org/expenses

http://webapps.acme.org/dev

http://webapps.acme.org/partner

You can consolidate those URLs, consolidate SSL certificates and use something called ‘protocol transition’ (which is built into VSJ) to go from one set of credentials to a set of Kerberos credentials.  This is all within Webthority, and can be used in conjunction with VSJ as well.

We have also made our own STS which not only provides SAML (Federation) support, but also supports something called ‘JIT Provisioning.’  The best thing to do is to check out these blog entries by the Product Manager for ActiveRoles Server where he describes this new functionality here:
http://www.bobbobel.com/just-in-time-access-provisioning/

I’m sure its all a lot to take in, so feel free to shoot back any questions you may have.

Dmitry

________________________________________
From: Joe at Acme
Sent: Friday, July 09, 2010 07:11
To: Dmitry Kagansky at Quest
Subject: RE: SSO for Java

Dmitry,
Thanks for the write-up.

I still am fixated on claims-aware programming.  It sounds like it is nothing more that providing a set of APIs for the application developer to use in making (access) decisions about a user?  Some of the claims will come to the application directly via a security token like SAML, and others are a part of the OS environment that one uses the APIs to get to?  If ADFS 2.0 is in use for abstracting the Identity Federation away from the app developer, I would think that the application would not see any SAML security tokens?

So then does the Java Security Principal (when VSJ is in use) provide all the claims a developer could want, including all the security context information?  No difference then between what a Windows developer (with ADFS 2.0 handling the Identity Federation for the enterprise) has access to and what a Linux Java developer has access to?

If XXXX is on a track for QAS with Oracle’s OIM suite (OAM, OIF, OES, OVD, etc), and if they are also a Windows AD shop with ADFS 2.0 also available, then maybe QAS + VSJ would make more sense than going the Webthority route?

Thanks.
Joe at Acme
________________________________________
From: Dmitry Kagansky at Quest
Sent: Friday, July 09, 2010 18:06
To: Joe at Acme
Subject: RE: SSO for Java

Here are the short answers, and you can read the write-up below for more details:
- With SAML, the operation is pretty binary.  Claims are put into a token, and the app can either access the claims or ignore them.  Its not flexible enough to make decisions like you describe.

- The app itself should not know or care about SAML; it is another abstraction, just like VSJ is a Kerberos “authenticator” that is put in front of the application.  Once the user gets past VSJ, it shouldn’t matter to the app how the user got there.

——
I actually think you’re expecting way more of claims than they really are.  You’re buying into ‘the dream’ and some of the ‘marketecture.’ And that’s not a bad thing, but lets look at what this means practically.

First, let’s level set, and define some terminology so we’re on the same page. What you have today is:
- Federation: This is an abstract term.  In my mind, this is just a way to separate management of resources from management of accounts that can access those resources.  In most cases, this comes as a result of two different organizations wanting to share resources, and allow accounts from one org to access resources from another org.  The caveat is that the org with the resources trusts (in some way) the account org, and accepts statements (or ‘claims’) made about a user by the account org.**

- SAML: This is a generic term that is used to describe anything from the notion of Federation down to the actual token sent during the authentication/authorization action.  It can be a protocol, a mark up language, the actual token, and a standard.  I get way too many questions about “do you support SAML?” which goes into a very long winded discussion.  So let’s discuss the key point, which is the protocol – there are 2 main flavours; 1.x and 2.x.  They are not complementary, and are competitive.  There are subtle differences in the syntax, but the big difference is what I outlined below. SAML 1.x is “in the clear” and its up to you (the sys admins/app managers) to secure it.  So you have to encrypt the channel, typically with SSL. SAML 2.x, on the other hand, encrypts the content –before– it is transmitted.  So even if the channel is wide open, and visible, everything is still jibberish and decrypted at the other end.***

- Certificates: These are used for all sorts of things, but in the context of this conversation, they are used to trust the organizations discussed above.  Obviously, there’s a public and private key set up, and the 2 orgs that are federating perform a key exchange at some point early on in the agreement.  This key exchange forms the Federation Trust between the two orgs, and validates a user from one org to the other.  So when you ask about encryption, the answer is almost always “whatever types of certificates you chose to use.”  There are some limitations, but most certs use standard encryption types.

So what does a Federated transaction actually look like?  Here’s a high level example.  Let’s pretend for a minute that Acme has some website called ‘partners.Acme.org’ and on that site, trusted partners can log in, and access information that Acme provides to their partners.  At the same time, Acme does not want to manage and maintain lists of users to access the site.  Job changes, turnover, and other factors lead to Acme telling their partners – “anyone that works for you that has a certain role (say, Marketing Manager) will be allowed into the site.  It is up to you, Mr Partner, to properly provision and deprovision your employees, and we trust anyone you send over that you claim to be a Marketing Manager.”

And now let’s say Quest is such a partner.  Because I work for Quest, I may (I stress –may–) have access to that site.  As long as I come from the Quest network (which can be confirmed by the certificates exchanged earlier) and the claim that Quest sends on my behalf reads ‘Dmitry Kagansky, Marketing Manager,’ I will be allowed into the site.  That’s all we’re really talking about here.  Quest makes some claims about me, and Acme trusts Quest’s claims.  If I leave, then Quest deletes my account, and I no longer have access to the Acme site.

That’s a high level overview.  Now, looking at what happens in a Java server, when someone authenticates, a “thing” (an object, a constructor, etc) gets created for the user called a Java Security Principal.  In that Principal are all sorts of information about the user that just logged in.  As you say, its the security context, and how it is generated should be irrelevant to the app developer.  And part of the information in the Principal is a list of all the roles the user has.  What VSJ provides is the ability to take the claims from someone’s SAML token during a Federated exchange, and put them into that list of roles.  So as a developer, you can now write code that says “if the user has a role of ‘Marketing Manager’ you are allowed to open this file.”  From an app standpoint, it should not care whether the person authenticated with a SAML token, a Kerberos ticket, or through carrier pigeon.  Somehow, the user got in, through a trusted access method, and they are here.  So you are right that the application should not know or care about the SAML token.  But the part about being able to ‘blend’ claims from the token versus the OS environment, that’s still a bit difficult and is not something that can be easily with SAML.

Which leads to what people want Federation to become.  There’s talk that SAML and claims are not enough, especially because the org with the resources wants to do more than just accept or reject claims. They want conditional things to happen.  They want ‘extensible APIs’ as you mention.  They want lots of things that are not yet part of SAML.  And if you search around, you’ll find something called XACML (eXtensible Access Control Markup Language) which, like SAML, is both a construct/token as well as a protocol and (sort of) an API.  Personally, what I see happening is that SAML will assume authentication responsibilities and XACML will take over the authorization duties but right now its a very, very hazy area.  SAML is here now, and ready for use (albeit somewhat limited) and XACML is still a few years off, but plenty of vendors are starting to support it and its starting to pick up some steam.

Finally, where does Webthority fit into all this?  Well, Webthority is a reverse proxy.  And it allows for multiple authentication sources.  And given that Federation is in such a state of flux, VSJ (with ADFS support) may not be enough to do it all.  You may still have cases where people need to log in using LDAP credentials.  Or they have a login in some database somewhere.  Webthority can provide SSO for those users, along with the Federated user.  And it actually provides a managable interface to control all these settings rather than writing lots of authentication code.

Whew – that’s quite a lot to take in on Friday.  Hopefully, this wasn’t too much for you, and it wasn’t too pedantic.  The short of it is that VSJ can provide the same SAML functionality for Java applications that Microsoft provides for their Windows apps.  And we do this using the same Microsoft plumbing, so there’s very little to add if you are already using ADFS (1.x or 2.x) and want the same functionality for your Java apps.  And, if you have (web) apps that you don’t want to overhaul, or that don’t use a Java Security Principal, Webthority may be a pretty good alternative as well.  Plus, VSJ can be used with Webthority so you can support the new (Federation, SAML, Kerberos) with the old (DB logins, LDAP, NTLM, etc).

——-
** Note that Federation often happens internal to an organization, and can be used just to segregate resource from user management.  It does not have to be 2 different orgs, but that is where the origins come from.

*** as an aside, when SAML 1.x came out, was adopted by Microsoft (and IBM to some degree) in ADFS 1.0.  SAML 2.0 was published a few years later, and was supported by the ‘anything but Microsoft’ crowd (The Liberty Alliance).  Since then, Microsoft has put out Geneva, which is their codename for ADFS 2.0, and now support both SAML 1.x and 2.x.

—
Dmitry

I was working with a client today that wants to rework what their URL looks like, and actually try to put in session data into it.  The reasons for this vary, and are irrelevant, but suffice to say this was a critical piece of functionality for their site.  Initially, I said “absolutely – Webthority can do this!” knowing that I’ve used Webthority’s URL rewriting capabilities in the past.

However, as we put everything into place, nothing happened.  And it turned out that the URL re-writing that they wanted (which is to put in the session id into the URL) wasn’t available until the user authenticated.  That sort of ‘URL mangling’ only happened when an authentication agent was used!  I’ve never used Webthority without one, which makes sense since it often used for Web SSO, and you always want to authenticate, right?

In any case, after a lot of stumbling and bumbling around, Paul H clued me into how the Custom Authentication Agent was used.  The documentation is pretty scant on it, so I created this 2.5 minute video outlining the changes I had to make in order to get the user to automatically authenticate and establish a session.

This is where I came up with the term ‘promiscuous authenticator.’  In a perfect world, this would be another option, just like LDAP or Database.  But for the time being, this will work.

http://www.idmwizard.com/quest/WebthorityCustomAuth/index.html

Hopefully, this will help others that are looking to configure Webthority’s Custom Authentication Agent.

I’ve now had a beta build of VAS 4.0 for a bit, and have finally gotten around to recording some videos featuring some of the new additions.  For core VAS functionality, this blog post here still has a lot of relevant videos.  None of that functionality is going away.  However, there are a lot of new things in 4.0, so here are some starter videos.  I’ll try to post some more, time permitting, but I’ve given up on Camtasia for Mac, so it may take a while.

As with the VAS 3.5 videos, there’s no audio, so you have to use your imagination.  And the second video is quite lengthy, even with some heavy editing to speed things up.  This is simply because the copies of the VAS binaries (all of them) to the server takes a bit of time.  Other than that second video, all the others are under 3.5 minutes.  Enjoy.

http://www.idmwizard.com/quest/vas/vas40-01-install-control-center/index.html
http://www.idmwizard.com/quest/vas/vas40-02-install-IMU/index.html
http://www.idmwizard.com/quest/vas/vas40-03-profile-host-using-IMU/index.html
http://www.idmwizard.com/quest/vas/vas40-04-preflight-host-using-IMU/index.html
http://www.idmwizard.com/quest/vas/vas40-05-install-qas40-via-IMU/index.html
http://www.idmwizard.com/quest/vas/vas40-06-map_local-user-to-AD-via-IMU/index.html

I posted the following in an entry quite some time ago, but thought it made sense to break out just the VAS ones into a separate post for easier searching.  And so I can reference it in the VAS 4.0 blog post I’m about to put up after this one.

All of the following videos are 1-3 minutes in length, with no audio.  They show some of the core VAS functionality which is found across the board on all operating systems supported by VAS:
http://www.idmwizard.com/quest/vas/vas35-01-preflight/index.html
http://www.idmwizard.com/quest/vas/vas35-02-install_and_join/index.html
http://www.idmwizard.com/quest/vas/vas35-03-installation_of_quest_ssh_and_getting_sso_through_it/index.html
http://www.idmwizard.com/quest/vas/vas35-04-unix_enable_user_and_group-password_change-sso_via_ssh/index.html
http://www.idmwizard.com/quest/vas/vas35-05-sudo_group_policy_usage_and_config/index.html
http://www.idmwizard.com/quest/vas/vas35-06-file_copy_policy_with_replacement_macro/index.html
http://www.idmwizard.com/quest/vas/vas35-07-access_controls_via_user_files/index.html
http://www.idmwizard.com/quest/vas/vas35-08-access_controls_via_windows_group_policy/index.html
http://www.idmwizard.com/quest/vas/vas35-09-self_enrollment-automatic_local_to_AD_mapping/index.html

If you happen to have NIS running in your environment, you’ll want to have a look at the next set of videos that target NIS maps, and how VAS brings them directly out of AD and onto your *nix hosts:

http://www.idmwizard.com/quest/vas/vas35-10-installing_vasyp_proxy-getting_yp_maps_from_AD/index.html
http://www.idmwizard.com/quest/vas/vas35-11-using_the_nis_editor/index.html
http://www.idmwizard.com/quest/vas/vas35-12-importing_a_new_nis_map_via_windows/index.html
http://www.idmwizard.com/quest/vas/vas35-13-importing_a_new_nis_map_via_unix_nisedit/index.html
http://www.idmwizard.com/quest/vas/vas35-14-importing_and_enabling_users_with_vastool_load/index.html

For a nice, complete 18 minute long NIS migration video (with audio!!!!) here is one that I recorded for a particular customer:
http://www.idmwizard.com/quest/vas_nis_migration/index.html

Here are some additional random VAS videos that I’ve recorded that are good to keep together.  People often have questions on what the VAS install looks like on the mac – here are 2 videos of that:
http://www.idmwizard.com/quest/vas35_mac_install/index.html
http://www.idmwizard.com/quest/vas35_mac_install_manual/index.html

Lastly, here is VAS’ self-enrollment feature on Solaris 10:
http://www.idmwizard.com/quest/Sol10-VASSelfEnrollment/Sol10-VASSelfEnrollment.html

In ARS 6.5, we really beefed up the end-user self-service functionality. It is really, really slick, and people that see it really like what it offers their end users. I’ve made numerous recordings of it, but none really come out to a satisfactory result. And it has nothing to do with our product.

This is because I’ve been struggling with converting from Camtasia for Windows to Camtasia for Mac. The two products are miles apart, and its the last bit of my ‘toolkit’ that I need to re-learn on the Mac. And, of course, the 2 products do not even produce videos in the same format, so I’ve had to re-record everything, and learn all the new controls.

With all of that, if the video is not to your liking, there’s not much I can do right now. It’s late, and I have a deadline, so here is a 6+ minute video of the Self Service Manager functionality (note that there is no audio but some text I’ve put in to highlight what is happen whilst I re-learn Camtasia):

http://www.idmwizard.com/quest/ARS65SelfServiceManager/index.html

As always, comments and feedback is always appreciated.

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

I got a call yesterday from a colleague looking for help in importing a text file. For those that don’t know, I do quite a bit of work with a Quest product called ActiveRoles Server, and an add-on called Quick Connect. Quick Connect (QC from now on) is pretty slick, and has come a long way in the last 2 years. However, it can’t do everything quite yet.

The file that was to be imported was a fixed width file, meaning every line was the same width, as was every field. Which meant fields were padded with spaces. Unfortunately, QC cannot import those files out of the box today.

The initial thought was to write a pre-sync script that would alter the file and have it put the file into a usable format. However, that’s a lot of work, and a lot of scripting. And with someone on-site, may take a while with the added pressure.

So I made the following suggestion (note: SSIS is SQL Server Integration Services – the successor to SQL Server Data Transformation Services):
———————-
SSIS lets you take delimited or fixed width files and do whatever you want to them. I suggest you watch this:
http://www.idmwizard.com/quest/SSIS-CSVExport/index.html

Then create a package to do what you want (all wizard and gui driven – very easy). Once the package is created, and executing properly, take a look at the following command line command:
DTSRun

This will let you execute the package, which you can use in a pre-sync step. Also, SSIS can do any format to any format – you don’t have to have SQL Server (or any DB) as either end point. So you could actually use this to convert a fixed width (or ragged right) file to a CSV file that QC can consume.
——————————

Why do I think this is a better solution over a pre-sync step? Well, there are several of reasons, and some may disagree, but I’ll put them out there anyway:

1. Maintaining scripts is a pain – that pre-sync step will need someone “script-capable” to alter it when the file format changes (and it will – it always does)
2. GUIs are easier – the script is just that, while SSIS provides a nice GUI package editor – it’s simply a better tool and is less prone to allowing mistakes
3. Debugging – QC doesn’t have any debugger in it – so you try the job, and it fails, and you re-code. With SSIS, you get debugging, and you can isolate the transformation so you don’t have to run the whole QC job just to see if the file is being built correctly
4. SQL Server infrastructure – using a package around the transformation lets you add many, many other things to it – notifications, other data sources, and other options – you basically have all of SQL Server at your disposal. And the coolest feature is DTSRun which is a command line tool to run the package unattended. I’m all about the command line when possible.
5. Finally – Speed – I’ve found that DTS (now SSIS) is super fast. Its sole lot in life is moving data around. And while QC is quick, too, the SQL Server team has been working on SSIS for years, and is all about ‘speeds and feeds.’ In the past, I’ve had DTS packages that would process over 50 million rows of data – that is some serious data movement, and given that the file needs to get run twice (once to transform and once to load through QC), you might as well cut time down anywhere you can

So there you have it. Will Quick Connect have this functionality in the future? I can’t say for sure, but we’ve got a bunch of smart people working on the product. Why do we not have it already? We can put every conceivable feature into the product, but then we’d never ship it. What do you need to do to get it? Well, you need to let someone know. This is the first time I’ve encountered a fixed width file in 2 years. If its rare, then it will go to the bottom of the feature list. But if lots of people request it, it will rise to the top. And how do you let someone know? You contact someone at Quest (myself, the Product Manager, your sales rep, or even support) and ask for an enhancement request. Its that simple – and it all gets back to our PM who tracks this stuff.

Enjoy the video, and let me know if it helps.

Cheers,

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>