The purpose of the script (SetLocalPassword.v2.txt - just rename to "SetLocalPassword.vbs") is, to ensure assignment of unique and complex password to a specific local user account (typically the local administrator account) on a Windows client in an Active Directory (AD) domain environment.

The script can be used, if you (for one reason or another) want a specified local user account (e.g. administrator) to be active, but you still want to ensure, that the password used is unique for each computer, that the password is changed regularly (a given period of time) and that you are able to logon using the password at any time. Usually I would recommend customers to just deactivate the local administrator account, or set the password using Group Policy Preferences (preferably different passwords on different security areas), but if these solutions aren’t usable in the environment, “ChangeLocalPassword.vbs” could be the right solution.

The intention is to execute the script as a "Startup Script” within a Group Policy Object (GPO), which is aimed at the relevant computer accounts in AD (as you probably know GPO’s can be filtered by AD security groups, WMI filters, Organizational Units (OU), domain and/or site). This way we ensure that the script is executed in ”SYSTEM" context, in which we can pretty much do anything on the local computer(s). Furthermore, SYSTEM can access network resources on behalf of the computer, as long as the resource in question (a file share in this case) allows “Domain Computers”, the specific AD computer account og “Authenticated Users” to gain access.

It is crucial that the group ”Authenticated Users” is NOT given access to the network share – in that case all users within the domain will be able to read which passwords are used on all computers hit by the GPO. Share permissions (could be a hidden share$) can of course be set to Everyone Full Control, but NTFS must be set to allow only members of the group "Domain Computers" to read and write - domain administrators, and other relevant groups (e.g. helpdesk, supporters, backup account etc.) should also have read access. If you have a Distributed File System (DFS) up and running it could be used as the network share.


This illustrates the scripts cycle:



1. The SYSTEM account is used by the computer during the boot process
2. DNS and AD is contacted, and Group Policies are processed (machine policies)
3. The GPO with the Startup Script is loaded
4. The VBS script is executed (also in SYSTEM context)
5. All activity is logged to a local log file (strLocalLog)
6. Some preliminary checks are performed, this includes last modification of strLocalStamp and network access (strNetShare)
7. A password (strNewPassword) is generated from 4 different criteras (intPasswordLength, intWantNumber, intWantLcase and intWantUcase)
8. The username and password (clear text) is logged in a central log file (strnetFile)
9. The chosen local user account (strLocalUser) is assigned the newly generated password (only if 8 was completed without any errors)
10. A local timestamp file is created or modified if 9 was successfully completed


Some important notes...

First and foremost one must ensure, that the script file the GPO is pointing to cannot be modified by others than the relevant administrators. If a user gets write access to that file, he or she can do anything (locally) on all machines executing the code. This is of course true for any GPO Startup Script used.

Another important thing to note is, that if your users have local admin rights (I hope not), they will be able to “hack” the solution in a couple of ways. First of all they will of course be able to reset passwords for all local user accounts, but if they are a bit clever, they will also be able to take over the SYSTEM account (hint: AT command or PSEXEC) and access the network share we are using – and thus read or modify the log files with all the clear text passwords. But who in the world would allow users to be local administrators in the fist place, right?

A Startup Script will time out if the script takes too long to execute, but we should not have such a problem with this script (normally executed in less than a second). Startup Scripts react differently depending on whether the “Always wait for the network at computer startup and logo” setting is set or not - the script should work in both cases though.


Let’s take a look at the customizable variables.

intDays = 60
- default: 60 days between password change

strNetShare = "\\SERVER\SHARE\"
- define as a share with the correct NTFS permissions set
- is could be a hidden share, perhaps on a DFS
- remember a trailing backslash (\) or the script will fail!

strLocalLog = "C:\admpwd.log"
- placement of the local log file of all activity (except for the password itself)

strLocalStamp = "C:\admpwd.stp"
- placement of the file used as a timestamp

strLocalUser = "test-user"
- name the user account to control (e.g. "administrator")

intPasswordLength = 12
- the number of characters the password should have (exactly)
- must be at least the same as the domains minimum password length

intWantNumbers = 1
- set whether or not the password should contain numbers (complexity requirement)

intWantLcase = 1
- set whether or not the password should contain lowercase letters (complexity requirement)

intWantUcase = 1
- set whether or not the password should contain UPPERCASE letters (complexity requirement)


An example of the strLocalLog (default "c:\admpwd.log") local log file:

2009-05-22 13:20:26 [STARTED]
2009-05-22 13:20:26 [VARIABLES - A]
2009-05-22 13:20:26 - intDays : 1
2009-05-22 13:20:26 - strNetShare : '\\SERVER\SHARE\'
2009-05-22 13:20:26 - strLocalLog : 'C:\admpwd.log'
2009-05-22 13:20:26 - strLocalStamp : 'C:\admpwd.stp'
2009-05-22 13:20:26 - strLocalUser : 'test-user'
2009-05-22 13:20:26 - strComputer : 'COMPUTER1'
2009-05-22 13:20:26 - strNetFile : '\\SERVER\SHARE\COMPUTER1.log'
2009-05-22 13:20:26 STATUS - No local stamp file, probably first run
2009-05-22 13:20:26 SUCCESS - ALIVE:\\SERVER\SHARE\
2009-05-22 13:20:26 [VARIABLES - B]
2009-05-22 13:20:26 - intPasswordLength: 12
2009-05-22 13:20:26 - intWantNumbers : 1
2009-05-22 13:20:26 - intWantLcase : 1
2009-05-22 13:20:26 - intWantUcase : 1
2009-05-22 13:20:26 SUCCESS - PWD SET for: 'test-user'
2009-05-22 13:20:26 SUCCESS - PWD written to: '\\SERVER\SHARE\COMPUTER1.log'
2009-05-22 13:20:26 SUCCESS - TIME written to: 'C:\admpwd.stp'
2009-05-22 13:20:26 [COMPLETED]

2009-05-22 13:27:45 [STARTED]
2009-05-22 13:27:45 [VARIABLES - A]
2009-05-22 13:27:45 - intDays : 1
2009-05-22 13:27:45 - strNetShare : '\\SERVER\SHARE\'
2009-05-22 13:27:45 - strLocalLog : 'C:\admpwd.log'
2009-05-22 13:27:45 - strLocalStamp : 'C:\admpwd.stp'
2009-05-22 13:27:45 - strLocalUser : 'test-user'
2009-05-22 13:27:45 - strComputer : 'COMPUTER1'
2009-05-22 13:27:45 - strNetFile : '\\SERVER\SHARE\COMPUTER1.log'
2009-05-22 13:27:45 STATUS - STAMP last modified: 22-05-2009 13:20:26
2009-05-22 13:27:45 STATUS - STAMP younger than: 1 days!
2009-05-22 13:27:45 [COMPLETED]

An example of the strNetFile (named [computername].log) network log file:

2009-05-20 13:20:26 test-user : 'W57Ja6c5Xcus'
2009-05-22 08:10:39 test-user : 'sdEc7s9Gbba8'


Final note:

The code could most definitely be more optimized (and prettier), but it works like a charm (and pretty fast too) on Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008 and Windows 7.

I hope it will turn out to be useful to someone out there - enjoy!

.

Here we are - Group Policy Preference Client Side Extensions are now available for download. This is a cool thing bringing lot's of Group Policy Power to admins around the world!

The GPP CSEs are included in Windows Server 2008 RTM, but can now be downloaded for:
Windows XP SP2+ (32/64 bit)
Windows Server 2003 SP1+ (32/64 bit)
Windows Vista RTM+ (32/64 bit)

These are the links:
GPP CSEs for Windows Vista (KB943729)
GPP CSEs for Windows Vista x64 Edition (KB943729)
GPP CSEs for Windows Server 2003 (KB943729)
GPP CSEs for Windows Server 2003 x64 Edition (KB943729)
GPP CSEs for Windows XP (KB943729)
GPP CSEs for Windows XP x64 Edition (KB943729)

To get Group Policy Preferences on your network all you need is a single Windows Server 2008 as a management station in you existing Windows Server 2003 AD (or 2008 AD of course). When RSAT (Remote Server Administration Tools) is out there - very soon! - a Windows Vista SP1 will be enough to get this cool functionality in your domain!

But remember, no GP Preferences (GPP) without the CSEs - so go ahead and download them now ;-)

 

.

If you have ever tried defining the Security Options policy setting called: "Interactive logon: Message text for users attempting to log on", you may have had some difficulties formatting the message the way you wanted it. This blog is about "how to" workaround a minor bug in the GPEDIT tool…

 

The issue:

First things first - the Group Policy setting is located here:

"Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\"

The value is a Multi-String registry value that allows you to make multiple lines in the message. The message pops up right after a users hits Ctrl+Alt+Del as a general warning to the user before actually logging on. But, unfortunately the formatting isn’t as perfect as it could be.

What happens is, that carriage returns are lost after formatting this "pre-logon message" with GPEDIT, imagine you would want a message like this (see Figure 3):

—>

I don’t know why this should be so hard? Jump next line please…

Let’s do a comma, and continue the line…
Line number 4 is ready, but let’s jump line 5 & 6 now…

Line 7 finishes up this story!

<—

Such a message would end up as (see Figure 5):

—>

I don’t know why this should be so hard? Jump next line please…
Let’s do a comma, and continue the line…
Line number 4 is ready, but let’s jump line 5 & 6 now…
Line 7 finishes up this story!

<—

So, basically the problem is: line feeds/carriage returns/empty lines disappear completely!

You can actually see this within the GPEDIT GUI, but only if you hit "Apply" before "OK" - if you just hit "OK" after typing in your message you cannot see that it’s actually changed by GPEDIT (so you think the formatting is working as it should). I tested this behavior with GPEDIT on Windows XP SP2 (local policy), Windows Server 2003 SP1 (domain policy), Windows Vista SP Pre-RC (local policy) and Windows Server 2008 RC1 (domain policy).

Figure 1 - I typed in my message with the format I wanted:

