Archive for the 'Security' Category

Deep Dive video: Constrained PowerShell Endpoints – Aleksandar Nikolic

We continue publishing the recordings from the previous PowerShell Deep Dive. This is Aleksandar‘s session on constrained runspaces / constrained endpoints – and was probably one of the most advanced sessions of the conference.

Aleksandar looks at the PowerShell remoting from the service creator’s point of view. The goal of constrained endpoints is to provide controlled access to services on a server in a secure manner. He shows how to create and configure a custom endpoint, control who has access to it, and constrain a session to defined set of capabilities available to users connecting to the endpoint.

This is a live recording from US TEC 2011 PowerShell Deep Dive conference. TEC Europe is just around the corner – October 17-19th, 2011 in Frankfurt. Register today to get a discount.

See also:

Improved script-signing in PowerGUI

Kirk has just updated his Script Editor add-on allowing you to sign your PowerShell scripts.

Script-signing is a highly-recomended best practice in PowerShell and the best way to prevent accidentally changed scripts or scripts downloaded from the internet and not properly tested and verified to be executed in your environment.

Kirk’s add-on is a great way to have code-signing integrated right into your script development environment absolutely for free. This is also one of our most popular add-ons which already had more than 700 downloads.

The new features include:

  • Replaced test certificate functionality with View Certificate, and updated result to show the certificate properties in the native windows dialog,
  • Updated script signing certificate search algorithm to search only in the “My” containers (the only places where script signing certificates will be stored),
  • Switched the default signing method to include all certificates in the chain.

Download the PowerShell Script-Signing add-on for PowerGUI here and let us know what you think.

Security Webcast is Today

[UPDATE] Recording of this webcast is available here.

Today at 11:00 AM EDT Randy F. Smith from Ultimate Windows Security is holding a webinar on using PowerShell to ensure Active Directory and Windows Server security. The webcast is sponsored by Quest and free to attend.

Pre-registration is required and the space is limited so you might want to register right away here.

Learn more about the PowerShell AD/Windows security webinar here.

PowerShell in the Enterprise

Jeffery HicksA wealth of best practices and recommendations on deployment and use of PowerShell at the enterprise scale can be found in this whitepaper from Jeffery Hicks.

This is more of a high-level architect kind of document providing key information on all the most important aspects to keep in mind. Which is great considering that most of the PowerShell material available on the web today is low-level PowerShell code for geeks – rather than the guidelines which IT architects and IT managers probably need.

The whitepaper introduces PowerShell and talks about its origins and advantages over the alternatives. discusses the deployment process, security aspects and best practices on using PowerShell in the enterprise.

All in all, great way to plan your enterprise transition to PowerShell in a secure and efficient way!

Get the whitepaper here (free download but registration required.)

Find and fix broken inheritance

Broken permissions inheritance can be a source of multiple issues – with PowerShell you can get such issues located and fixed with an easy oneliner.

Getting security inheritance blocked is easy – locating and setting it back can be hard. One big customer of ours once had most of their mail transport paralyzed with a branch administrator clearing the inherit permissions checkbox he thought should not have been there. Nicolas is reporting similar issues with Exchange 2007 deployments.

Seeing whether an AD object has permissions inheritance blocked is as easy as checking the object’s DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected property.

So for example, to get a list of all users in the domain who has inheritance off you just need to run:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected}

I am using -SizeLimit 0 so I retrieve all users and not just the default 1000.

Fixing inheritance is even easier with the new Set-QADObjectSecurity cmdlet introduced in AD cmdlets 1.1.

So if you want to fix inheritance for all AD users (caution: you might want to just get the list of the accounts first using the command above to make sure you do not “fix” legitimate exceptions) you just need to pipe the collection into Set-QADObjectSecurity -UnlockInheritance:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected} | Set-QADObjectSecurity -UnlockInheritance


Tags: , , , , , , , , , ,

Changing AD permissions

I’ve recently blogged about retrieving AD security with PowerShell, as you can probably guess for every Get-* there is a Set-* and AD cmdlets 1.1 provide you an easy way to change the permissions set on any AD object.

Add-QADPermission and Remove-QADPermission are your biggest friends here.

Well, obviously and the power of the PowerShell pipeline. My favorite example is copying permissions from one object to another with that simple oneliner:

Get-QADPermission “Dmitry Sotnikov” | Add-QADPermission “Evil Tween”

This simple line is incredibly powerful. It takes all permissions directly set on the first objects and adds them onto the second one. Of course you could put where in the middle to do some filtering if you need.

Of course you can explicitly grant specific rights on specific objects. Suppose you want to give Administrator full control over an OU and everything in it. Easy:

