The Decision to migrate has been made. Now What!?!

Oct. 12th 2015

You’re the IT guy and the company has been bought, changed names, or your just simply cleaning up old Ailing domain that should have gone years ago. There are a few things you need to do before seeking out quotes for software and beginning your Active Directory Migration. A few questions to ask:

  • How many users will be migrated?
  • How many mailboxes will be migrated?
    • How much Email Data do you have?
  • How many Domains will be migrated?
  • What time frame you want to complete?

You now have your Software now what do we need to know before we start migrating.

  • What Applications talk to AD and how?
    • Are they LDAP?
    • Can they be configured with multiple domains?
    • Contacting the Vendor sometimes will help with these questions.
  • Do you have a List?
    • Users
    • Groups
    • Computers
    • Users to Computers they use
    • Users to Shared Mailboxes they use

Having these things ahead of time will help you and your consultant move forward faster and more efficient.

Posted by bc-admin | in Migration Manager for Active Directory | Comments Off on The Decision to migrate has been made. Now What!?!

Performing an Intra-Forest migration

Oct. 8th 2015

Performing an Intra-Forest migration is different in many aspects than performing an Inter-Forest migrations. The biggest issue that needs to be watched out for is not having two same accounts with same SIDS in both domains. That is why as soon as possible after migrating the objects they need to be deleted from the source domain. This make having a tested backup extremely important in case there is a need to back out the migration. Careful planning needs to be done when performing an Intra-Forest migration. Below are high level steps to help insure that the migration goes smoothly.

  1. Upgrade source Global groups to Universal
  2. Physically migrate all groups to target Domain.
    1. Migrate groups with Sid History and adding source members.
    2. Delete source groups
    3. Change admin point to target for all groups.
    4. Resource Process workgroup data (i.e., file servers, etc.)
    5. Execute ADPW in all domains to update group membership of Source users
    6. Optional but recommended:  Clean up sidHistory on migrated groups.
  3. Create user “stubs” in target. (i.e., Logically Migrate)
    1. Migrate user accounts, skipping sAMAccountName (migration session)
    2. DO NOT copy SID History, Password, Security Descriptor, and Mailbox.
    3. DO NOT Enable user account
  4. Resource process and move all workstations. (delete the source computer accounts during the physical migration – if QMM Directory Sync is running, be sure NOT to sync deletions)
    1. Exclude serviceprincipalname attribute from computer objects
  5. Resource process servers for ACL only
  6. Migrate users (Physical Migration)
    1. Verify RMAD session ran recently (in case of an object restore requirement)
    2. Migrate selected users with Password, SID History, Mailbox, and sAMAccountName
    3. Run ADPW with custom map to update TARGET ‘Update Group Membership”. Verify migration
    4. If SQL servers present, SQL Wizard run with custom map
    5. Delete source users
  7. Migrate Servers (physical migration)
    1. Resource Process (do not double acl, replace the acl).
    2. Join to target domain
  8. Clean-up
    1. If MS SQL present, re-run SQL Wizard with all objects.
    2. Re-run ADPW, clean up legacy memberships.
    3. Verify RMAD run and user ADPW to cleanup SID History.
    4. Remove source domain.

Note that you may choose to “loop” on step three for sets of users at a time.  You may also choose to loop on step 2 for sets of groups at a time

Posted by bc-admin | in Migration Manager for Active Directory, Migration Manager for Exchange | Comments Off on Performing an Intra-Forest migration

Enabling Active Directory User Authentication in TPAM

Nov. 14th 2013


The TPAM appliance can utilize External Authentication Sources to permit user access to the TPAM interface for management of the appliance, as an auditor, or just as a normal user wanting to request a password or session from the system.  This article will be focused on allowing users within TPAM to access the appliance with their Active Directory credentials.

First we need to gather some information about the environment and the user(s) that need to authenticate using AD credentials.

For my test lab, below are the requirements:

Domain Name(FQDN): target.local

User Information:

First Name: John

Last Name: Smith

LoginID (sAMAccountName): JSMITH


1)      Log into your appliances’ /admin interface with an administrator user (default is parmaster)

2)      Move the mouse to System Status/Setting, move down to External Authentication, then click on WinAD. (The TPAM interface does not require clicking on each option, these are mouse-over activated menus, and only the final option requires a mouse click)


3)      Within the WinAD Window, Click New System

4)      Enter the System Name, this is a TPAM only reference name and can be anything you want.

5)      Enter Server Address, this can be an IP, a DC FQDN, or preferably, if DNS is working properly, the FQDN of the AD Domain Name.

6)      (Optional) Change the Timeout, the default is 4 hours, maximum is 8 hours.

7)      Click Save Changes and your newly configured System Name appears in the Configured Systems.


At this point, TPAM has a configured external system to authenticate against, but the user account within TPAM must be configured to utilize this External Authentication source.  For this example, I will add a new user to TPAM and configure the user to login with its AD credentials.

