Windows Admin Scripting Little Black Book- P18 ppsx

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the following: @ECHO OFF COPY SUSS.EXE %WINDIR%\SYSTEM32 %WINDIR%\SYSTEM

Basicsv.inf—Default server

Basicwk.inf—Default workstation

These three basic security templates contain the standard security settings for each system

Compatws.inf—Compatible workstation or server

The compatibility template contains lower security settings to allow regular users maximum control of installed applications Applying the compatibility template will remove all users from the power users group

Dedicadc.inf—Dedicated domain controller

The dedicated template contains security settings for domain controllers that will not be running server-based

applications

Hisecdc.inf—Highly secure domain controller

Hisecws.inf—Highly secure workstation or server

The high security templates provide the maximum security settings for the system Applying this template on a Windows 2000 system will restrict that system to communicating only with other Windows 2000 systems

Securedc.inf—Secure domain controller

Securews.inf—Secure workstation or server

The secure templates are the recommended security settings

Important Security Practices

Here is a list of several security practices to help protect your environment:

Administrators should always lock their system when not in use This should be a top priority for administrators

It takes only a few seconds of distraction for an intruder to go to work under your logged-on account

Do not allow other accounts to access or log on to an administrator’s system If another user can access your system (even if you are not logged on), he or she can potentially extract passwords, grab your files, and more Always use the latest security patches and service pack It seems Microsoft is always releasing security

patches and service packs to combat system exploits These patches don’t do any good unless they are actually loaded onto your system

Use the maximum password length allowed Microsoft Windows NT/2000 uses a maximum password length of

14 characters To slow down brute-force password utilities, you should always use the maximum password length allowed

Passwords should be a mix of upper- and lowercase, letters, and numbers The more complex your passwords are, the longer it takes for a password-cracking program to guess a password

Do not use dictionary-based passwords (for example, MyKids) Dictionary-based passwords are the easiest and usually the first passwords determined through password-guessing utilities

Use the New Technology File System (NTFS) In addition to increased reliability, NTFS provides dramatically increased security compared to the other Windows file systems

Set your system BIOS to boot from the hard drive only Even if you use NTFS, a hacker can access all your protected files by booting from removable media

Setting the Boot Timeout

Allowing users to choose other operating systems (OS) at bootup is a security risk because the other operating systems can be used to bypass or defeat Windows security

Setting the Boot Timeout Using KiXtart

To set the boot timeout using KiXtart, proceed as follows:

1 Create a new directory to store all files included in this example

2 Download and extract the latest version of KiXtart, from www.microsoft.com, to the new directory

3 Select Start|Run and enter “kix32 scriptfile”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the

following:

$File = "C:\boot.ini"

$RCode = SetFileAttr($File,128)

WriteProfileString($File, "boot loader", "timeout", "0")

$RCode = SetFileAttr($File,1)

This script first clears any file attributes on BOOT.INI, modifies the boot timeout, and then marks the file as read-only

Setting the Boot Timeout Using WMI

To set the boot timeout to zero using WMI, proceed as follows:

1 Create a new directory to store all files included in this example

2 Download and install the latest version of WMI and Windows Script Host, from www.microsoft.com, to the new directory

3 Select Start|Run and enter “cscript scriptfile.vbs”

Here, scriptfile is the full path and file name of a script file that contains the following:

On Error Resume Next

Computer = InputBox("Enter the computer name", "Boot Timeout"

, "localhost")

Set Boot = GetObject("winmgmts:{impersonationLevel=

impersonate}!\\" & Computer & "\root\cimv2")

ExecQuery("select * from Win32_ComputerSystem")

For each Item in Boot

Item.SystemStartupDelay = 0

Item.Put_()

Next

Note

The highlighted code above must be placed on one line

Removing POSIX and OS/2 Subsystems

By default, Windows NT/2000 includes three environment subsystems: OS/2, POSIX, and Win32 subsystems Originally developed by Microsoft, OS/2 is IBM’s operating system for the personal computer POSIX stands for

