Showing posts with label password. Show all posts
Showing posts with label password. Show all posts

Thursday, September 30, 2010

Reset Passwords for all User Accounts in an OU

I realise that there's plenty of scripts floating around the net that already do this, but for me this was simply an exercise.

Note: I haven't gotten around to testing it yet.


' PasswordReset.vbs
' Resets all passwords within an AD Container
' Version 1.0
' 27 September 2010


Option Explicit
Dim objRootDSE, objOU, objUser
Dim strTargetOU, strForceReset, strEnAcct, strDNSDomain, strNewPass
Dim intCounter, intUACval, intPWLval


' Change strTargetOU to location of user accounts
strTargetOU = "MyContainer"


' Change strNewPass to the new password
strNewPass = "Password123"


' Change strForceReset to "Yes" in order to force users to reset passwords
strForceReset = "No"


' Change strEnAcct to "Yes" in order to enable disabled accounts
strEnAcct = "No"


' Int Values 
' See Microsoft KB305144 for UserAccountControl values
' Setting PwdLastSet value to 0 forces password reset
intUACval = 544
intPWLval = 0
intCounter = 0


Set objRootDSE = GetObject("LDAP://RootDSE") 
strDNSDomain = objRootDSE.Get("DefaultNamingContext")
strTargetOU = "OU=" & strTargetOU & ", " & strDNSDomain
set objOU =GetObject("LDAP://" & strTargetOU )


For each objUser in objOU
If objUser.class="user" then
objUser.SetPassword strNewPass
objUser.SetInfo


If strForceReset="Yes"
objUser.Put "pwdLastSet", intPWLval
objUser.SetInfo
End if
If strEnAcct="Yes"
objUser.Put "userAccountControl", intUACval
objUser.SetInfo
End if


intCounter = intCounter +1
End if
Next


WScript.Echo "New Password: " & strNewPass & vbCr & "Accounts changed: " & intCounter _
  & vbCr & "Password Change Forced: " & strForceReset & vbCr & "Disabled Accounts Enabled: " & strEnAcct
  


Thursday, January 28, 2010

Move and Disable Stale Computer Accounts

I started to write a script today to relocate and disable computer accounts that have an old PwdLastSet attribute. Before I got very far, I discovered that Richard Mueller of Hilltop Lab had already done quite an effective job of scripting this very task and has made the effort to refine it a few times too.

The script can be found at http://www.rlmueller.net/Programs/MoveOldComputers.txt

I modified it a little to suit my own purposes, but his script certainly got me 90% of the way there. Thanks for saving me the effort Richard!

Cheers,
Sean

Sunday, November 15, 2009

Local Account Manipulation

I had a request the other day from someone who knows some of my work. He had seen my scripts for manipulating local accounts on machines but couldn't make sense of them. (This was essentially because he was only seeing half of the system.) He asked if I could explain them in my blog, so here goes...

There are many different methods for manipulating local accounts on machines. Some companies make a profit from selling software that will go and talk to all of the machines and change passwords, accounts, group memberships, etc. Surprisingly, Microsoft has not yet integrated any system for easy management of local computer accounts into their own domain management systems. (Edit: Of course Microsoft has finally done something about this and you can now use Group Policy Preferences to manage local accounts quite easily. I thoroughly recommend using Group Policy instead of the method described here!)

Anyway, one way to achieve this is to use the Group Policy system. Computers run the Computer Startup Scripts with system administrative rights (Computer Configuration / Windows Settings / Scripts / Startup.) This enables the savvy administrator to run a script that can be used to manipulate local accounts.