8)      Login to your appliances’ /tpam interface with an administrator user (default is paradmin)

9)      Move the mouse to Users & Groups, move to UserIDs, and click on Add UserID.

(The TPAM interface does not require clicking on each option, these are mouse-over activated menus, and only the final option requires a mouse click)







2)      Once in the New UserID windows, you will notice a multitude of fields available.  Note the fields with a red asterisk (*).  These fields are mandatory when creating a user within TPAM.



3)      Fill in the User Name field, this is the TPAM User Name and does not necessarily need to be the same as the AD login id, but to cut down on confusion, it is recommended to make them the same.

4)      Fill in the users first and last name in the fields provided.

5)      Fill in any other fields desired, but are not required.

6)      Select the User Type.  The default is Basic and this is what the majority of TPAM users should be configured as.  This selector is where you can define a user as an Auditor, Administrator, etc..

7)      At the bottom of the page is where we define how this user will authenticate to TPAM.  The default is for any new user to authenticate locally to TPAM, and that is what the password fields are for.  If you enter and confirm the password in these boxes, and save the user, this user will authenticate locally to the TPAM appliance.

8)      The User Authentication section right below the Password is how you define this user to utilize the External Authentication we created earlier.

9)      On the Primary, Click on the drop down next to Local. Select WinAD.  When this is done, notice the Select a System drop down enables and the password and confirm boxes go away.

10)   Click the drop down for Select a system, and select the External Authentication that was defined earlier.

11)   In the UserID box, enter the users AD sAMAccountName or UPN (if desired).

12)   Your new user window should look similar to the image below.  Click Save Changes.



Now you have an External Authentication source and a new user configured to utilize that source.  Now we just need to test it.

1)      Log Out of TPAM and close all browser windows

2)      Launch your browser and open the /tpam interface and Login with your new user.

3)      If everything was configured properly and Active Directory is reachable, then your new user will receive the TPAM page below: (Note the user ID in the upper right corner)


Notice that this window is pretty sparse, since this was a new user created only for demoing External Authentication, it has no access to anything else in the system, but that is for another day.


Author: Russ Burden LeadThem Security Architect







Posted by bc-admin | in TPAM | Comments Off on Enabling Active Directory User Authentication in TPAM

Join a *Nix host to Active Directory without utilizing a clear text password

Aug. 21st 2013


Within QAS, the vastool command on *nix hosts is like the Swiss Army Knife of the QAS product.  This command allows an admin to verify authentication, list the QAS cache on that host, verify and remove Kerberos tickets, and join the host to an Active Directory domain just to name a few.  Today, I am going to discuss the join command, more specifically joining a host to Active Directory without using a plain text password.

Most customers wish to automate the process of joining a *nix host to Active Directory by a standalone script, or incorporating code into their kick start/jumpstart provisioning.  This can be accomplished, but the join command requires authentication to Active Directory with an account that possesses the necessary permissions to join a computer to Active Directory.  The most direct way to issue this command is:

Vastool –u –w <password> join


The command above will join the current host to utilizing the Active Directory credentials for  The issue most customers have with this is that the password is clear text and would appear as clear text within their script.  The way around this is to create a ‘service’ account that has the necessary permissions to join a computer to active directory, and generate a key tab for this user.  This key tab can then be placed with the kick start files and referenced in the join command instead of passing a clear text password, as below:

Vastool –u –k /etc/opt/quest/vas/sa.keytab join


The command above is the same as before, but now the vastool command is utilizing the key tab to perform the authentication rather than having a clear text password present.

In order to use this method, you will need to create a service account.  This account should be similar to most Windows service accounts in that, it does not force password expiration.  The msDS-KeyVersionNumber will need to be recorded for use in the generation commands of the account, this can be acquired by issuing the following from a QAS connected *nix host:

Vastool –u host/ attrs <ServiceAccountID> msDS-KeyVersionNumber


Once the key version is acquired, use the following commands to create a key tab for the service account:

Ktutil –k <Path>/<ServiceAccount>.keytab add –p <AccountUPN> -e arcfour-hmac-md5 –V <KeyVersionNumber> -w ‘password’
Ktutil –k <Path>/<SarviceAccount>.keytab add –p <AccountUPN> -e aes256-cts-hmac-sha1-96 –V <KeyVersionNumber> -w ‘password’
Ktutil –k <Path>/<ServiceAccount>.keytab add –p <AccountUPN> -e aes128-cts-hmac-sha1-96 –V <KeyVersionNumber> -w ‘password’


Make sure to include the single quotes around the password at the end to mitigate any issues with miss-interpreting special characters that may exist in the password.

Once the key tab has been completed, it can be placed with the provisioning files and referenced for vastool commands.



Author: Russ Burden, Technical Architect, LeadThem Security





Posted by bc-admin | in Authentication Services | Comments Off on Join a *Nix host to Active Directory without utilizing a clear text password