Add-QADPermission OU=Demo,DC=mydomain,DC=local -Account Administrator -Rights GenericAll

You can use the -Deny parameter to deny access, -PropertySet to work with property sets 🙂 and -ApplyTo to select whether you want to give rights only to this object or its children or any possible combination. So for example you could do:

Add-QADPermission dirObjectIdentity -Deny -Account trusteeIdentity -Rights WriteProperty -PropertySet (General-Information,Web-Information) -Property samAccountName -ApplyTo ThisObjectOnly

You can also pipe any AD object into these cmdlets (similar to reading the objects) for bulk operations:

Get-QADUser -City Orlando -SecurityMask Dacl | Add-QADPermission -Account Dmitry Sotnikov -Rights ReadProperty

And, as you can easily guess Remove-QADPermission can delete any ACE in much the same way. For example, let’s remove all the Deny ACEs from a particular object:

Get-QADPermission objectIdentity -Deny | Remove-QADPermission

You can find more information and examples in the user’s guide and by typing get-help for any of these cmdlets.

Download the cmdlets and give us your feedback at the AD PowerShell discussion forums.

Tags: , , , , , , , ,

Read Active Directory Permissions

One of the biggest advances of AD cmdlets 1.1 is support for AD security operations. In this post we will look at the Get-QADPermission cmdlet and how you can use it to read permissions set on AD objects.

To get a list of permissions set on an AD objects directly you just need to use:

Get-QADPermission Identity – where identity is Name, DN, Canonical name, Domain\Name, and so on. For example:

Get-QADPermission Dmitry Sotnikov

As usual you can pipeline a set of objects into the cmdlet to get results for all of them, e.g.:

Get-QADUser -SearchRoot domain.local/employees/chicago -SecurityMask DACL | Get-QADPermission

Here I am getting access control for all permissions directly set on users in the domain.local/employees/chicago OU. Note that I am also using the -SecurityMask parameter to tell the Get-QADUser cmdlet to retrieve the access list (DACL – Discretionary Account Control List). This is optionally but highly recommended because if you use this parameter Get-QADPermission does not have to retrieve the DACL again – less calls to the DC, better performance.

The examples above deal only with the permissions set on the object directly, you can add inherited permissions by simply adding -Inherited. In a similar fashion, the -SchemaDefault parameter adds Account Control Entries (ACE) that came from the default security descriptor. So this will give you everything:

Get-QADPermission Dmitry Sotnikov -Inherited -SchemaDefault

Or the same but much faster:
Get-QADUser -Name Dmitry Sotnikov -SecurityMask DACL | Get-QADPermission -Inherited -SchemaDefault

You can look for the rights which specific trusties have:

Get-QADPermission Dmitry Sotnikov -Account (domain\bill, self) -UseTokenGroups

Note that I have added -UseTokenGroups to make sure I get Bill’s rights even if he got those via group membership.

Or for specific rights set on specific properties:

Get-QADPermission Dmitry Sotnikov -Rights WriteProperty -Property (samAccountName,name)

You can also check for extended rights. Let’s see if I can change my password:

Get-QADPermission Dmitry Sotnikov -account self,everyone -Allow -ExtendedRight User-Change-Password -InheritedSchemaDefault

-Allow and -Deny parameters allow to check specifically for allowing and denying ACEs.

And there’s much much more: just check out:

get-help Get-QADPermission -detailed

Good job by the team trying to cover each and every case they could think of. If you can think of something they have not covered or implemented in a suboptimal way – please provide your feedback in the AD PowerShell forum – the team is there and listening.

Here’s the AD cmdlets download page which has the latest 1.1 beta drop.

Tags: , , , , , , , , ,

What’s new in AD cmdlets 1.1.0?

Here’s a quick summary of the new and exciting features added in Quest’s free AD cmdlets 1.1.0 just published on the web (I plan to provide more details and examples next week):

1. Get-QADGroupMember -Indirect – this new parameter allows you to retrieve complete group membership for nested AD groups in one command!

2. Permission management cmdlets:

  • Get-QADPermission,
  • Add-QADPermission,
  • Remove-QADPermission,
  • Get-QADObjectSecurity,
  • Remove-QADObjectSecurity.

3. New parameters of Get-QADUser:

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • Email (string)
  • AccountExpiresBefore (DateTime)
  • AccountExpiresAfter (DateTime)
  • AccountNeverExpires (bool)
  • PasswordNeverExpires (bool)

