Quest Software provides PowerShell users with the possibility to manage Active Directory quickly and easily through their free Active Directory cmdlets. I love using PowerShell to get the exact information I need, using a single line of code. The following oneliner for instance returns the description of a server:

 

(Get-QADComputer -Name TESTSERVER -Credential $(Get-Credential TESTDOMAIN\TESTUSER)).Description

 

Isn’t that way cooler then opening Active Directory Users and Computers, searching for the server and opening the properties dialog? It might not be faster of less work, but it does exactly what I want. I think it’s pretty elegant.

 

I found a strange flaw in the way the Quest cmdlets handle my credentials though.

 

The native PowerShell Get-Credential command allows you to supply network credentials, when connecting to remote computers for example. As a security precaution, your password is stored in a secure manner. Check this out:

 

PS D:\> $cred = Get-Credential TESTDOMAIN\TESTUSER (a dialog box pops up and asks me to supply my password)

PS D:\> $cred.password

System.Security.SecureString

 

As you can see, PowerShell does not allow me to read the contents of the password property.

The stored credentials allow me to authenticate against a remote server. So while this WMI query fails:

 

PS D:\> Get-WmiObject Win32_OperatingSystem -ComputerName TESTSERVER

Get-WmiObject : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

At line:1 char:14

+ Get-WmiObject  <<<< Win32_OperatingSystem -ComputerName TESTSERVER

 

This works like a charm:

 

PS D:\> Get-WmiObject Win32_OperatingSystem -ComputerName TESTSERVER -Credential $cred

SystemDirectory : C:\WINNT\system32

Organization    : TESTORG

BuildNumber     : 3790

RegisteredUser  : TESTORG

SerialNumber    : 12345-123-1234567-12345

Version         : 5.2.3790

 

The Quest Active Directory cmdlets also allow me to use these stored credentials to connect to Active Directory:

 

PS D:\> $computer = Get-QADComputer -Name testcomputer -Credential $cred

PS D:\>$computer

Name                      Type                    DN

—-                            —-                      

TESTSERVER          computer           CN=TESTSERVER,DC=TESTDOMAIN,DC=LOCAL

 

That’s just great! But I found out recently that the object returned by this command has a property called NetworkCredential:

 

PS D:\> $computer | Format-List -Property NetworkCredential

NetworkCredential : System.Net.NetworkCredential

 

Now let’s take a look at the value of this property:

 

PS D:\> $computer.NetworkCredential | Format-List -Property *

UserName : TESTUSER

Password : SecretPassword!

Domain   : TESTDOMAIN

 

Hey, what the hell!? That’s my password! I thought it was secret!

Tagged with:
 

4 Responses to Quest can’t keep a secret?

  1. aleksandar says:

    Quest is not alone, try this too:

    $cred = get-credential

    [Net.NetworkCredential]$cred

    ;-)

  2. This actually has nothing to do with Quest. Get-Credential is a native PowerShell cmdlet from Microsoft and unfortunately this is the way they decide to keep passwords. See this blog post and its comments for more information:

    http://dmitrysotnikov.wordpress.com/2007/07/27/powershell-security/

  3. With that said, in AD cmdlets 1.1 objects will not expose the NetworkCredential property at all – thus limiting your exposure to the Microsoft’s credentials object issue.

  4. admin says:

    Thank you for your comments!
    I hope they’ll change this behaviour in version 2 of PowerShell. I haven’t had the chance to work with the CTP of PowerShell v2.0 yet.

Leave a Reply