Changes to RunAs and Drive Mapping in EM 2018.3 – Why you need a Certificate and How to Deploy it to Endpoints

Version 1

    In Environment Manager 2018.3 the “Run As” capability for Policy Actions had a major overhaul, and introduced a new method for passing credentials to the endpoint agent for Run As and Drive Mapping operations.

     

    Actions in Environment Manager have the option of being run in the context of: (1) the currently logged-on user, (2) as the SYSTEM account, or (3) as a specific account which requires that the user of the EM console supply the password for that account and store the credentials with a Friendly Name.

     

    1.jpg

     

    Similarly, mapping a Drive Letter to a network share can be performed as the logged-on user, or with another account by entering the account name and password:

     

    2.jpg

     

    If your EM actions only use SYSTEM or Current User options then you have nothing to change! However, if you use specific accounts to perform those operations then in EM 2018.3 the method used to encrypt and decrypt the password in the aemp file now uses a public key and private key pair that you will need to generate and distribute. The private key must be available on all endpoints that need to decrypt the password. The public key is used in the console by the administrator to encrypt the password.

     

    The Friendly Name is configured as a combination of a specific user account and password. Here is a screenshot of the EM console where the certificate with the public key is selected and the Friendly Name is configured:

    3.jpg

     

    Before we get into more detail on how to create and distribute these keys, first consider if there is another approach that removes the need for a specific user name and password. If you are copying files at logon, consider whether changing the ACL on a file server to allow access from an AD Group removes the need to use a specific account. If you have looked at that and still need to use the specific user name and password, read on…

     

    We have chosen to distribute use digital certificates to distribute the public and private keys used for password encryption and decryption, since many enterprise environments already have a secure method for creating and delivering certificates to endpoints. If you don’t have a Certificate Authority or other method of creating a certificate, you can make a self-signed certificate with PowerShell. Here’s an example, which you need to run as Administrator:

     

    New-SelfSignedCertificate -Subject "EMEncryption(VAL)" -CertStoreLocation cert:\LocalMachine\My -KeySpec KeyExchange

     

    When using Microsoft Server 2012 R2

    Microsoft recommend using the following command:

     

    New-SelfSignedCertificate -DnsName "*.costoso100.com" -CertStoreLocation "cert:\LocalMachine\My"

    This certificate can be exported and copied to the computer running the EM console (without its private key) and selected in the dialog shown above. You can export it directly from the Certificates MMC snap-in:

    4.png

     

    On the endpoints, this certificate (that has been exported *with* its private key, and protected with another password) needs to be copied and securely placed in the endpoint certificate store. The EM agent looks into the Local Computer\Personal store on each endpoint (which is the localMachine\My store in PowerShell) to find the certificate and its private key. Here is a PowerShell script that can be used to copy it from a file share to the correct store. The file share should be secured so that ordinary users cannot access it. Note that the private key password is required since the private key is in the file alongside the certificate:

     

    $mypwd = ConvertTo-SecureString -String "PrivateKeyPassword" -Force –AsPlainText

    Import-PfxCertificate –FilePath ""\\server\share\EMEncryption.pfx"" cert:\localMachine\My -Password $mypwd

     

    This script could be run from Group Policy, or as a package in Ivanti Endpoint Manager or Microsoft System Center Configuration Manager, or you could even launch it from Environment Manager. However, if you run it from Environment Manager note that the aemp file would give a user everything needed to decrypt passwords in one place if they have access to the file share.

     

    One final step to prevent anyone except SYSTEM from accessing the certificate (and private key) stored on the endpoint is to protect it with an ACL. Here is an example of PowerShell that denies access to users, and needs to be run on each endpoint:

     

    $certCN = "CN=EMEncryption\(VAL\)"

    $WorkingCert = Get-ChildItem CERT:\LocalMachine\My | Where-Object {$_.Subject -Match $certCN} | Sort-Object $_.NotAfter -Descending | Select-Object -First 1 -ErrorAction STOP

    $rsaFile = $WorkingCert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName

    $keyPath = "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\"

    $fullPath=$keyPath+$rsaFile

    $acl=Get-Acl -Path $fullPath

    $permission="Authenticated Users","Read","Deny"

    $accessRule=new-object System.Security.AccessControl.FileSystemAccessRule $permission

    $acl.AddAccessRule($accessRule)

    Set-Acl $fullPath $acl

     

    One huge benefit of this change is that you can now securely connect to the Ivanti Automation and Identity Director servers from the EM agent, in order to automate IT workflows, and query Identity Director as a source of user entitlement to services and applications. This is an exciting capability that underlines Ivanti’s focus on unifying and simplifying IT.