Archive for the 'Longhorn' Category

Fine-Grained Password Management post from Tyson

Tyson Kopczynski – the author of Windows PowerShell Unleashed (sample chapter available here) has a post on Managing Fine Grained Password Policies.

In which he also complaints that big vendors – Microsoft in this case – are sometimes releasing features – like BitLocker or fine-grained password policies – without fully providing sufficient management tools to actually use them. Needless to say this is very much inline with what I am thinking on the need for do-it-yourself administrative consoles.

Tyson concludes by the following:

My reply to my co-worker was to use either the PasswordSettingsObject cmdlets from Quest or the PowerGUI snap-in which uses those cmdlets –

I’ve also previously blogged about both the cmdlets and the UI:

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

Longhorn UG in UK, Scotty and Austin Blogging

Just found from Austin Osuide that not only has Windows Server 2008 started (congratulations, Scotty!), they already have the website up and running, and Scotty made Austin start blogging too.

Scotty and Austin have been active members of the PowerShell Usergroup so now the Longhorn group is surely in good hands!

Also, both Austin and Scotty are among the top IT consultants in UK so I hope some of their insight is going to be leak through their blogs. (And thanks for the congratulations, Austin!)

Tags: , , ,

Free UI Console for Fine-Grained Password Policies

I spent most of the day today using the password policy cmdlets and the PowerShell UI we all use and love to create graphical user interface for fine-grained password policies (see overviews in 4sysops and Ulf’s blog) in my Windows 2008 lab. And here’s the result (click to see it full size):

Graphical console to manage fine-grained password policies in Windows 2008 domains

What you see on the screen is the graphical user interface to manage those granular password policies and they are far nicer than ADSIEdit. 😉

I included the following functionality:

  • Create new password policy,
  • See password policy properties (PowerGUI adds sorting, filtering, reporting, copy to clipboard and other goodies),
  • Link a password policy to a user or group,
  • Unlink a password policy,
  • Remove a password policy,
  • See the resultant policy for a selected user.

All these operations also support bulk selection.

You can download the pack from PowerGUI library: Fine-Grained Password Policies – please provide feedback so I can make it better.

And, as usual, should you want to learn the command-line or script the same actions, just click the PowerShell Code tab at the bottom of the PowerGUI window – and copy/paste from there.


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

Manage Fine-Grained Password Policies with PowerShell

One of the major new features in the upcoming Windows Server 2008 (aka Longhorn) are granular password policies. The feature allows you to have multiple password policies within a single AD domain and thus be able to better fine-tune the security in your organization.

You can find pretty good write-ups about the feature and using ADSIedit to manage it at 4sysops and Ulf’s blog. However, as Richard pointed recently, using PowerShell to manage them is so much easier than ADSIEdit, so here’s a transcript of me experimenting with the policies in my Longhorn (Beta 3) lab (using AD cmdlets 1.0.3):

PS C:\> # Get the list of all password policies in the domain
PS C:\> Get-QADPasswordSettingsObject

Name      Type               DN                                                                       ----      ----               --                                                                       new pso   msDS-PasswordSe... CN=new pso,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

PSO2      msDS-PasswordSe... CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft   

PS C:\> # Let's see all settings of a particular policy
PS C:\> Get-QADPasswordSettingsObject pso | Format-List

AppliesTo                   : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow                              ,DC=spb,DC=qsft}

CanonicalName               : cow.spb.qsft/System/Password Settings Container/PSO2

CreationDate                : 5/16/2007 4:50:29 PM

Description                 : 

DisplayName                 : 

DN                          : CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

Guid                        : 59632928-e3ff-4ced-afbf-c99ba2b60a8d

LockoutDuration             : -00:30:00

LockoutThreshold            : 0

MaximumPasswordAge          : -20.00:00:00

MinimumPasswordAge          : -1.00:00:00

MinimumPasswordLength       : 8

ModificationDate            : 6/18/2007 11:03:13 AM

Name                        : PSO2

PasswordComplexityEnabled   : True

PasswordHistoryLength       : 24

Precedence                  : 10

ResetLockoutCounterAfter    : -00:30:00

ReversibleEncryptionEnabled : False

Type                        : msDS-PasswordSettings

PS C:\> # Create a new policy, set a few attributes and leave the rest default
PS C:\> New-QADPasswordSettingsObject -Name BeatlesPolicy -Precedence 5 -PasswordHistoryLength 10 -PasswordComplexityEnabled $true

Name            Type               DN                                                                               ----            ----               --                                                                               

BeatlesPolicy   msDS-PasswordSe... CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft  

PS C:\> # See the properties of the new policy
PS C:\> Get-QADPasswordSettingsObject BeatlesPolicy | Format-List

AppliesTo                   : CanonicalName               : cow.spb.qsft/System/Password Settings Container/BeatlesPolicy

CreationDate                : 6/18/2007 11:41:17 AM

Description                 : 

DisplayName                 : 