Portable Operating System Interface for Unix and is a set of interface standards used by developers to design applications and operating systems

Win32 is the main subsystem used by Windows, whereas the others are merely present for compatibility with other operating systems and applications When Windows NT was submitted for evaluation, the POSIX and OS/2 subsystems were disabled to reduce the size of the evaluation You should remove these subsystems to comply to C2-level security To remove the POSIX and OS/2 subsystems from the command line, proceed as follows:

1 Create a new directory to store all files included in this example

2 For Windows NT, obtain RMDIR.EXE from the Resource Kit and copy it to the new directory

3 Start a command prompt and enter “scriptfile.bat”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the

following:

@ECHO OFF

RMDIR /Q /S "%WINDIR%\System32\OS2"

DEL /F /Q "%WINDIR%\SYSTEM32\PSXDLL.DLL"

DEL /F /Q "%WINDIR%\SYSTEM32\PSXSS.EXE"

DEL /F /Q "%WINDIR%\SYSTEM32\POSIX.EXE"

DEL /F /Q "%WINDIR%\SYSTEM32\PSXSS.EXE"

DEL /F /Q "%WINDIR%\SYSTEM32\OS2.EXE"

DEL /F /Q "%WINDIR%\SYSTEM32\OS2SRV.EXE"

DEL /F /Q "%WINDIR%\SYSTEM32\OS2SS.EXE"

ECHO REGEDIT4 > C:\OS2.REG

ECHO [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

OS/2 Subsystem for NT] >> C:\OS2.REG

REGEDIT /S C:\OS2.REG

DEL /F /Q C:\OS2.REG

Note

The highlighted code above must be placed on one line

Tip

You can perform the same removal using the C2Config Tool, discussed earlier in this chapter

Removing Administrative Shares

Administrative shares are hidden shares created by the system to allow administrators to access files remotely Although these shares are hidden, they are no secret to the savvy user and should be removed for maximum security To remove administrative shares, proceed as follows:

1 Create a new directory to store all files included in this example

2 Download and install the latest version of Windows Script Host, from www.microsoft.com, to the new directory

3 Select Start|Run and enter “cscript scriptfile.vbs”

Here, scriptfile is the full path and file name of a script file that contains the following:

On Error Resume Next

Set SHELL = CreateObject("WScript.Shell")

Set Drives = FSO.Drives

For Each Drive in Drives

SHELL.Run "NET SHARE " & Drive & "\ /D", 0, False

SHELL.Run "NET SHARE " & Drive & "\WINNT /D", 0, False

Next

Warning

Certain programs use administrative shares and might not work if they are removed

Locking Down Administrative Tools

Administrative tools, such as User Manager and REGEDT32, should be locked down for administrative access only

To lock down various administrative tools, proceed as follows:

1 Create a new directory to store all files included in this example

2 Copy XCACLS.EXE from the resource kit to the new directory

3 Start a command prompt and enter “scriptfile.bat”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the

following:

@ECHO OFF

XCACLS "%WINDIR%\POLEDIT.EXE" /G Administrators:F;F /Y

XCACLS "%WINDIR%\REGEDIT.EXE" /G Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\CACLS.EXE" /G Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\CLIPBRD.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\NCADMIN.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\NTBACKUP.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\REGEDT32.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\RASADMIN.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\RDISK.EXE" /G Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\SYSKEY.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\USRMGR.EXE" /G

Administrators:F;F /Y

XCACLS "%WINDIR%\SYSTEM32\WINDISK.EXE" /G

Administrators:F;F /Y

Note

The highlighted code above must be placed on one line Although this script prevents an ordinary

user from accessing these tools, they could always bring them in and run them from an alternate source, such as a floppy disk

Using the SYSKEY Utility