What about the fact that the passwords may be exposed in the script? Some administrators will suggest that you do it in VBScript and then encrypt it. This is not a good idea because it is far too easy to decrypt these files. IMHO, it is much better to let Microsofts domain security protect it for you. (I can't believe I just said that. Scary but true!)

You can place these 'scriptlets' below in your scripts folder and pass the required parameters to them from your GPO. You secure your GPO by removing Authenticated Users from having read and apply group policies rights and giving Domain Computers read and apply group policy rights. Using this method, the users cannot see the new passwords, but the computers which are running the scripts can.

There is a caveat. The computers have to be processing group policies in order to run the scripts. This may be prevented by slow link detection, the behaviour of which can be modified. It may also not be processed by computers coming into the network by remote access. A user logging into the computer by remote access can process the scripts, but a user logging into your VPN or dial-up after logging in the computer using cached credentials will not process the scripts.

IDCHPASS.BAT: Used to Change a local user identity password.

@ECHO OFF
REM USAGE: IDCHPASS username newpassword
NET USER %1 %2

IDCREATE.BAT: Used to create a local identity.
@ECHO OFF
REM USAGE: IDCREATE username password
NET USER %1 %2 /ADD

IDDELETE.BAT: Used to delete a local identity.

@ECHO OFF
REM USAGE: IDDELETE username
NET USER %1 /DELETE
IDENABLE.BAT: Used to enable or disable a local identity.

@ECHO OFF
REM USAGE: IDENABLE username YES\NO
NET USER %1 /ACTIVE:%2

IDGROUP.BAT: Used to change the group membership of a local identity, or to create or delete local groups.

@ECHO OFF
REM USAGE: IDGROUP group ADD\DELETE username
REM USERNAME IS ADDED TO OR DELETED FROM GROUP
REM USERNAME CAN BE LEFT OFF TO ADD OR DELETE GROUPS
NET LOCALGROUP %1 %3 /%2


A shoutout goes to ripvankip for giving me something to write about! ;)

Sean

Saturday, March 21, 2009

Cisco: Password Recovery


Ever lost the password to a Cisco device? I've had to do this about 4 times so far during my career (Not because I lost the password personally!). The steps are similar for many Cisco devices. These are the steps to reset the enable password on an ASA5505 Security Appliance.

The following steps were designed using a Cisco ASA 5505 Security Appliance. They are not appropriate for a Cisco PIX Firewall appliance.


1. Power-cycle your security appliance by removing and re-inserting the power plug at the power strip.
2. When prompted, press Esc to interrupt the boot process and enter ROM Monitor mode. You should immediately see a rommon prompt (rommon #0>).
3. At the rommon prompt, enter the confreg command to view the current configuration register setting: rommon #0>confreg
4. The current configuration register should be the default of 0x01 (it will actually display as 0x00000001). The security appliance will ask if you want to make changes to the configuration register. Answer no when prompted.
5. You must change the configuration register to 0x41, which tells the appliance to ignore its saved (startup) configuration upon boot: rommon #1>confreg 0x41
6. Reset the appliance with the boot command: rommon #2>boot
7. Notice that the security appliance ignores its startup configuration during the boot process. When it finishes booting, you should see a generic User Mode prompt: ciscoasa>
8. Enter the enable command to enter Privileged Mode. When the appliance prompts you for a password, simply press (at this point, the password is blank): ciscoasa>enable Password: ciscoasa#
9. Copy the startup configuration file into the running configuration with the following command: ciscoasa#copy startup-config running-config Destination filename [running-config]?
10. The previously saved configuration is now the active configuration, but since the security appliance is already in Privileged Mode, privileged access is not disabled. Next, in configuration mode, enter the following command to change the Privileged Mode password to a known value (in this case, we'll use the password system): asa#conf t asa(config)#enable password system
11. While still in Configuration Mode, reset the configuration register to the default of 0x01 to force the security appliance to read its startup configuration on boot: asa(config)#config-register 0x01
12. Use the following commands to view the configuration register setting: asa(config)#exit asa#show version
13. At bottom of the output of the show version command, you should see the following statement: Configuration register is 0x41 (will be 0x1 at next reload)
14. Save the current configuration with the copy run start command to make the above changes persistent: asa#copy run start Source filename [running-config]
15. Reload the security appliance: asa# reload System config has been modified. Save? [Y]es/[N]o:yes
Cryptochecksum: e5f81433 5493266b 4e24072 d71d5cbf
2157 bytes copied in 1.490 secs (2157 bytes/sec) Proceed with reload? [confirm]
When your security appliance reloads, you should be able to use your newly reset password to enter privileged mode.