Archive for the 'Authentication Services' Category

Issue: Citrix/Roaming profiles are not used after RUM processing

Oct. 11th 2017

Description

Steps to recreate the problem:

  1. Citrix roaming profiles are in use.
  2. Roaming profile folders naming standard is “username.sourcedomain.v2”.
  3. Process profiles folder with a RUM processing task to add target permissions.
  4. When the migrated user logs onto the target domain a new roaming profile folder is created. This is not the expected behavior, the new profile name is in the format “username.targetdomain.v2”
  5. The target account does not use the processed roaming profile.

Resolution

The group policy setting that determines the location of the roaming profile folder needs to be changed:

  • Original configuration – with this group policy setting the roaming profile folder names are in the format username.domain.v2.
    • Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Session Host/Profiles
      • Set path for Remote Desktop Services Roaming User – Enabled
        • Profile Path – specify the path in the form \\Computername\Sharename
  • Updated configuration – with this group policy setting the roaming profile folder names are in the format username.v2.
    • Computer Configuration/Administrative Templates/System/User Profiles
      • Set Roaming profile path for all users logging onto this computer
        • \\Computername\Sharename\%USERNAME%
      • Copy all user profiles and permissions to the user profiles folder with the name username.v2 (removing the domain name).
      • Update group policy to use the %USERNAME% variable. Remove the original configuration from the GPO
      • Process the roaming profile and logon using the target account.  Using the new GPO setting will force the folder name to be “username.V2” and not to include the domain name.

The original configuration using the “Set path for Remote Desktop Services Roaming User” GPO setting includes the domain name in the roaming profile folder name, which caused the logon process to create a new folder with the target domain name. Updating the GPO to use the “Set Roaming profile path for all users logging onto this computer” removes the domain name from the folder name and allows the user to logon to the processed profile on the target domain.

Written by John Hobbs

Posted by LeadThem Consulting | in Authentication Services, Uncategorized | No Comments »

Troubleshooting Desktop Authority

Oct. 10th 2016

As with any computer program, especially a management application such as Desktop Authority (DA), there will be times when you’ll be required to troubleshoot issues that may be encountered while using the product.  This is a brief overview of the log files produced by DA to assist with troubleshooting.

There are three categories of log files we can view when troubleshooting issues with Desktop Authority.

  • Manager (console) log files
  • User Based Management client log files
  • Computer Based Management log files

Let’s look at all three categories in more detail.

Manager Log files

These log files can be found on the Manager Console machine and depending on the OS, are found in different locations.

— W2k3 = %ALLUSERSPROFILE%\Application Data\ScriptLogic\DAConsole\

— W2k8 & W2k12 = %PROGRAM DATA%\ScriptLogic\DAConsole\

  • The DAConsolelog records general activity encountered during the launching of the manager console.
  • The DAConsole_errors.log records any errors or exceptions encountered when launching or running the manager console.
  • The SMWinServicelog – records all activity related to the Desktop Authority Manager Service.
  • The SMWinService_errors.log – records any errors or exceptions encountered when launching or running the Desktop Authority Manager Service.

User Based Management Client Log files

These log files can be found on the client machine under %TEMP%\Desktop Authority.

  • The SLTrace.htm file is used primarily to troubleshoot User Based Management settings executed during the logon event.
  • The SLTraceEnforce.htm file is used to troubleshoot User Based Management settings executed during the refresh event.
  • The SLTraceLogoff.htm file is used to troubleshoot User Based Management settings executed during the logoff event.
  • The SLBoostlog file is used to record activity encountered when attempting to provision the target machine.
  • The SLInstallog file is used to record activity encountered when attempting to provision the target machine with the DACIientlnstall.msi.
  • The SLAgentlog ffle is used to record details of activity recorded in the trace files, but mainly pertaining to the Run As Admin feature.

Computer Based Management Client Log files

These files are located on the client machine in %WIN DIR%\Temp\Desktop Authority.

ComputerManagementTrace.htm file is used to record the activity for all computer based management settings on a daily basis.

The SLTraceUSLoc.htm file is used to record the locator activity.

 

Hopefully these files, in addition to regular windows event logs and other systems can help you to quickly pinpoint and resolve any issue you encounter when using the product.  Good luck and happy computing!

Posted by LeadThem Consulting | in Authentication Services | No Comments »

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 ADUser@domain.com –w <password> join domain.com

 

The command above will join the current host to domain.com utilizing the Active Directory credentials for ADUser@domain.com.  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 ADUser@domain.com –k /etc/opt/quest/vas/sa.keytab join domain.com

 

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 Consulting

 

 ———————————————————————————————————————————————————————————————-

 

 

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