Not too long ago in a galaxy not too far away, a small group of rebels called LOpht Heavy Industries created a tool called LOPHTCRACK.EXE to extract passwords from an encrypted hash within the registry or an emergency repair disk (ERD) Provided with Service Pack 3, SYSKEY is a utility that allows you to encrypt the hash with 128-bit cryptography, which prevents password extraction by the Lophtcrack utility

Note

SYSKEY encryption is enabled by default on Windows 2000 systems

To enable SYSKEY to encrypt the hash locally, proceed as follows:

1 Download and install AutoIt, from www.hiddensoft.com/autoit

2 Select Start|Run and enter “autoit2 scriptfile”

Here, autoit2 is the complete path and name of the AUTOIT executable, and scriptfile is a text file that contains the

following:

RUN, C:\\WINNT\\SYSTEM32\\SYSKEY.EXE

WINWAIT, Securing the Windows, ,5

SEND, !E{ENTER}

WINWAIT, Confirm, ,5

IfWinNotExist, Confirm, , Exit

SEND, {TAB}{ENTER}

WINWAIT, Account Database, ,5

SEND, {TAB}{ENTER}

WINWAIT, Success, ,5

SEND, {ENTER}

Warning

There is a bug with the keystream used by the Windows NT version of SYSKEY For more information and to obtain the security patch, see the Microsoft TechNet article Q248183

Running Commands under Different Security Contexts

Every time someone logs on to the network with an administrator account, it creates a big security risk Malicious ActiveX components from the Web, Trojan horses, or even a hidden batch file can wipe out an entire server,

database, and more when run under administrative privileges If you think about it, you don’t really need

administrative privileges when you are checking your mail or surfing the Net A common solution to this security problem is to log on with a regular user account and use a utility to run trusted applications under the security context

of an administrative account

A security context specifies all the rights and privileges granted to a user For administrators, this security context allows them to manage users, groups, trusts, and domains The process of switching to the security context of another user is known as impersonation Impersonation is mostly used by system services

Installing the SU Utility

Named after the Unix SU command, the SU (Switch User) utility is an NT resource kit utility that allows users to run applications under the security context of a different user This utility runs as a service and is commonly used within logon script for locked-down environments To install the SU utility, proceed as follows:

1 Create a new directory to store all files included in this example

2 For Windows NT, obtain RMDIR.EXE from the Resource Kit and copy it to the new directory

3 Start a command prompt and enter “scriptfile.bat”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the

following:

@ECHO OFF

COPY SUSS.EXE %WINDIR%\SYSTEM32

%WINDIR%\SYSTEM32\SUSS -INSTALL

Tip

A common mistake when installing the SU utility is not installing it from a local copy of the SUSS.EXE Installing straight from the Resource Kit CD will set the service to always look to run the SU utility from the CD

Running the SU Utility with a Password Environment Variable

The SU utility can use an environment variable called SU_PASSWORD to access the account’s password Once the command has completed, the variable can be removed To run the SU utility using an environment variable, proceed

as follows:

1 Create a new directory to store all files included in this example

2 Install the SU utility from the Windows NT resource kit and copy SU.EXE to the new directory

3 Start a command prompt and enter “scriptfile.bat”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the

following:

@ECHO OFF

SET SU_PASSWORD=password

SU username command domain

SET SU_PASSWORD=

Here, password is the password of the domain\username with rights to run the specified command

Running the SU Utility with a Password Text File

Another common method is to store the password in a text file and redirect it to the SU utility To redirect the

password from a text file to the SU utility, proceed as follows:

1 Create a new directory to store all files included in this example

2 Install the SU utility from the Windows NT resource kit

3 Start a command prompt and enter “scriptfile.bat”

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the following:

@ECHO OFF

SU username command domain < password.txt

Here, password.txt is the text file containing the password of the domain\username, with rights to run the specified command

Using the Windows 2000 RunAs Command

Windows 2000 includes the utility RUNAS.EXE, which allows users to run applications under the security context of a different user This utility is integrated into the Windows shell, which allows you to set up shortcuts to utilize the

RUNAS utility The basic syntax of the RUNAS utility is:

RUNAS /commands program

Here, program is the shortcut, Control Panel applet, MMC console, or application to run The available commands

are:

/ENV—Keep the current environment

/NETONLY—Specifies for remote access only

/PROFILE—Loads the specified user’s profile

/USER:username—Specifies the username to run application as Valid name formats are domain\user or

user@domain

Note

Once you have entered the command, you will be prompted for the password associated with the account

To start an instance of User Manager using an administrator account called ADMIN@MYDOMAIN.COM, enter the following:

RUNAS /USERNAME:ADMIN@MYDOMAIN.COM USRMGR

Using the SECEDIT Utility

The SECEDIT.EXE utility is the command-line version of the Microsoft security configuration editor that allows you to run security configuration and analysis from the command line

Running a Security Analysis

The basic syntax to run an analysis using SECEDIT is as follows:

secedit /analyze /commands

Here, the available commands are:

/DB filename—Required, specifies the database to compare against

/CFG filename—Valid with /DB, specifies the security template to be imported

/LOG logpath—Specifies the log file to use

/VERBOSE—Specifies to include more detail to the log or output

/QUIET—Runs the analysis with no screen or log output

Here is an example to run a system analysis against the high security template for a domain controller:

Secedit /analyze /DB "%WINDIR%\Security\Database\hisecdc.sdb"

/CFG "%WINDIR%\Security\Templates\hisecdc.inf"

/LOG "%WINDIR%\Security\Logs\hisecdc.log" /VERBOSE

Note

The code above must be placed on one line

Reapplying a Group Policy

To reapply a local or user policy, start a command prompt and enter the following:

SECEDIT /REFRESHPOLICY policy /ENFORCE

Here, /ENFORCE forces the policy to be reapplied, even if no security changes were found

Applying a Security Template

The basic syntax to apply a security template using SECEDIT is as follows:

secedit /configure /commands

Here, the available commands are:

/AREAS name—Specifies the specific security areas to apply, where name is:

FILESTORE—Local file security

GROUP_MGMT—Group settings

REGKEYS—Local registry security

SECURITYPOLICY—Local or domain policy

SERVICES—Local services security

USER_RIGHTS—User’s rights and privileges

/CFG filename—Valid with /DB; specifies the security template to be imported

/DB filename—Required; specifies the database containing the template to be applied

/OVERWRITE—Valid with /CFG; specifies to overwrite templates in the database

/LOG logpath—Specifies the log file to use

/VERBOSE—Specifies to include more detail to the log or output

/QUIET—Runs the analysis with no screen or log output

Fixing Security on a Windows NT to Windows 2000 Upgrade

When you upgrade from Windows NT to Windows 2000, the security settings on the system are not modified This means none of the intended Windows 2000 security settings are implemented To apply the Windows 2000 basic security settings, start a command prompt and enter the following:

Secedit /configure

/db "%WINDIR%\Security\Database\basicwk.sdb"

/cfg "%WINDIR%\Security\Templates\basicwk.inf"

/log "%WINDIR%\Security\Logs\basicwk.log"

/verbose

Note

The code above must be placed on one line

Exporting Security Settings

The basic syntax to export security settings using SECEDIT is as follows:

secedit /export /commands

Here, the available commands are:

/AREAS name—Specifies the specific security areas to export, where name is:

FILESTORE—Local file security

GROUP_MGMT—Group settings

REGKEYS—Local registry security

SECURITYPOLICY—Local or domain policy

SERVICES—Local services security

USER_RIGHTS—User’s rights and privileges

/DB filename—Required; specifies the database containing the template to be exported

/CFG filename—Valid with /DB; specifies the security template to export to

/MERGEDPOLICY—Valid with /CFG; specifies to overwrite templates in the database

/LOG logpath—Specifies the log file to use