4. New parameters of Set-QADUser

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • Email (string)
  • AccountExpires (DateTime, nullable)
  • PasswordNeverExpires (bool)
  • UserMustChangePassword (bool)
  • TsProfilePath (string)
  • TsHomeDirectory (string)
  • TsHomeDrive (string)
  • TsWorkDirectory (string)
  • TsInitialProgram (string)
  • TsMaxDisconnectionTime (TimeSpan)
  • TsMaxConnectionTime (TimeSpan)
  • TsMaxIdleTime (TimeSpan)
  • TsAllowLogon (bool)
  • TsRemoteControl (int)
  • TsReconnectionAction (int)
  • TsBrokenConnectionAction (int)
  • TsConnectClientDrives (bool)
  • TsConnectPrinterDrives (bool)
  • TsDefaultToMainPrinter (bool)

5. New properties of User object

  • HomeDirectory (string)
  • HomeDrive (string)
  • ProfilePath (string)
  • LogonScript (string)
  • AccountExpires (DateTime, nullable)
  • PasswordLastSet (DateTime, nullable, readonly)
  • PasswordAge (TimeSpan, nullable, readonly)
  • PasswordExpires (DateTime, nullable, readonly)
  • LastLogonTimestamp (DateTime, nullable, readonly)
  • LastLogon (DateTime, nullable, readonly)
  • LastLogoff (DateTime, nullable, readonly)
  • AccountIsDisabled (bool)
  • AccountIsLockedOut (bool)
  • PasswordNeverExpires (bool)
  • UserMustChangePassword (bool)

6. Set-QADGroup now has GroupType and GroupScope parameters (to change group type and scope ;))
7. New cmdlet Get-QADRootDSE
8. Disambiguation prefixes in Identity parameter: e.g. Get-QADUser ‘dn=cn=object_with@sign’
9. Access to default domain password policies through the domain object:e.g. Get-QADObject mydomain.local/ | format-list *
10. Functionality specific to Quest ActiveRoles Server (this will only work if you have the commercial app):

  • Access template link management,
  • Dynamic groups.

Lots of cool and exciting features and numerous bugfixes.

You can download the beta on the Quest’s AD cmdlets page. Please provide your feedback in the AD PowerShell discussion forums.

Tags: , , , , , , , , ,

“PowerShell credentials in clear text” follow-up

If you have not read these comments by MoW and Lee which they added to the PowerShell Security summary I posted last week please do.

Both of them commented on my concern on PowerShell being able to expose in clear text the credentials you specify when being prompted by username and/or password by a PowerShell script. In a nutshell, the bottomline is that it does not really matter. Yes, PowerShell makes retrieving the credentials a simple call of a function but even if it were not that easy, someone would have been able to retrieve it anyway.

These are good points and they have to do with the worst thing a technology can do: give you a false sense of security. If PowerShell pretends that it is keeping passwords safe but in fact it is not – this is the issue. If you are providing your credentials to a script you might want to become cautious of what the script does with them.

I think I still have mixed feelings about the issue, because when seeing Windows system credential prompt I kind of assume tighter security around the credentials I specify, but I can definitely see the point which MoW and Lee are making. Please read their comments for more details.

PowerShell Security

SANS Institute has started offering PowerShell security classes. I guess this means PowerShell is clearly getting traction. This also got me thinking of PowerShell security features in general.

PowerShell has been obviously designed with much more security in mind than VBScript or cmd.exe:

  1. By default .ps1 script files are associated with Notepad. Double-clicking a script does not start it.
  2. To reference a script in PowerShell you have to specify file path, so even if a script is called dir.ps1 typing in dir will not start it. The shortest way to reference it is .\dir.ps1.
  3. And finally execution policies by default won’t allow you to run any scripts at all. You can lift the limitation up a bit by allowing to run scripts signed by trusted authorities.

(Anything else I am missing?)

There are a few things I personally would like to see added in next releases:

  1. Make execution policies more granular to specify that scripts need to be signed by a specific certificate (the one my company’s IT is using) and not just any trusted one.
  2. Add built-in protection against code-injection. Right now each script creator needs to handle that him-/herself. Once the protection is in the platform everything is going to be much more secure!
  3. Fix the ability to retrieve clear text password from credentials prompt (issue found by Martin):

PS C:\> $creds = get-credential
PS C:\> $creds.GetNetworkCredential()

UserName                                Password--------                                --------

Admin                                   Qwerty!

(Anything else? Comments are welcome!)

There are some additional security features which are already available commercially from companies like Quest and SAPIEN (sorry if there are more which I have not referenced – please add in the comments) like:

  1. Impersonating scripts/command-line for helpdesk and other limited rights scenarios.
  2. Auditing.
  3. Approval workflows.

So I think that the summary would be that PowerShell has gone a long way to become a much more secure command-line and scripting environment than we used to have before. There is room for improvements but this is only v1, right? I am sure there’s more to come!


Tags: ,

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

September 2022

%d bloggers like this: