Friday, October 9, 2020

Non-Persistent VDI: Adding RDP Passwords With Ivanti Environment Manager

Scenario:

Users accessing a non-persistent virtual desktop use an application via an RDP connection to a server. 

Problem:

When users launch the RDP shortcut, they are prompted for credentials. All users need to use the same service account local to the server but:

  1. Users should not have to remember the service account username.
  2. Users should not need to know the password.
  3. Users should be automatically logged in.

The username/password can no longer be entered into the .rdp file by one user and read by another.

Solution:

Use a combination of Ivanti Enviroment Manager and Powershell to add an entry to the users' Credential Manager.

For this example, I will assume the reader has knowledge of Ivanti EV. I have a Reusable Node for creating desktop shortcuts where these steps are stored. The reusable node is then added under User > Logon > Pre-Desktop so all shortcuts are available immediately after logon to the VDI desktop:

  1. Create a Powershell script to launch the RDP session:

    start-process -filepath "mstsc" -argumentlist "/v:servername"
    exit

  2. Save the script to whatever share used to copy files to desktops in Environment Manager
  3. In EV, Create a User Group condition for the AD group that will need the shortcut (Optional if not all users need this shortcut)
  4. Under that condition, create a Copy File action to copy the script created in step #1 to the desktop
  5. Under that action, create a Create Shortcut action to place a shortcut on the users' desktop

    The target of the shortcut is the path to Powershell (eg. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
    Parameters: <Path to Powershell Script copied in step 2> -windowstyle hidden

  6. Under the condition in step 3, create a Session Variable action. Enter a session variable name and set it's value to the password of the RDP user.
    Note - This does mean that the password is being stored on the Ivanti service in plain text. Make sure proper NTFS and/or SQL permissions are set to prevent unauthorized users from opening the configuration file. Actions in next steps prevent the plaintext password from being accessible on the client.
  7. Under the session variable action, create a custom action of type Powershell and add the following code to the bottom of the script substituting in the user nane and server name for the RDP session, as well as the session variable created in step 6:

    $user = "Domain\RDP_Username"
    $server = "RDP_Servername"
    $password = (Get-SessionVariable "sessionVariable")

    cmdkey /delete:"$server" # clears the credentials
    cmdkey /generic:"$Server" /user:"$user" /pass:"$password"

    Remove-Variable password # deletes plaintext password in memory

  8. Under the custom action, create a Delete Session Variable action. Specify the same session variable created in step 6.
The result will create a desktop shortcut that launches a remote desktop session to the specified server and automatically logs in using the credentials stored in Credential Manager. All without the user needing to know the server name, user name, or password. Additionally, the plaintext password is not stored anywhere on the VDI desktop.

Thursday, August 20, 2020

Solved: RAC0225: Sending the test mail failed - iDRAC 9

 Recently when configuring the SMTP settings on iDRAC 9 controllers, I kept receiving this error when testing:

RAC0225: Sending the test mail failed

The most common solutions found online involved making sure a DNS iDRAC Name and Static DNS Domain Name were set in iDRAC Settings -> Connectivity -> Network -> Common Settings.
However, these did not work in my case. Fortunately, I found the issue reviewing the support article for Configuring Email Notifications for iDRAC
Near the bottom of the article is this sneaky bit of info:

Note: After iDRAC is upgraded to version 4.00.00.00, you may stop receiving encrypted email alerts from iDRAC, if the external email server does not support encryption. iDRAC firmware version 4.00.00.00 introduces a user-selectable encryption option and the default protocol is StartTLS. To start receiving email messages again, disable the email encryption by using the following RACADM command: racadm set idrac.RemoteHosts.ConnectionEncryption None

In my case, the servers were shipped with version 4.00.00.00. If you're not familiar, you can use SSH to connect to the iDRAC9 (enabled by default). Use an app like PuTTY to connect to each iDRAC, log in with the same credentials used for the web console, and run the command: racadm set idrac.RemoteHosts.ConnectionEncryption None

A reset is not needed, simply test again and you should by greeted with a success message in iDRAC as well as an email from DNSiDRACName@StaticDNSDomainName with a subject of

Test email alert from DNSiDRACName
Stay safe!