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!

.

Hi,
Ever had the need to extract all email adresses from a folder in Outlook?

Let's say you want to make a reply to a lot of people who are not in your addressbook (contacts), but who have sent you an email which you have archived in a specific folder (or from your Sent items).

I archive my emails all the time using one folder pr. "case", "customer" etc. - and sometimes it's ery useful to be able to write to everyone who had to do with the specific case. This is when it get's a bit frustrating - you have to find a way to get all the email-adresses, and only once!

This is how to do it the easy way:
1. In Outlook press ALT+F11 (opens Microsoft Visual Basic console)
2. Open "ThisOutlookSession" from the Project tree (left menubar)
3. Paste the code below into the project (right window)
4. Press F5 to Run the code (execute)
5. Select the folder you want to use and hit OK (might take some time to complete)
6. Press ALT+G and then copy the email-addresses from the "immediate" window (debug window)

Oh, and remember to use the BCC field if they shouldn't see eachothers email addresses (in the case you want to send an email to all of them).

CODE:
Sub GetEmailAddressesInFolder()
Dim objFolder As MAPIFolder
Dim strEmail As String
Dim strEmails As String
Dim objItem As Object

Set objFolder = Application.GetNamespace("Mapi").PickFolder

For Each objItem In objFolder.Items
If objItem.Class = olMail Then
strEmail = objItem.SenderEmailAddress
If InStr(strEmails, strEmail) = 0 Then strEmails = strEmails + strEmail + ";"
End If
Next
Debug.Print strEmails
End Sub


The above code is tested on Microsoft Outlook 2007, but should work on older Office systems too.

Original source here - I just had to modify the code a bit.


Bye for now!
.

Just found this - using Google Alerts of course :)

I made little modifications on this script created by Jakob Heidelberg to search for printers manually created on user profiles. This is very usefull when you wanna ensure that eveybody has only auto created printers, from Citrix or ThinPrint.

This script load ntuser.dat on each profile, check some registry keys, write a log and unload ntuser.dat. Some users can have problems to load their profiles if you use this script on the same time that they try logon.

http://www.robertoalves.com/?p=58

I just love sharing!

When you have the Group Policy Preference (GPP) Client Side Extensions (CSE) downloaded you'll notice that they are not (yet) in the .MSI format - so using Group Policy Software Installation (GPSI) is not possible. Bummer, right!?

We have .EXE files for Windows XP/2003 and .MSU files for Windows Vista... But that's not the only thing we need to think about. Before "deploying" these things to the clients on the network we need to know the OS version (XP/2003/Vista), the OS architecture (32 or 64 bit), the Service Pack Level, and whether or not the Group Policy Preference Pre-requisites (WmlLite - http://support.microsoft.com/kb/914783/en-us) are installed.

To make all this pretty easy I've created a "demo" script for deploying the GPP CSEs using Startup Script - or a manual launch (in admin context). My good friend Jeremy Moskowitz asked me to do this - so, a couple of hours later the "demo" - or "beta" - script is public (download below)...

Note: I haven't been able to test in all scenarios yet, but I *think* they are all covered pretty well by now. Please report back if you find any problems - any feedback is welcome!

Download the VBS script right here!

NB! You might need other language version for the XmlLite GPP CSE Pre-requisites, so watch out!

Running the script in your production network is on your own risk. The code is delivered "As Is" - totally free of any charge. No strings attached.

 

I hope this works out nicely for you!

.

If you have looked into "The onion ring", or just "Tor", you have probably wondered if it would be wise to block access from these anonymous servers (or maybe just the exit nodes). I am not gonna talk about how the encrypted Tor network works, as a great deal of info can be found "out there". Main source should be: www.torproject.org - and perhaps WikiPedia.

As a security guy (or ISA administrator maybe), you ask yourself "why do these people want to be anonymous"? In this case "anonymous" means that "they" don’t want targets on the Internet to see the originating IP address (the source). A "target" is typically a web site or some other web service.

The answer? Well, first you gotta ask yourself: "who are they"? And there’s really no good answer to that question I guess - who really knows? All we can do is guess, so let me turn these questions around: if I were to try out a hack, or some new exploit, would I do it directly over my personal WAN IP? Or would I try to "hide" my originating IP? If you look at it in that perspective Tor networks are GREAT for hiding out - the whole idea is that it shouldn’t be possible to track the communication. What you don’t know can hurt you, right? I’m not saying all Tor users are hackers or anything, because they are not, but you have to look at the odds… What do you think? I cant help thinking, that if you hide from someone you have something (bad) to hide - but hey, it could be a Christmas present, right?

Anyway - you have to decide - do I want these people to be able to access my web sites and services or not? I’m not going to decide on your behalf - that’s politics!

So, what can we do about it if we want them out? Well, after reading Thomas Shinders Blog entry "HammerOfGod Computer Sets — Block and Log by Country" I got an idea. How about downloading a list of Tor servers, import it into a Computer Set (CS) and make sure that CS is an Exception on all of you Published services? This way hackers out there, behind Tor servers, won’t be able to poke around your IIS servers or whatever you have.

 

So, I started a search for Tor lists - the best thing would probably be to create it yourself dynamically - but that would take programming skills that I unfortunately haven’t got. I’m just a scripting kinda guy… The thing is, you would need to have a Tor client installed and from that extract the list once in a while - not possible for me (maybe you can do it easily - please post a "how to" then).

But, then I found a list on Proxy.org - this list it updated regularly - the only thing is, that this list is formatted for easy import on Apache servers, definitely not ISA. But hey, we can change the formatting in a script and then call the "AddComputersToComputerSet.vbs" script from Microsoft… Simple, all we have to do then, is to configure the CS exceptions on our ISA rules, schedule the script and never touch it again!

So, I created a simple script for:

a) Downloading the latest Tor server list from Proxy.org
b) After the download it creates a new file with the correct format (machine_name<tab>IP_address)
c) And then it calls the AddComputersToComputerSet.vbs with the correct parameters

You can download the script here - also download the script from MS (link above) and place them in the same directory. You will need a bit of VBS knowledge to "tweak" the script(s), but I’ve tried to make the code "easy understandable". Now, make sure you can run it from your ISA box (it downloads over HTTP), and then schedule the thing (oh, and remember to remove the Msgbox "Done!" line if you want this as a scheduled task).

If you want it to run from another machine, take a look at the link to the AddComputersToComputerSet I provided above (some changes are needed).

Please report back if you have any bug reports or ideas! It provided "As Is" - after downloading you’re on your own :)

 

The dynamically created/updated ISA Computer Set:

The ISA Rule/Publishing Exceptions:

What’s missing?
I can think of a lot of things I’d like to add in there - but the idea with this blog entry is to "spread the word" and a Proof of Concept.

Personally I want to add logging of script actions, email alerts if the list is unavailable or some other errors occur. Also, there’s a weakness in case the downloadable list is compromised somehow. Say someone adds Internal/Private/"not-Tor" IPs etc. to the list, it just might give some strange results for your users. So, we have to trust the list is OK secure - but it would be a good idea to put in some sort of validation on what IP addresses are put into this particular CS.

 

Hope you can use this :)

.

Microsoft just gave us an updated version of the Windows Script engine that we all love so much… This version brings very few additions, but great many fixes.

From release notes:
This release of Windows Script brings the improvements in scripting made during the Vista development cycle to downlevel platforms. During any release cycle we test with increasingly effective analysis tools designed to expose stability problems, memory leaks, and potential security weaknesses in code. The results from this testing comprise the vast majority of changes. Of course, we also include all the current security updates. This is the fastest, most robust, and secure release of Windows Script available.

Why Version 5.7?
The primary reason for changing the version number from 5.6 to 5.7 is to simplify servicing and support by synchronizing the versioning to a consistent scheme based on Vista build number. The minor version increase does not indicate significant new features. The scripting feature set is substantially the same as 5.6, with only minor additions.

What’s New
In addition to the general improvements noted above, the following are some of the notable changes in this release.

JScript
• This package includes the improved garbage collector (GC) shipped with Internet Explorer 7 and Vista. The new GC can dramatically improve the performance of applications that create large numbers of objects, such as Ajax-style web applications. These performance improvements are now available to users of earlier browsers.This work replaces and improves upon KB919237. If you have implemented KB919237, we recommend removing the registry keys.
• New progid JScript.Compact implements the JScript Compact Profile (ECMA 327). This is a profile of the ECMAScript language standard with a subset of features. See the ECMA 327 standard for more information.
• Update for new Daylight Savings Time rules.

VBScript
• VBScript defines a new global function GetUILanguage that returns the current default user interface language. This is the same value returned by the Windows API GetUserDefaultUILanguage. Script authors can now write code that is aware of the current user’s language preference.
• Fix crash when calling VBScript class objects from JScript.
• Fix problems with comparisons to NaN in some versions (KB901104).VBScript and JScript
• Support for large address space on machines with > 2GB RAM (KB890048)
• Improved stack checking makes script more robust in the face of stack overflows.
• Fix miscellaneous TLS leaks and memory leaks, including using the RegEx object with more than 10 sub-matches.Windows Scripting Host
• Fixed rare deadlocks in remote scripting. Prevents occasional hangs in remote scripts.
• Fixed propagation of error return codes in remote scripting. Error codes produced by remote scripts are more reliably returned to the client.
• Fixed attempting to load nonexistent wshenu.dll which created performance problem in login scripts.

Included KB’s
This release also contains fixes described in the following knowledgebase articles.
KB831191
KB834742
KB836863
KB890048
KB892296
KB901104
KB903648
KB906092
KB917344
KB919237 (superceded by new GC)
KB925753
KB933811
KB933812
KB933873
KB940284

Download here:
Windows Script 5.7 for Windows 2000
Windows Script 5.7 for Windows XP
Windows Script 5.7 for Windows Server 2003
Windows Script 5.7 Release Notes

_