Quest can’t keep a secret?
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: 0×80070005 (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!
No related posts.
4 Responses to Quest can’t keep a secret?
Tags
Active Directory API bind order cleanup cluster CPU Custom Fields datastores description device management directory tree errors Event Log file name filter Fun function HA IT known issues License Server LUN multipath NIC objects Oneliner portgroups PowerCLI PowerShell profile recursive Registry Scripts security session share snapshots SQL Stat VI Toolkit VMware vSphere WMI WSUS ZenArchives
- July 2012
- July 2011
- February 2011
- January 2011
- December 2010
- May 2010
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008





Quest is not alone, try this too:
$cred = get-credential
[Net.NetworkCredential]$cred
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/
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.
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.