About
You arrived at the weblog of Geert Baeke. I am a technology consultant for a company called Xylos (Belgium). I mostly work with Microsoft technologies such as Windows, Active Directory, Exchange, Sharepoint, MSCS, and more. I am also actively busy with VMware's products, focussing on VMware ESX.

Sections
Search






XBOX 360

RSS Newsfeeds
baeke.info Main RSS Feed Main Page RSS
View Article  Longhorn granular password policies

Since the April CTP of Longhorn it is possible to set granular password policies. In previous versions of Windows and Active Directory, you can only have one password policy. This password policy is set in a group policy object (GPO) that is linked to the domain object. Although you set the password policy in a GPO, the actual password policy is stored as attributes of the domain object of Active Directory.

For example if you set the minimum password length to 7 for domain lh.local there will be a property called minPwdLength on the object with distinguished name DC=lh,DC=local. When users choose a password or an administrator sets a password, the minPwdLenght property is checked for compliance.

Granular password policies in Longhorn allow you to set a different password policy for users and global groups. You could, for example, require that administrators have a 14 character password instead of 7 for regular users. This is certainly a useful feature that should have been part of Active Directory from day one.

How is it actually done? Well, don't expect to be able to set this with a GPO on an organizational unit because you can't. You need to create an object of class msDS-PasswordSettings in "CN=Password Settings Container" under "CN=System" under your domain. You can do this with adsiedit.msc which is available by default on a Longhorn installation. For full details, you should read this post.

Once you have created an msDS-PasswordSettings object, you need to link it to a user or global group in Active Directory. This is done with the msDS-PSOAppliesTo property of the msDS-PasswordSettings object you created.

So in short, the procedure is:

  1. With adsiedit.msc, create an object of class msDS-PasswordSettings in the container "CN=System,CN=Password Settings Container". Adsiedit will ask for the required properties.
  2. With adsiedit.msc, set the property msDS-AppliesTo of the msDS-PasswordSettings object you created in step 1 to the distinguished names of the users and/or global groups that need this password policy.

Once you start applying password policies to users and groups it can be difficult to find out what policy is applied to them. You can use the PowerShell script below to find out:

$principal=[ADSI]'LDAP://$args'
$appliedPSO=$principal.get("msDS-PSOApplied")
$PSO=[ADSI]'LDAP://$appliedPSO'
$minpwdlength=$PSO.get("msDS-MinimumPasswordLength")
$lockout=$PSO.get("msDS-LockoutThreshold")
write-host "Password length: $minpwdlength"
write-host "Lockout: $lockout"

Save the above script to a .ps1 file (e.g. get-pwdpolicy.ps1) and run it with the distinguished name of the user or group. For example:

./get-pwdpolicy.ps1 'CN=Geert Baeke,OU=Test OU,DC=lh,DC=local'

The PowerShell script makes use of the msDS-PSOApplied property which is actually a backlink to the password settings object that is applied to this user. This is a good way to find out the applied policy because you can apply several policy objects to the same user or group but only one will win based on the msDS-PasswordSettingsPrecedence property.

View Article  PowerShell script to check ESX patch status

You can use the simple PowerShell script below to check ESX server patching status from your Windows client. Requirements:

  • .NET Framework 2.0
  • PowerShell v1.0
  • plink.exe (from the Putty download page) in your path
  • An account and password to remotely connect over SSH and execute the command esxupdate query.
  • Change the $servers array with your servers and also update the $account and $password variable.
  • Keep the $patches array up-to-date with ESX patch names.

The script:

$patches="ESX-2158032","ESX-1410076","ESX-1006511","ESX-9986131","ESX-8173580","ESX-6921838",
"ESX-2066306","ESX-6075798","ESX-5497987","ESX-3996003","ESX-2092658","ESX-2031037",
"ESX-1917602","ESX-1271657","ESX-9865995","ESX-6856573","ESX-6050503","ESX-5885387",
"ESX-5031800","ESX-3199476","ESX-9916286","ESX-9617902","ESX-8852210","ESX-8174018",
"ESX-7780490","ESX-7737432","ESX-5011126","ESX-3416571","ESX-1161870","ESX-2559638",
"ESX-2257739","ESX-1541239"

$servers="server0","server1"

$account="root"
$password="password"

$servers | % { $a=plink -pw $password $account@$_ "esxupdate query"

$server=$_

$patches | % {

  $patch=$_

  if( [regex]::match($a, $_).success ) {

     $summary="Installed"
  }
  else
 {
    $summary="Not installed"
 }

new-object psobject |
add-member -pass NoteProperty Server $server |
add-member -pass NoteProperty Patch $patch |
add-member -pass NoteProperty Summary $summary

}

}

 Save the above script as a .ps1 file (e.g. c:\patch.ps1) and run it as follows:

./patch.ps1 | ft -groupby server

You will get an overview of all patches grouped by server.

 

Login
User name:
Password:
Remember me 
This Month
April 2007
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Networking
View Geert Baeke's profile on LinkedIn

Services

Powered by BlogHarbor
Powered by BlogHarbor
StatCounter