Using ZENworks to Manage 2000 University PCs
Novell Cool Solutions: Trench
By Doug Streit
Digg This -
Posted: 13 May 2002
Doug Streit works in a university environment where he was tasked to change passwords and other account information on 2000 university-managed PCs -- not a trivial task. Read how Doug enlisted ZENworks to do all the heavy lifting.
We needed to change the password for the administrative account and perform other administrative account changes on 2000 Windows NT/2000 workstations. We also needed the process to maintain security of our passwords and account information. The changes required Administrative rights to perform and ZENworks normally uses System rights, so we could not push the change out via a NAL object or an action on the workstation without other significant changes taking place. We decided on a solution that leveraged ZENworks with simple batch files and were able to make the change on every workstation and maintain security.
We first pushed down autoadminlogon registry keys from TID-10052847 and related TIDs, which logged on and ran this batch file, then force ran a separate NAL app to clear the autoadminlogon registry keys, and a third NAL object which forced a timed shutdown so the workstation would only be logged in with the administrative account for a brief period and there was no way to stop the shutdown from happening. The initial push looks for a registry key that we push down, and if it does not see it, it will run the autoadminlogon prep. We still have it associated with our users and it is helping to keep our administrative accounts the way we want them across 2000 workstations.
- We placed the batch file and a user.dmp file with new account information in a directory and gave read/file scan rights to one DLU administrative account that we would use for the upgrade. Here's what the batch file looked like:
@echo off REM check for existence of
user net user > nul if errorlevel 1 goto end if errorlevel 2 goto end REM the account does exist, change its password net user /comment:" " REM Initially create user/Group accounts with needed settings addusers /c user.dmp /p:le REM grant log on across the network to the LAN admin group ntrights +r SeNetworkLogonRight -u > nul ntrights +r SeInteractiveLogonRight -u > nul REM update new user for LAN admin group net user /expires:< > /times:all > nul REM add new LAN group user to and groups net localgroup /add > nul net localgroup /add > nul REM remove the network access rights from the local accounts ntrights -r SeNetworkLogonRight -u administrators > nul ntrights -r SeNetworkLogonRight -u "power users" > nul ntrights -r SeNetworkLogonRight -u everyone > nul :end
- In ZENworks we configured a push which only pushed down autoadminlogon information for that account. On the next logout or shutdown, the workstations performed the autoadminlogon.
- On the account used for autoadminlogon, we associated four force run NAL objects. One cleared the autoadminlogon information. One was set to run on WindowsNT 4.0 or below to make the account changes. One was set to run on WindowsNT 5.0 and above to make the account changes. One was a forced workstation shutdown.
- In order to protect against anyone hijacking the update process (giving them administrative rights on the workstation and also the ability to view the account information) we created a force run NAL object which forced a timed shutdown of the machine whether the update ran or not, significantly hindering any possibility of compromise. Even if someone was able to stop the account update, the machine would shut down with the account information cleared from the registry.
- The upgrade was virtually transparent to users and ran with very few problems and remains associated in order to update any machine that is put on the network without the proper accounts configured.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com