DN                          : CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft

Guid                        : c76a72fd-6612-4647-b279-b42cf648e4eb

LockoutDuration             : -00:30:00

LockoutThreshold            : 5

MaximumPasswordAge          : -42.00:00:00

MinimumPasswordAge          : -30.00:00:00

MinimumPasswordLength       : 0

ModificationDate            : 6/18/2007 11:41:17 AM

Name                        : BeatlesPolicy

PasswordComplexityEnabled   : True

PasswordHistoryLength       : 10

Precedence                  : 5

ResetLockoutCounterAfter    : -00:30:00

ReversibleEncryptionEnabled : False

Type                        : msDS-PasswordSettings

PS C:\> # Link the policy to the COW\Beatles group
PS C:\> Add-QADPasswordSettingsObjectAppliesTo BeatlesPolicy -AppliesTo COW\Beatles

Name          Type               DN                                                                               

----          ----               --                                                                               

BeatlesPolicy msDS-PasswordSe... CN=BeatlesPolicy,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft  

PS C:\> # See where are all the polies linked now
PS C:\> Get-QADPasswordSettingsObject | Format-List Name, AppliesTo

Name      : new psoAppliesTo : {CN=Kelly Smith,CN=Users,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

Name      : PSO2

AppliesTo : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

Name      : BeatlesPolicy

AppliesTo : {CN=Beatles,CN=Users,DC=cow,DC=spb,DC=qsft}

PS C:\> # Check resultant policy for user jlennon (note that the Beatles policy got applied via group membership)
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name         msDS-ResultantPSO                                          

----         -----------------                                          

John Lennon  CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check resultant policy for user jlennon (note that the Beatles policy got applied via group membership)
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name        msDS-ResultantPSO                                          

----        -----------------                                          

John Lennon CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check the resultant policy and note that the one linked directly won
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name        msDS-ResultantPSO                                          

----        -----------------                                          

John Lennon CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Check where the policy is applied
PS C:\> Get-QADPasswordSettingsObject PSO2 | Format-List Name, AppliesTo

Name      : PSO2AppliesTo : {CN=Haruki.Murakami,OU=Demo,DC=cow,DC=spb,DC=qsft, CN=Event Log Readers,CN=Builtin,DC=cow,DC=spb,DC=qsft}

PS C:\> # Unlink the policy
PS C:\> Remove-QADPasswordSettingsObjectAppliesTo PSO2 -AppliesTo COW\jlennon

Name  Type               DN                                                                               

----  ----               --                                                                               

PSO2  msDS-PasswordSe... CN=PSO2,CN=Password Settings Container,CN=System,DC=cow,DC=spb,DC=qsft           

PS C:\> # Resultant policy changed back to the group one
PS C:\> Get-QADUser jlennon -IncludedProperties Msds-ResultantPSo | Format-Table Name, Msds-ResultantPSo

Name         msDS-ResultantPSO                                          

----         -----------------                                          

John Lennon  CN=BeatlesPolicy,CN=Password Settings Container,CN=Syste...

PS C:\> # Remove the policy from the directory
PS C:\> Remove-QADObject BeatlesPolicy

Are you sure you want to delete this object: CN=BeatlesPolicy,CN=Password Settings
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y

Windows Server 2008 and PowerShell – are better together! 😉

Here’s the fine-grained-passwords-demo.txt file with the commands in case you want to have fun with them yourself (just change the domain name, etc. to match your lab)

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

AD Cmdlets 1.0.2 Released: Support Vista and Longhorn

Andrei posted an announcement on release of v1.0.2 of AD cmdlets.

Vista/Longhorn Support

To me this is the main new feature. Not any particular cmdlet but just the ability to install and run the cmdlets on Windows Vista and Windows Server 2008 (Longhorn). My desktop computer runs Vista and my demo lab is 2008 so I am glad I no longer need to use a dev build not being available publicly.

However, besides that there are multiple other improvements such as:

Remove-QADObject cmdlet

Supports pipelining so you could run something like:

Get-QADGroupMember *Managers | Remove-QADObject -whatif

to get read of all managers in your company.

Seriously though, please execise with caution. Deleting accounts, groups, OUs, etc. can be pretty dangerous. Always use -whatif before really running the command, and when you do run it, carefully read the “Are you sure” note before confirming.

There is also the-DeleteTree parameter for objects within OUs:

Remove-QADObject '' -DeleteTree

Obviously, there are multiple other parameters (such as -Force) which you can find in documentation, help, or just by using tab-completion.

Output limits

1.0.1 had a couple of get- limitations:

All get- cmdlets returned by default just the first 1000 objects and if you wanted more (e.g. all) you had to use the -SizeLimit parameter with some huge number. In 1.0.2 the default limitation is still there(which is great in large environments) but unlimited mode is implemented. To remove the limitation simply use zero as your size limit.

(Get-QADUser -SizeLimit 0).Count

should return you the number of user accounts in your AD even if you have more than a 1,000 of those.

Get-GroupMember is also now not limited to the AD default retrieve set (was that 1,000 as well?) and always returns full list of members. You don’t have to use any parameters to achieve that:

Get-GroupMember "World-Wide Everyone"

will give you a list of all accounts in the group no matter how big it is.

You can create enabled user accounts

1.0.1 did not support setting UserAccountControl flags during creation so you had to first create an account and then use Set-QADUser to enable it. Now you can do it all with one cmdlet:

New-QADUser -Name 'User1' -OU '' -UserPassword 'Qwerty123' -ObjectAttributes @{userAccountControl=512}

Smart wildcard mode

Before that you had to manually switch cmdlets to PowerShell-wildcard mode for advanced wildcards. With 1.0.2 cmdlets are smart enough to make the decision for you:

Everything that was there before

All the functionality they had in 1.0.1 is of course still there as well.

Tags: , , , , , , , , ,

Longhorn RDP Airlift Slides

Here are the slides I was showing on the Longhorn Airlift AD PowerShell session:


Overall the session went well. I was surprised that a big part of the audience was not that familiar with PowerShell as such but everyone seemed pretty interested and I saw people taking notes during the session.

We used Longhorn Beta 3 for the demos and everything went surprisingly well. I even demoed experimental cmdlets for granular password policies.

P.S. In case you get the DVD and listen to the session or just were there. During the demo I completely forgot to mention that the new-account.ps1 script I was showing while demonstrating the ADSI approach is from Adam Bell. Thanks to Adam for providing that on his blog!

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

How PowerShell can manage Longhorn Core

It turns out that there actually is a way to manage Longhorn Core with PowerShell.

While I was preparing for my Longhorn Airlift session I kept thinking of the Microsoft’s decision to not allow PowerShell on Longhorn Core, and whether there could be any workaround to that. And it turned out that a workaround exists and is actually pretty straight-forward.

The answer is… using PowerShell remotely! While this answer is not applicable for managing operating system stuff (processes, services, registry, files and so on) AD cmdlets work just fine when installed to any computer in the network – not necessarily a DC.

By default they would pick some DC in the network and run against it with your current credentials, or you can use Connect-QADService to specify a specific DC and/or credentials. And in either case they work just fine even if your DCs are in the “headless” mode.

So to maximize your security in the Longhorn world:

1. Use Server Core installation option.

2. Use PowerShell to manage your AD.

Tags: , , , , , , , ,

No PowerShell for Longhorn Core?

Someone just told me that Longhorn Core server role does not support PowerShell so you have to get back to 20th century command-line style and learn all the different command-line styles of all the components.

(Disclaimer: I have not checked this myself so I hope someone comes out and tells me this is all wrong.)

Server Core role basically allows to install a minimal version of Longhorn and thus significantly reduce the attack surface and make your deployment more stable, efficient and secure. As there is no graphical user interface administrators are using the command-line instead. This makes sense except that the command-line is the same old cmd.exe.

To make it even worse, I was told that you cannot install PowerShell there manually even if you wanted to because PowerShell requires .NET which is not supported on Server Core.

I think this all is a real pity. Server Core and PowerShell were born to be together. I hope this was not an intentional decision but was rather a matter of priorities and having to chose to be able to ship.

Does this mean it’s time to start compiling your SP1 wish-lists?

Tags: , , ,

AD and PowerShell at Longhorn Airlift

I’ve been asked to present at the Microsoft Windows Server “Longhorn” RDP Airlift conference in Seattle on May 16 and needless to say was happy to accept the invitation. This is a great event where you can find enterprise customers participating in Microsoft’s “Longhorn” Rapid Deployment Program – i.e. deploying “Longhorn” beta in their production.

In case you are coming, the session will be on Wednesday, May 16 at 9:00am.

The title is: Managing Active Directory with PowerShell and creating custom administrative consoles (300 Level)

I am thinking of the following agenda:

  1. Quick introduction to PowerShell.
  2. AD management in PowerShell using:
    • ADSI, .NET.
    • AD provider.
    • AD cmdlets.
  3. Showing PowerGUI and custom UIs administrators can create for their own AD management tasks.

During the demos I am thinking of showing of a few AD-specific management tasks such as:

  1. Browsing AD, reporting, statistics.
  2. User account-, group-, OU-management.
  3. Provisioning from CSV files, cloning accounts.
  4. A few Longhorn-specific scenarios – such as granular password policies.

This sounds like a pretty exciting session and a good chance to start enterprises (not just geeks like you and me) thinking about PowerShell.

Any comment/suggestions?

Tags: , , , , , , , ,

The First Longhorn Build with PowerShell Shipped

Most blog posts about Longhorn April CTP which hit connect yesterday don’t mention the biggest aspect of this build. This is the first public Longhorn milestone to have PowerShell built-in.

Can’t wait to see PowerGUI and AD cmdlets running on it…

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

June 2022

%d bloggers like this: