\[Editor's Note: Do you have a security-related question about Windows 2000? Send it to [email protected], and you might see the answer in this column!\]
We're migrating our workstations to Win2K before deploying Active Directory (AD). How can I use Group Policy to centrally secure all our workstations and manage user desktop restrictions without deploying AD?
Without AD, you can't use the greater portion of Win2K's security and management features, including Group Policy. If you can't deploy a lightweight AD domain with your workstations, then become familiar with the Microsoft Management Console (MMC) Security Templates snap-in and the MMC Security Configuration and Analysis snap-in. Security Templates lets you create a custom security template that contains the same policies as those that you can place in a Group Policy Object (GPO) under \Computer Configuration\Windows Settings\Security Settings. Then you can use Security Configuration and Analysis to apply that template to each system, as necessary. You can use the Secedit command to automate this procedure in a workstation installation script. For more information about this procedure, search Win2K's Help file for Security Templates and Security Configuration and Analysis, then run
from the command prompt.
To manage user settings such as password-protected screen savers, use the system's local GPO and configure each system individually. Alternatively, you can set up one workstation with the configuration you need, then use an imaged installation product, such as Symantec's Norton Ghost, to install the settings on other workstations. To open the local GPO, run
from the command prompt. In MMC, select Add/Remove Snap-in from the Console menu. Click Add, and select Group Policy from the list of available snap-ins. Verify that the resulting Select Group Policy Object dialog box says Local Computer, then click Finish, Close, OK.
Why doesn't L0phtCrack work on Win2K? I need to assess password strength in my domain, but since I upgraded to Win2K, L0phtCrack just runs forever and cracks no passwords.
L0phtCrack doesn't work on systems that have Syskey enabled; in Win2K, Syskey is automatically enabled. Syskey, a command that first appeared in Windows NT 4.0 Service Pack 3 (SP3), encrypts the password hashes stored in the SAM. Consequently, Syskey defeats password crackers such as L0phtCrack when you use a copy of the SAM file (e.g., a SAM file copy from an Emergency Repair Disk—ERD) or when you use L0phtCrack's Dump Passwords From Registry command. However, if you have administrator authority, you can still crack Win2K AD domain passwords with the latest version (i.e., the March 28, 2000, version) of Pwdump2, which is available at http://www.webspan.net/~tas/pwdump2. Pwdump2 can dump password hashes from OS memory so that they become unencrypted. For more information about password cracking and about using Pwdump2, see "Cracking User Passwords in Windows 2000," http://www.WindowsITsecurity.com, InstantDoc ID 9186.
I'm running Win2K, and I don't have the User Manager utility on my desktop under Administrative Tools. How can I obtain the utility?
The Administrative Tools folder on Win2K's Start menu doesn't include a shortcut to User Manager because User Manager doesn't apply to Win2K systems and domains. Instead, you use the MMC Active Directory Users and Computers snap-in to administer Win2K domains, and you use the Local Users and Groups component of the MMC Computer Management snap-in to manage local SAMs on Win2K member servers and workstations.
However, you might need to run User Manager from a Win2K system to administer NT domains and individual NT systems. Win2K Server includes the User Manager program, and you can map to \%systemroot%\system32\usrmgr.exe to create a shortcut to the program. If you're using a Win2K Professional system, you must copy usrmgr.exe from a Win2K Server system because the file doesn't exist in the Win2K Pro OS.
Does the Encrypting File System (EFS) contain a method for using different keys to encrypt different folders? For example, users A, B, and C each have a user directory on the server. Can the server (not each user's machine) encrypt files in individual directories with the users' public keys when the users copy or drop the files into their directories?
EFS is available for encrypting files you access through a shared folder on a file server. EFS protects files you store on the disk drive; it doesn't protect data traveling over the network between a server and a workstation. Use the following procedure to give users their own encrypted folders on a server:
- Ensure that users' workstations and the file server are members of an AD domain. Use the Active Directory Users and Computers snap-in to open the file server's computer account and select the Trust computer for delegation check box. This action lets the server use the users' private encryption keys on their behalf.
- Create user accounts and their corresponding folders. For each folder, open the Properties dialog box and click Advanced. In the resulting Advanced Attributes dialog box, which Figure 1 shows, select the Encrypt contents to secure data check box, then click OK. Confirm that you want to encrypt this folder and its files and subfolders.
- Limit Modify access on each folder to its corresponding user. At this point, each user has an encrypted directory.
As users create new files in their respective directories, EFS encrypts each file's unique file encryption key (FEK) with the public key of the user's EFS certificate. Consequently, only user A and the designated data-recovery agent or agents can open files in folder A. When a user creates a file in an encryption-enabled folder, the file's encryption will depend on the user who created the file.
After initial setup, you might want to verify that encryption is working properly. To do so, log on as user A and create a file in user A's directory. Then, use Windows Explorer to open the Advanced Attributes for that file and confirm that Encrypt contents to secure data is selected. For further confirmation, temporarily grant user B Modify access to this file. Log on as user B, and try to open the file. The system will deny you access to the file because although user B has permissions to open the file, user B doesn't have the encryption key.
How can I get the IP address of computers that try to connect to my system and fail? My system is recording numerous event IDs 529 and 681, but I can't figure out where the logon attempts are coming from.
Event ID 529 is in the Logon/Logoff category and shows that someone failed to log on to the local system because of a bad password or username. This event category in Win2K and NT doesn't record IP addresses, because someone could be connecting through NetBEUI or IPX instead of TCP/IP.
However, Win2K's Account Logon audit category, which tracks authentication events on Win2K domain controllers (DCs), supplies the IP address of any Kerberos authentication event. For example, if all your systems run Win2K and therefore use Kerberos, the DC logs event ID 675 when domain account authentication fails because a user supplies a bad password during a workstation or server logon attempt. If a workstation or server involved in the logon runs NT, the OS uses NT LAN Manager (NTLM) instead of Kerberos for authentication. When an NTLM domain logon fails, the Win2K DC logs event ID 681 and an error code (e.g., error code 3221225578 shows that the username is correct but the password is incorrect). Because NTLM authentication can occur through IPX or NetBEUI, event ID 681 records the workstation's NetBIOS name, not its IP address.
To discover which IP address failed logons come from, you must upgrade your systems to Win2K or use a network sniffer. If the NTLM logon events you're concerned about are coming from the Internet, consider blocking NTLM and NetBIOS at the firewall, unless your application requires them.