/VERBOSE—Specifies to include more detail to the log or output

/QUIET—Runs the analysis with no screen or log output

Here is an example of how to export the local registry security area to the registry template:

Secedit /export /mergedpolicy

/db "%WINDIR%\Security\Database\security.sdb"

/cfg "%WINDIR%\Security\Templates\registry.inf"

/log "%WINDIR%\Security\Logs\registry.log"

/verbose

Using the PASSPROP Utility

PASSPROP is an NT resource kit utility that allows you to modify domain password policies from the command line The basic syntax of the PASSPROP utility is:

PASSPROP /commands

Here, the available commands are:

/ADMINLOCKOUT—Allows the administrator account to lock out for remote logons

/COMPLEX—Forces passwords to contain numbers or symbols and upper- and lowercase letters

/NOADMINLOCKOUT—Does not allow the administrator account to be locked out

/SIMPLE—Allows simple passwords

For example, to implement a strong domain password policy, you would use the following command:

PASSPROP /ADMINLOCKOUT /COMPLEX

Using the NET ACCOUNTS Command

The built-in NET command has an ACCOUNTS parameter to modify the password and logon requirements for the local computer or a specified domain The basic syntax of the NET ACCOUNTS utility is:

NET ACCOUNTS /commands

Here, the available commands are:

/DOMAIN—If used, performs the specified operations on the primary domain controller of the current domain;

otherwise, performs the operations on the local computer

/FORCELOGOFF:min—Sets the number of minutes before a user session is terminated where min is either

the number of minutes or NO to specify no forced logoff

/MAXPWAGE:days—Specifies the maximum duration a password is valid where days is either the number of

days (1 through 49,710) or UNLIMITED to set no maximum time

/MINPWAGE:days—Specifies the minimum duration before a user can change his or her password, where days is either the number of days (1 through 49,710) or UNLIMITED to set no time limit This value must be less

than the MAXPWAGE

/MINPWLEN:length—Specifies the minimum password length

/SYNC—Forces backup domain controllers to synchronize their password and logon requirements with those

set on the primary domain controller

/UNIQUEPW:changes—Specifies that users cannot repeat the same password for the specified amount of

password changes (0 through 24)

For example, to modify the logon and password requirements using the NET ACCOUNTS command, you would enter the following command:

NET ACCOUNTS /DOMAIN /MAXPWAGE:30 /MINPWAGE:UNLIMITED

/MINPWLEN:14

Note

The code above must be placed on one line

Tip

When the administrator has specified a forced logoff, the user receives a warning that a domain controller will force a logoff shortly

Managing Security through ADSI

Active Directory Services Interfaces provides another medium to control security In Chapter 8, you learned how to manage shares, groups, and user accounts through ADSI In the following section, you will learn how to manage security through ADSI

Setting the Minimum Password Length

For maximum security, you should set your domain password minimum length to the maximum value, 14 To set the minimum password length for the domain using ADSI, proceed as follows:

1 Create a new directory to store all files included in this example

2 Download and install the latest version of ADSI and Windows Script Host, from www.microsoft.com, to the new directory

3 Select Start|Run and enter “cscript scriptfile.vbs”

Here, scriptfile is the full path and file name of a script file that contains the following:

On Error Resume Next

Set objDomain = GetObject("WinNT://Domain")

objDomain.Put "MinPasswordLength", max

objDomain.SetInfo

Here, domain is the name of the domain, and max is the maximum password length to set Again, you should set max equal to 14 for maximum security

1

Note

The maximum password length allowed by Windows NT/2000 is 14 characters

Setting the Password Age

For maximum security, you should implement a policy to force users to change their password regularly To set the password age for the domain using ADSI, proceed as follows:

Create a new directory to store all files included in this example

2 Download and install the latest version of ADSI and Windows Script Host, from www.microsoft.com, to the new directory

3 Select Start|Run and enter “cscript scriptfile.vbs”