Figure 2 - I clicked Apply, and the formatting was changed:

If I had just click OK I wouldn’t have noticed the change - anyway it’s a bit annoying, right?

 

Solution/Workaround:

The solution I came up with is to modify the policy file directly/manually using Notepad. The file is located here:

"\\DOMAIN.local\SYSVOL\DOMAIN.local\Policies\{GPO-GUID}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf"

Within that file we have the relevant registry value, called "LegalNoticeText":

MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText=7,I don’t know why this should be so hard? Jump next line please…," ",Let’s do a comma"," and continue the line…,Line number 4 is ready"," but let’s jump line 5 & 6 now…," "," ",Line 7 finishes up this story!

Notice the " " (<quote><space><quote>) sequences, which are the same as empty lines.

This is the relevant line from a working GptTempl.inf file (the correct syntax written manually), and it actually works great:

Figure 3 - Pre-logon message on a Windows Server 2003 SP1 Domain Controller: 

Figure 4 - The above inserted GptTmpl.inf line also works for Windows XP SP2 in the same domain:

So, this proves that the INI file can actually be correctly formatted so clients (tested w/WS2003 SP1 and XP SP2 in a domain) can show the message perfectly. Please notice that the behavior is similar with local policies, but my testing has been focused on domain environments so far.

If you try to modify the working policy setting using GPEDIT again - after changing just a tiny bit (or just hitting OK to an existing setting) within the GPO the formatting/syntax is ruined again unfortunately (when GPO is saved by GPEDIT)! Look here what came out of it when I tested it:

MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText=7,I don’t know why this should be so hard? Jump next line please…,Let’s do a comma"," and continue the line…,Line number 4 is ready"," but let’s jump line 5 & 6 now…,Line 7 finishes up this story!

Notice the " " (<quote><space><quote>) sequences are gone! This gives a wrong result (no empty lines) when clients get the pre-logon message.

Figure 5 - The formatting is lost (or wrong) when GPEDIT does the job:

 

Please notice, if you’re testing this you will have to define an additional policy setting for it to work, namely the "Interactive logon: Message title for users attempting to log on" setting.

Figure 6 - The title must be set for pre-logon message to appear

 

Conclusion

So, my conclusion is that (existing version of) GPEDIT doesn’t modify the GptTmpl.inf file properly (or the registry for local policies for that matter) - for this particular value at least… My best guess is that it doesn’t handle the quotes (") correctly, but I can’t be 100% sure. A bug report has been made for Microsoft - so hopefully it will be fixed before the final release of Windows Server 2008 and the Remote Server Administration Tools (RSAT).

However, as mentioned you can make it work with a workaround like this: Just perform the GptTmpl.inf (below SYSVOL) editing manually, make a backup of the file when it’s perfect - and never touch that GPO with GPEDIT again… Until Microsoft releases an updated version of GPEDIT anyway.

 

Related KB articles out there:
KB 330618
KB 238149
Technet article

 

.

Just a “quick note” this time!

A nice looking whitepaper is available from the Microsoft Group Policy Team… This time it’s an AGPM overview: Advanced Group Policy Management Overview

It’s exciting, fantastic, amazing, wonderful and totally cool - Microsoft has FINALLY announced what is going to happen with the PolicyMaker stuff they got when taking over DesktopStandards… It’s going to be released with Windows Server 2008 as many of us had hoped for!

This is just GREAT I can tell you - and it will available to the public with the RC1 release of Windows Server 2008, maybe even before as a separate Beta program I’m told…

Microsoft decided to call it “Group Policy Preferences” or just “GP Preferences”. So, what can we do with this you ask? Well, here’s some of it:

• Map network drives
• Set Environment variables
• Copy Files to clients
• Create and update INI files
• Modify registry settings on the clients (REG_SZ, REG_DWORD, REG_BINARY, REG_MULTI_SZ, and REG_EXPAND_SZ )
• Create Shortcuts (URL/File/Shell)
• Open Database Connectivity (ODBC)
• Control Devices
• Set Folder Options
• Define File Associations
• Tweak Internet Settings
• Handle Local Users and Groups (change passwords, add/remove from groups, disable users etc.)
• Set Network Options (like VPN or Dial-Up connections)
• Configure Power Options (Windows XP)
• Map Printers (even TCP/IP printers)
• Set Regional Options
• Create Scheduled Tasks
• Set properties on Services
• Tweak the Start Menu
• and so on….

As you can see, it’s quite impressive and something that will make companies around the world turn to Windows Server 2008 ASAP… I think and hope anyway!

The client part, a necessary extension which must be installed on the client, will be ready for Windows XP/2003/Vista - and in both x86 and x64 editions. Windows Server 2008 already includes the CSE (Client Side Extension).

There’s SO much to tell, and SO little time… But, a Whitepaper is ready (a REALLY nice of the kind) thank you Microsoft!

Download the whitepaper here:
An Overview of Group Policy Preferences

Check out this article, it’s really good for a “quick” summary of the GP related changes in Windows Vista/Windows Server 2008 (Longhorn)

http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true