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: , , , , , , , , ,

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

January 2019
« Oct    

%d bloggers like this: