it-admin

Windows Shared Permissions vs NTFS Security

2010-11-03T23:37:00.000-07:00

http://www.copyrunstart.net/understanding-windows-shared-permissions-vs-ntfs-security/

General Information:

■Windows 9x/ME workstations cannot access NTFS partitions
■Shared permissions only apply to shares connected to over the network
■NTFS Security applies to users both locally and across the network
■When there’s a difference between the sharing permission and the NTFS security permission, the most restrictive setting wins
■There are two types of NTFS permissions, file and folder
■Deny will always take precendence over allow permissions.
First, let's cover the definitions of security levels and permissions. We'll start with Shared permissions, there are only 3

1.Read: View files and subdirectories. Execute applications. No changes can be made.
2.Change: Includes read permissions and the ability to add, delete or change files or subdirectories
3.Full Control: Abilities to perform any and all functions on all files and folders within the share.

Now, let's cover what the 5 NTFS file permissions are and what they allow, you should notice that each level of security builds upon the one before it.

1.Read: This allows the user or group to read the file and view its attributes**, ownership, and permissions set.
2.Write: This allows the user or group to overwrite the file, change its attributes, view its ownership, and view the permissions set.
3.Read & Execute: This allows the user or group to run and execute the application. In addition, the user can perform all duties allowed by the Read permission.
4.Modify: This allows the user or group to modify and delete a file including perform all of the actions permitted by the Read, Write, and Read and Execute NTFS file permissions.
5.Full Control: This allows the user or group to change the permission set on a file, take ownership of the file, and perform actions permitted by all of the other NTFS file permissions.

Next, are the the 6 NTFS folder permissions

1.Read: This allows the user or group to view the files, folders, and subfolders of the parent folder. It also allows the viewing of folder ownership, permissions, and attributes of that folder.
2.Write: This allows the user or group to create new files and folders within the parent folder as well as view folder ownership and permissions and change the folder attributes.
3.List Folder Contents: This allows the user or group to view the files and subfolders contained within the folder.
4.Read & Execute: This allows the user or group to navigate through all files and subfolders including perform all actions allowed by the Read and List Folder Contents permissions.
5.Modify: This allows the user to delete the folder and perform all activities included in the Write and Read & Execute NTFS folder permissions.
6.Full Control: This allows the user or group to change permissions on the folder, take ownership of it, and perform all activities included in all other permissions.
Earlier in the General Information list the last bullet mentioned deny takes precedence over allow. This is in reference to NTFS special permission, which are used when your file and folder permissions just aren't specific enough. Here's all 13of them...

1. Traverse Folder/Execute File: This allows or denies a user to browse through a folder's subfolders and files where he would otherwise not have access. In addition, it allows or denies the user the ability to run programs within that folder.

2.List Folder/Read Data: This allows or denies the user to view subfolders and fill names in the parent folder. In addition, it allows or denies the user to view the data within the files in the parent folder or subfolders of that parent.
3.Read Attributes: This allows or denies a user to view the standard NTFS attributes of a file or folder.
4.Read Extended Attributes: This allows or denies the user to view the extended attributes of a file or folder, which can vary due to the fact that they are defined by the programs themselves.
5.Create Files/Write Data: This allows or denies the user the right to create new files in the parent folder. In addition, it allows or denies the user to modify or overwrite existing data in a file.
6.Create Folders/Append Data: This allows or denies the user to create new folders in the parent folder. In addition, it allows or denies the user the right to add data to the end of files. This does not include making changes to any existing data within a file.
7.Write Attributes: This allows or denies the ability to change the attributes of a files or folder, such as Read-Only and Hidden.
8.Write Extended Attributes: This allows or denies a user the ability to change the extended attributes of a file or folder. These attributes are defined by programs and may vary.
9.Delete Subfolders and Files: This allows or denies the deleting of files and subfolder within the parent folder. It also true that if this permission is assigned files and subfolders can be deleted even if the Delete special access permission has not been granted.
10.Delete: This allows or denies the deleting of files and folders. If the user does not have this permission assigned but does have the Delete Subfolders and Files permission, she can still delete.
Read Permissions This allows or denies the user the ability to read the standard NTFS permissions of a file or folder.
11.Change Permissions: This allows or denies the user the ability to change the standard NTFS permissions of a files or folder.
12.Take Ownership: This allows or denies a user the ability to take ownership of a file or folder. The owner of a file or folder can change the permissions on the files and folders she owns, regardless of any other permission that might be in place.
13.Synchronize: This allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies to only multithreaded, multiprocessing programs.
So now that you have an idea of what defines these, what are the best practices, the best practice should be to keep access and administration to a minimum. Secure your windows shares with the minimum access needed. Utilize NTFS to further minimize access to your folders and files. Use groups for folders if appropriate as opposed to single user settings. Best of luck!

**Atributes are part of the file and include Read-Only, Hidden, Archive, and System

1.Read Only: A file that is marked Read Only cannot be altered. It can be read, but it cannot be changed or deleted.2.Hidden: By default, hidden files do not appear in a directory listing. (Normally power users uncheck "hide systems files in Folder Settings).
3.Archive: Every time the user or the software modifies a file, then the archive bit will be marked. This tells you when the file was last modified.
4.System: System files are files flagged for use by the operating system and are not usually displayed in a directory listing. System files should not be modified or deleted.
You also want to be careful of contradictory permissions, a great article no this topic can be found here. (http://searchwindowssecurity.techtarget.com/tip/0,289483,sid45_gci1194946,00.html)

In summary, it recommends "assigning everyone full control at the share level and using NTFS permissions to secure the individual files or folders." This is considered a security risk to many, however, it may make it easier for you to keep track of what you're sharing to whom.

Also, if you want to play it safe and use permissions at both the NTFS and Share level, Server Check is a tool that is part of the Server 2003 Resource kit, and it works for Windows 2003, 2000, and XP. It is a command line interface that will let you know what permissions are defined for each shared resource

Sources:

http://www.home-network-help.com/folder-private.html

http://articles.techrepublic.com.com/5100-6346-5032876.html

http://www.mcmcse.com/microsoft/guides/ntfs_and_share_permissions.shtml

http://kb.iu.edu/data/aift.html

http://www.windowsitlibrary.com/Content/592/1.html

http://www.proprofs.com/certification/comptia/a-plus/study-guide/wbt13/8004.shtml

Dual-Booting Vista and XP*

2009-01-02T08:42:00.000-08:00

While Vista can upgrade your current version of XP, you may wish to try a dual-boot configuration. This leaves your XP installation alone and installs Vista in another partition, either an existing one or one you will create just for Vista. Now Vista comes with it's own partitioning tools that can be accessed during setup as run from the Vista bootable DVD. I have never used these myself, preferring Acronis Disk Director to manage my partitions. whatever tool you prefer, you will need a good sized partition, at least 15GB or more, depending on how many programs you will install in Vista later.

Once you have your partition, you can install Vista in one of 2 ways: either start the install from within XP (telling Vista to not perform an upgrade) or you can boot with the Vista DVD, making sure that your BIOS is configured to boot your DVD drive before the hard drive. I prefer to boot from the DVD.

Vista's installation program is fairly straightforward, and if you have installed XP from scratch before, Vista's initial setup screens will be quite familiar. You are presented with a list of partitions to chose from, and once you choose the partition, if you would like to format it or not.

Once Vista is installed, you will notice a boring black & white text screen that presents itself when the PC is restarted. This is Vista's boot manager. You have about 30 seconds to choose between "Earlier version of Windows" (that would be XP) and "Microsoft Windows" (that would be Vista):

Vista has done away with boot.ini and now has something way more complex: the Boot Configuration Data store.

One nice feature is that, if you decide you no longer want Vista, you simply go to the "Change settings" tab and click "Delete Vista Boot Loader!". This 'reactivates' boot.ini in the XP partition and when you reboot, Vista's Boot Manager is gone and you will boot directly into XP. You can then format the Vista partition if you wish. Alternatively, you can access VistaBootPRO from within XP and accomplish the same task.

Note regarding Vista's Bootloader: Each time you install a version of Windows, it rewrites the MBR to call its own boot loader. If you install Windows Vista as a second operating system on a PC where Windows XP is already installed, the Windows Vista boot menu incorporates the options from the older boot menu. But if you install a fresh copy of Windows XP on a system that is already running Windows Vista, you’ll overwrite the MBR with one that doesn’t recognize the Windows Vista Boot Loader. To repair the damage, open a Command Prompt window
in the older operating system and run the following command from the Windows Vista DVD, substituting the letter of your drive for here.
:\Boot\ Bootsect.exe –NT60 All

When you restart, you should see the Windows Vista menu. To restore the menu entry for your earlier version of Windows, open an elevated Command Prompt and enter this command:

Bcdedit –create {ntldr} –d “Menu description goes here”

Substitute your own description for the placeholder text. The next time you start your computer, the menus should appear as you intended.

http://www.windowstalk.org/dual_boot_vista.htm
http://www.windowstalk.org/dual_boot_part2.htm

Windows Security Log Encyclopedia

2006-02-28T07:25:00.000-08:00

www.ultimatewindowssecurity.com/encyclopedia.html

Event ID OS: Title:
512 All Versions Windows NT is starting up
513 XP, Win2003 Windows NT is shutting down
514 All Versions An authentication package has been loaded by the Local Security Authority
515 All Versions A trusted logon process has registered with the Local Security Authority
516 All Versions Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits
517 All Versions The audit log was cleared
518 All Versions An notification package has been loaded by the Security Account Manager
519 Win2003 A process is using an invalid local procedure call (LPC) port
520 Win2003 The system time was changed
528 All Versions Successful Logon
529 All Versions Logon Failure - Unknown user name or bad password
530 All Versions Logon Failure - Account logon time restriction violation
531 All Versions Logon Failure - Account currently disabled
532 All Versions Logon Failure - The specified user account has expired
533 All Versions Logon Failure - User not allowed to logon at this computer
534 All Versions Logon Failure - The user has not been granted the requested logon type at this machine
535 All Versions Logon Failure - The specified account's password has expired
536 All Versions Logon Failure - The NetLogon component is not active
537 All Versions Logon failure - The logon attempt failed for other reasons
538 All Versions User Logoff
539 All Versions Logon Failure - Account locked out
540 XP, Win2000, Win2003 Successful Network Logon
552 Win2003 Logon attempt using explicit credentials
560 All Versions Object Open
561 All Versions Handle Allocated
562 All Versions Handle Closed
563 All Versions Object Open for Delete
564 All Versions Object Deleted
565 Win2000 Object Open (Active Directory)
Win2003 Object Open (W3 Active Directory)
566 Win2003 Object Operation (W3 Active Directory)
567 Win2003 Object Access Attempt
576 All Versions Special privileges assigned to new logon
577 All Versions Privileged Service Called
578 All Versions Privileged object operation
592 All Versions A new process has been created
593 All Versions A process has exited
594 All Versions A handle to an object has been duplicated
595 All Versions Indirect access to an object has been obtained
600 All Versions A process was assigned a primary token
601 Win2003 Attempt to install service
602 Win2003 Scheduled Task created
608 Win2003 User Right Assigned
609 All Versions User Right Removed
610 Win2000 New Trusted Domain
Win2003 New Trusted Domain
611 Win2000 Removing Trusted Domain
Win2003 Trusted Domain Removed
612 All Versions Audit Policy Change
613 All Versions IPSec policy agent started
614 All Versions IPSec policy agent disabled
615 Win2000 IPSEC PolicyAgent Service
Win2003 IPSec Services
616 Win2000 IPSec policy agent encountered a potentially serious failure
617 Win2000, Win2003, DC Kerberos Policy Changed
618 XP, Win2000, Win2003 Encrypted Data Recovery Policy Changed
619 All Versions Quality of Service Policy Changed
620 Win2000 Trusted Domain Information Modified
Win2003 Trusted Domain Information Modified
621 Win2003 System Security Access Granted
622 Win2003 System Security Access Removed
623 Win2003 Per User Audit Policy was refreshed
624 Win2000, Win2003 User Account Created
625 Win2003 Per user auditing policy set for user
Win2000, DC User Account Type Change
626 Win2000, Win2003 User Account Enabled
627 Win2000, Win2003 Change Password Attempt
628 Win2000, Win2003 User Account password set
629 Win2003 User Account Disabled
630 Win2000, Win2003 User Account Deleted
631 Win2000, Win2003, DC Group created
632 Win2000, Win2003, DC Group member added or removed
633 Win2000, Win2003, DC Group member added or removed
634 Win2000, Win2003, DC Group deleted
635 Win2000, Win2003 Group created
636 Win2000, Win2003 Group member added or removed
637 Win2000, Win2003 Group member added or removed
638 Win2000, Win2003 Group deleted
639 Win2000, Win2003 Group changed
640 All Versions General Account Database Change
641 Win2000, Win2003, DC Group changed
642 Win2000, Win2003 User Account Changed
643 Win2000 Domain Policy Changed
Win2003 Domain Policy Changed
644 All Versions User Account Locked Out
645 Win2000, Win2003, DC Computer Account Created
646 Win2000, Win2003, DC Computer Account Changed
647 Win2000, Win2003, DC Computer Account Deleted
648 Win2000, Win2003, DC Group created
649 Win2000, Win2003, DC Group changed
650 Win2000, Win2003, DC Group member added or removed
651 Win2000, Win2003, DC Group member added or removed
652 Win2000, Win2003, DC Group deleted
653 Win2000, Win2003, DC Group created
654 Win2000, Win2003, DC Group changed
655 Win2000, Win2003, DC Group member added or removed
656 Win2000, Win2003, DC Group member added or removed
657 Win2000, Win2003, DC Group deleted
658 Win2000, Win2003, DC Group created
659 Win2000, Win2003, DC Group changed
660 Win2000, Win2003, DC Group member added or removed
661 Win2000, Win2003, DC Group member added or removed
662 Win2000, Win2003, DC Group deleted
663 Win2000, Win2003, DC Group created
664 Win2000, Win2003, DC Group changed
665 Win2000, Win2003, DC Group member added or removed
666 Win2000, Win2003, DC Group member added or removed
667 Win2000, Win2003, DC Group deleted
668 Win2000, Win2003, DC Group Type Changed
669 All Versions Add SID History
670 All Versions Add SID History
671 Win2003 User Account Unlocked
672 Win2000 Authentication Ticket Granted
Win2003 Authentication Ticket Request
673 Win2000 Service Ticket Granted
Win2003 Service Ticket Request
674 Win2000 Ticket Granted Renewed
Win2003 Service Ticket Renewed
675 Win2000, Win2003, DC Pre-authentication failed
676 Win2000 Authentication Ticket Request Failed
Win2003 Authentication Ticket Request Failed
677 Win2000 Service Ticket Request Failed
Win2003 Service Ticket Request Failed
678 All Versions Account Mapped for Logon by
679 Win2000 The name: %2 could not be mapped for logon by: %1
680 Win2000 Account Used for Logon by
Win2003 Logon attempt
681 Win2000 The logon to account: %2 by: %1 from workstation: %3 failed
Win2003 The logon to account: %2 by: %1 from workstation: %3 failed
682 XP, Win2000, Win2003 Session reconnected to winstation
683 XP, Win2000, Win2003 Session disconnected from winstation
684 Win2003 Set the security descriptor of members of administrative groups
685 Win2003 Account Name Changed
686 Win2003 Password of the following user accessed
687 All Versions Application group operation
688 Win2003 Application group operation
689 Win2003 Application group operation
690 Win2003 Application group operation
691 Win2003 Application group operation
692 All Versions Application group operation
693 Win2003 Application group operation
694 Win2003 Application group operation
695 Win2003 Application group operation
696 Win2003 Application group operation
806 Win2003 Per User Audit Policy was refreshed
807 Win2003 Per user auditing policy set for user

WMIC

2006-01-10T02:52:00.000-08:00

What is WMI?
Many network administrators have heard of Windows Management Instrumentation (WMI). Simply put, WMI represents a major change in the way that application applications interact with the Windows family of Operating Systems. In the past, developers were required to write complicated code to perform even the simplest tasks or collect basic information about computers on the network. This was a difficult task even for the most seasoned programmer. WMI changes this approach to become simpler and more consistent

WMI is a layer of software that runs as service. It functions in much the same way a database does. A series of providers abstract and expose the operating system. These providers allow developers to reference a multitude of classes. The classes represent things such as your network configuration, running processes, installed services, hardware and software. In many cases these providers expose data structures that resemble tables, making code that interacts with them simple and easy to write.

WMI is also important for network administrators. This new model has resulted in a new generation of command line tools, management applications and scripts. Commands such as the EVENTQUERY, SC, and TYPEPERF all interact with the computer via WMI. Applications such as Microsoft Operations Manager (MOM) and Systems Management Server (SMS) use WMI to query and manage systems from a central location. WMI can even be used in conjunction with group policy on Windows Server 2003 and Windows XP Professional as an additional filter when applying GPO’s.

What is WMIC
The WMI command-line (WMIC) is a simplified command line interface for working with WMI. Using WMIC, you can manage multiple computers running different versions of Microsoft Windows. WMIC features a non-blocking interface that allows it to be used by scripts and batch files. Some of the capabilities of WMIC are:

Commands based on aliases making common tasks quick and easy to perform.
Ability to work with the local computer, a remote computer, or a collection of remote computers.
Customizable output formats and aliases.
Used to manage any computer running WMI.

Using WMIC
Before you being to work with WMIC, you will need to adjust your command prompt to avoid wrapping of output. Some WMIC commands produce very large outputs that are difficult to read. There are two adjustments that I recommend, both of which are found on the properties of your command prompt window. Simply configure your command prompt window as shown below.

Figure 1: Adjusting the font size

Figure 2: Adjusting the Screen Buffer Size
To use WMIC you must know a little about how it works. WMIC includes a series of “canned” WMI queries known as aliases. These aliases represent the most common pieces of information that administrators would gather from computers. You can view the contents of any alias by simply typing WMIC following by the name of the alias. For example, “WMIC QFE” will list all hotfixes and service packs that are installed on the computer. A complete list of aliases can be found by typing “WMIC /?”. The table below lists some of the more useful aliases

Alias
Use

Computersystem
Information found in the system properties such as the computer name, make, model, and currently logged on user.

Csproduct
Computer system product information. This contains the computers UUID, which can be used with deployment solutions such as RIS.

Pagefile and Pagefileset
Information on the current size and usage of page files.

Memphysical
Memory capacity of the computer and current physical RAM configuration.

Product
Installed software products.

Sysaccount
Builtin system user account information, SIDS, and status information.

Process
Detailed information on running processes.

Service
Detailed information on all installed services.

The default aliases include two output formats. The default is a full listing of all values. You can access a reduced view, which contains only the most useful information by typing the following.

WMIC LIST BRIEF

You should note that although the brief listing is customizable, it is very difficult to change. A more practical approach is to create a custom list of only the information you want to see using the GET clause. A simple example is to create a list of the startup configuration for each service on your computer. A full listing of the SERVICE alias includes about 15 columns. Of these 15, you only need 4 to generate a report on the startup type of all services. The columns you need are the CAPTION, NAME, and STARTMODE. You can also include the STATE column to compare the services that are started with those that should be started. The query looks like this.

Wmic service get caption, name, startmode, state

Notice the use of the GET keyword to create a list of columns. This will work for any column that is included in the alias.

Another option to limit the out put of a large WMIC command is to filter the rows of information that are returned. In our above example, we may only want to see services that are started, to generate a report of running services. This is done by including a WHERE clause in the query. The WHERE clause has a simple filter expression. You specify the column you want to filer on, and a value to compare the column to. Text columns are expressed in quotes (i.e. “server”) and numeric columns are not (i.e. < 80). The query to generate a report of only running services looks like this.

Wmic service where (state=”running”) get caption, name, startmode, state

When the WHERE and GET clauses are used in the same query, the WHERE will always appear before the GET.

Another option is to redirect output to a file for viewing. This is accomplished by using output redirection, which has been a feature of the command prompt since the days of DOS. The default output format is a TSV (tab separated values) format. This format is understood by most database and spreadsheet products. We can redirect our report of running services by using the following command.

Wmic service where (state=”running”) get caption, name, startmode, state > output.tsv

When the file is opened using Microsoft Excel, it looks like this.

Figure 3: TSV report in Microsoft Excel
Beyond Reporting
WMI has the ability to go far beyond simple reporting. Using WMI you can also create and manipulate a Windows computer. There are a few terms that must be understood before we proceed.

Class – A class is a definition of something. For example, the class process defines all the characteristics of a process, but does not refer to any specific process.

Object – Sometimes called an instance; an object is a specific occurrence of a class. For example, when you start notepad, you instantiate the class process, and create a new process object, which represents the copy of notepad you have running on your computer.

Action – Called a method by developers, and action is something you can ask a class or object to do. For example, one action associated with the class process is to create a new process. Another is to terminate a process.

Let’s say that you want to create an instance of a process on your computer. The first step is to determine the information that is required to create a new instance of a process. This is done by the WMIC built in help using the following command.

Wmic process /?
You will notice the output contains a CALL keyword. This keyword is used to call an action. Every class (we are working with the process class) will have a different set of actions that can be called. Some actions will be fairly common such as create and terminate. You can view the list of actions by typing the following command.

Wmic process call /?

You will notice the action create. You can now list what is required to create a new process by typing

Wmic process call create /?

The output will contain four pieces of information. Each parameter will have a direction (IN or OUT), a name, and a data type. As before, for string data types, enclose the parameter in quotes, and for numeric, do not. Fortunately, not all parameters are needed.

Our command to create a new instance of notepad now looks like this.

Wmic process call create “c:\windows\notepad.exe”

Notepad should now be running on your screen. This is a simple example, but it illustrates the power and simplicity of WMI. Another example is to terminate the process of notepad. This is done using the terminate action of the process class. Help can be found by typing

Wmic process call terminate /?

All instances of notepad can be terminated by typing:

Wmic process where (caption=”notepad.exe”) call terminate

Be careful to include a filter when you use the terminate action. If you were to terminate all processes, your computer would reboot.

Using WMIC to Manage Multiple Computers
If you only had to manage a single server, then WMIC represents a lot of work to complete a simple task that can be done quickly using a GUI tool. It is not until you begin to manage multiple servers that you have the power of WMIC becomes apparent.

First of all, let’s look at how WMIC commands can be targeted at multiple servers. This is accomplished using the /NODE switch on the WMIC command. The /NODE switch will use either a list of computer names or a file containing a list of all computers. To specify a list of computer names in the WMIC command, type a command such as the following.

Wmic /node:server1,server2 process list brief

If you would like to run the query against multiple computers stored in a file, you need to create a file. The file can contain a list of server names, either separated by commas or on separate lines. The file must start with an @ character. The following example will generate a list of all the computers in a forest and store the results in a file named @computers.txt.

dsquery * forestroot -scope subtree -filter objectcategory=computer -attr name –l > @computers.txt

The DSQuery command is included with Windows Server 2003 and can query any object in Active Directory. If you only want to search a single domain, simple run this query on a domain controller in the domain. Replace the forestroot option with domainroot.
You can now use this file to kill all occurrences of notepad on every computer in your forest.

Wmic /node:@computers.txt process where (caption=”notepad.exe”) call terminate

One important note is that if all computers listed in the file are not available, the entire command will fail. You can get around this limitation by only querying responsive computers. This is done with FAILFAST switch. When failfast is on, each server is pinged before the WMIC command is run. If the server fails to respond to the ping, it is skipped. Note that WMI is transported using DCOM, which uses RPC. If a firewall is preventing ICMP (Ping) then the server will not receive the command. Likewise, if a server is allowing ICMP, but not RPC, then the command will still fail. The FAILFAST switch can be used as follows.

Wmic /fastfail:on /node:@computers.txt process where (caption=”notepad.exe”) call terminate

Advanced Topics
So fare we have not gone beyond the functionality that is included with WMIC. The aliases that are provided represent the majority of tasks and information that system administrators would be interested in. This does not represent everything you can do with WMIC. WMIC can also be used to directly query the WMI schema. This gives you access to every class available, and not just those that are exposed through aliases.

A full reference of all WMI classes can be found on the Microsoft Developer Network at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_start_page.asp

The classes are organized into what are known as namespaces. Different namespaces represent different collections of classes that have a common function. The namespace that contains the classes of use to administrators is the \root\cimv2 namespace. In this namespace there are several groups of classes. The group that is of use to administrators is the Win32 group of classes. To better understand how aliases and classes relate, enter the following command.

Wmic alias list brief

The rightmost column contains a statement known as a query. This query is written in the WMI Query Language (WQL). This language is very similar to SQL. You can directly query one of the classes by using the following command.

Wmic /namespace:\\root\cimv2 class Win32_Service

The output of this command is an XML document that contains a description of all the properties of the Win32_Service, but not actual service information. In order to view actual service information, you must query the instances of Win32_Service, instead of the class Win32_Service. This is done by replacing the CLASS keyword with the PATH keyword. An example is shown.

Wmic /namespace:\\root\cimv2 path Win32_Service

WMIC supports both filtering and actions when directly querying the WMI schema.

Extensive help on WMIC can be found in both the Windows XP Professional and Windows Server 2003 help and support centers.

Anonymous Connections - win2000/win2003

2005-12-29T17:48:00.000-08:00

What can an Anonymous Connection Accomplish?
I am sure I have your attention now! The question that must be on the tip of your tongue must be, “What can someone do if they gain anonymous access to my computer?” Of course the answer is “it depends!” It depends because it is based on not only what they acquire from your computer, but what they can do with it.

The basic information that someone can glean from your computer from an anonymous connection includes:

List of users from your computer, including Active Directory
List of groups from your computer, including Active Directory
SIDs for user accounts
User accounts for SIDs
List of shares from your computer
Account policies from your computer
NetBIOS name from your computer
Domain name that your computer is associated with
List of domains that your domain trusts

How to Make an Anonymous Connection
An anonymous connection is not something that you can make by accident. The syntax is not so simple that just anyone can make the connection. The point here is that if you have anonymous connections being made to your servers, someone is deliberately trying to gather information and you need to take immediate action.

The method that is mostly used to create an anonymous connection is to use the net use command. The net use command allows you to make a connection to a specific share on a server. The syntax would look something like this:

Net use \\10.10.10.10\ipc$ /u:”” “”

Here, you can replace the 10.10.10.10 IP address with the IP address of the server that you are accessing, or the NetBIOS name of the computer. In some instances, you can even get a list of all the computers that you could possibly connect to by running the following command:

Net view /domain:domainname

Once you have the computer names or IP addresses of the computers, you can attempt to make anonymous connections using the command above, or any “hacker” tool that exploits the anonymous access.

How Windows 2000 protected against anonymous connections
Microsoft has been aware of the anonymous access problem for quite some time. For Windows 2000, they implemented a Group Policy Object setting which allowed you to control how and if a user could create an anonymous connection to your computer. The setting is located in the Computer Configuration portion of any GPO. If you go below the Computer Configuration to the Windows Settings | Security Settings | Local Policies | Security Options, you will see the first GPO policy is related to anonymous connections, as shown in the figure.

Figure 1: GPO policy relating to anonymous connections

This policy can be configured to three different levels: 0, 1, and 2. These levels are displayed in the policy editor a bit differently, which is explained below. The Registry value that is being modified is HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous. Here is an explanation of the settings and what they protect against.

Level 0: “None. Rely on default permission”
This does not restrict any anonymous connections. This is a very insecure setting, but it is also the default on a Windows 2000 computer or domain.

Level 1: “Do not allow enumeration of SAM accounts or shares”
This is designed to not allow any anonymous access list the SAM or shares. However, there is a small problem here that this does not protect against all methods of accessing the SAM or shares from an anonymous connection. This setting is in essence no more secure than the Level 0 setting.

Level 2: “No access without explicit anonymous permissions”
This will deny all access for anonymous connections gaining access to the SAM or shares. This setting is not suggested, due to the impact it has on down level clients and applications that rely on anonymous connections.

A note about the level 2 access in Windows 2000 is that it is not designed for a mixed-mode domain. If this policy is set to 2 for a mixed mode domain, you will see problems with the following areas:

Windows 9x and Windows NT computers will not be able to establish a netlogon secure channel.
Windows NT trusted domains will not be able to establish a netlogon secure channel.
Users of Windows NT computers will not be able to change their passwords.
The browser service will fail on all computers where this level is set to 2.

How Windows 2003 protects against anonymous connections
When Server 2003 arrived, there were some distinct changes with regard to the control of anonymous connections. The old Windows 2000 anonymous GPO policy was still there (in a round about way), but it was accompanied with many more policy settings. The settings are welcomed, especially with the poor control over anonymous connections that Windows 2000 provided. The main problem is that the descriptions, documentation, and features of each setting were not very clear.

Figure 2 shows the anonymous control settings in a Group Policy Object from a Windows Server 2003 environment. The following is a list of each setting that directly controls anonymous connections, as well as a description as to what the policy controls.

Figure 2: Windows Server 2003 has better control over anonymous connections

Network access: Allow anonymous SID/Name translation – This policy controls an anonymous user’s capability of obtaining the SID of a user by knowing the name, or vice versa. With tools such as user2sid and sid2user, allowing this access can quickly give away the built-in administrators name.

Network access: Let everyone's permissions apply to anonymous users – This policy controls the access that anonymous users have once connected. In previous versions of Windows, anonymous users were provided with the SID for the Everyone group on the authentication token, allowing them to access everything that the Everyone group had access to. In Server 2003, the default configuration is to remove the Everyone group SID from the token generated for an anonymous user. This provides added protection for anonymous users attempting to access resources. Once this policy is set, anonymous users will only be able to access resources for which the anonymous user has been explicitly given permission.

Network access: Do not allow anonymous enumeration of SAM accounts – This policy is designed to negate anonymous connections from enumerating the list of user accounts from the local SAM (member servers and desktops) and Active Directory domain controllers.

Network access: Do not allow anonymous enumeration of SAM accounts and shares – This policy takes the previous policy one step further, by not only negating enumeration of user accounts from the SAM, but also shares on the targeted computer. The shares that are negated include standard, hidden, and hidden administrative shares.

There are other settings that control anonymous connections to specific shares, named pipes, etc. These are typically not as powerful as the settings described above in negating anonymous connectivity to a Windows computer.

Active Directory Troubleshooting Part 1

2005-12-22T18:38:00.000-08:00

http://www.windowsnetworking.com/pages/article_p.asp?id=464

Monitoring and Troubleshooting Active Directory Replication
Replication may be defined as a duplicate copy of similar data on the same or a different platform or system. When using a directory service such as Active Directory, the directory database is carried by all domain controllers so that when you want to contact a domain controller for use, there is always a local copy local for use so that requests do not have to be sent over the wide area network (WAN). Replication for Active Directory operates within the directory service component of the security subsystem. This component is called Ntdsa.dll and is accessed through the Lightweight Directory Access Protocol (LDAP). Ntdsa.dll runs as a part of the local security authority (LSA), which runs as Lsass.exe. Updates are transported over Internet Protocol (IP) by the remote procedure call (RPC) protocol. The Simple Mail Transfer Protocol (SMTP) is also available for use as well, although it’s more common to see RPC over IP used.

When considering Active Directory, replication takes place and a copy of the Active Directory database is stored and updated on all other participating domain controllers on your network and in a perfect world, each copy of the database is the same and all domain controllers are synchronized. If this happens, then all your domain controllers are synchronized with an exact duplicate copy of the Active Directory database. When you install Active Directory, for the most part even if all the default settings are chosen, the replication process from domain controller to domain controller is automatic and practically transparent. For the most part, domain controllers handle the replication processes without advanced configuration and most times, without a problem.

In figure 1, you can see a common network (2 sites connected via a WAN link) with a domain controller in each location. Again, the benefit of having a domain controller local to your PC’s at each network segment is to have requests made of the domain controller kept local to the PC’s in need of its services to speed up requests (by keeping them local) or in case of disaster recovery, which could happen if the WAN link drops, the local PCs can still find a local domain controller to use. Keeping traffic off the wide area network (WAN) and containing it to the local area network (LAN) is the best design practice you can implement.

Figure 1: A Common Wide Area Network (WAN)

As a systems administrator, you should still consider that Active Directory performance still needs to be monitored and analyzed. The health and maximized performance of Active Directory depends on a smooth replication process. If you are having problems with replication, you will know not only from blatant logging in your Event Viewer, but from poor performance as well. Many times, you cannot stop every problem from occurring, but hopefully after reading this article, you will be better equipped to handle issues and keep your network as optimized as possible to handle the traffic traversing it.

Consider a common problem such as a failed network link. In figure 2, you see that the main wide area network link has been broken.

Figure 2: A Failed Network Link

ISP’s and telecom service providers occasionally have problems and service can be interrupted. This of course stops the communication between domain controllers, therefore also severing the replication process. This can prevent the synchronization of information between domain controllers and possibly cause corruption and/or other problems.

A good way to make sure that this doesn’t happen is to set up a backup link (such as ISDN as seen in figure 2). ISDN (Integrated Services Digital Networks) is a digital WAN technology used to facilitate connections between sites. More commonly used today for disaster recovery, ISDN still has a place in today’s marketplace. Although still used, you don’t have to limit yourself to any technology when it comes to backup links, you can use a fractional or full T1, a DSL line, or any other technology that allows you to have redundancy in your links. The goal is to have redundant links to keep your domain controllers in constant communication with each other so that the Active Directory database stays synchronized and healthy. A common symptom of replication problems is that information is not updated on some or all domain controllers. For example, a systems administrator creates a user account on one domain controller, but the changes are not propagated to other domain controllers. In most environments, this is a potentially serious problem because it affects network security and can prevent authorized users from accessing the resources they require. You can take several steps to troubleshoot Active Directory replication; each of these is discussed in the following sections.

Verifying Network Connectivity
In order for replication to work properly in distributed environments, you must have network connectivity. Although ideally all domain controllers would be connected by high-speed and redundant LAN or WAN links, this is rarely the case for larger deployments and for most companies that utilize slow WAN links that aren’t recoverable from a disaster. Always make sure your network topology is documented and tested to ensure that it’s connected. There are many tools you can use to verify connectivity such as Ping and Tracert which come with just about every operating system ever created that runs TCP/IP.

In real world deployments, analog/dial-up connections and slow connections are common. If you have verified that your replication topology is set up properly, you should confirm that your servers are able to communicate over the network. Problems such as a failed dial-up connection attempt can prevent important Active Directory information from being replicated. Learn how to use ping and other ICMP based protocol troubleshooting tools in the links section at the end of this article.

Verifying Router and Firewall Configurations
When building a secure network, most times controls are placed on network devices to filter the traffic going from place to place. The most commonly used tool to control traffic is a Firewall. A router or any other device that utilizes a firewall feature set, or some other form of Access Control that stops access to and from other hosts connected can also be used. A firewall is usually dedicated to only protecting the perimeter so its been designed to do that, do not assume that the use of a firewall stops any risk of you being attacked, it only minimizes that risk.

Firewalls are used to restrict the types of traffic that can be transferred between networks. Their main use is to increase security by preventing unauthorized users from transferring information. In some cases, company firewalls may block the types of network access that must be available in order for Active Directory replication to occur. For example, if a specific router or firewall prevents data from being transferred using SMTP, replication that uses this protocol will fail.

Network Ports Used by Active Directory Replication
RPC replication uses dynamic port mapping as per the default setting. When you need to connect to an RPC endpoint during Active Directory replication, RPC uses TCP port 135. RPC on the client contacts the RPC endpoint mapper on the server at a well-known port and RPC randomly allocates high TCP ports from port 1024 to 65536. Because of this configuration, a client will never need to know what port to use for Active Directory replication; it will just take place seamlessly. There are also other ports assigned for Active Directory replication. There are as follows:

Protocol
Port

LDAP
udp 389
tcp 389

LDAP (SSL)
udp 636
tcp 636

Kerberos
udp 88
tcp 88

DNS
udp 53
tcp 53

SMB over IP
udp 445
tcp 445

Global Catalog Server
tcp 3269
tcp 3268

Examining the Event Logs:
Errors, if they occur, will show up in the Event Viewer logs. At the end of this article, I have placed a link to the Microsoft Website so that you can learn how to use the Event Viewer. The Event Viewer can be very helpful when trying to locate and resolve a replication problem. Many errors are reported to the Event Viewer for your review.

Whenever an error in the replication configuration occurs, the computer writes events to the Directory Service and File Replication Service (FRS) event logs. By using the Event Viewer administrative tool, you can quickly and easily view the details associated with any problems in replication. For example, if one domain controller is not able to communicate with another to transfer changes, a log entry is created.

You may receive events such as:

Event ID 1311 in the directory service log
Event ID 1265 with error "DNS Lookup Failure" or "RPC server is unavailable" in the directory service log. Or, received "DNS Lookup Failure" or "Target account name is incorrect" from the repadmin command
Event ID 1265 "Access denied," in directory service log. Or, received "Access denied" from the repadmin command
Note:
The link at the end of the article covers the explanation of these specific errors and more.

Verifying Site Links
Before domain controllers in different sites can communicate with each other, the sites must be connected by site links. If replication between sites is not occurring properly, verify that the proper site links are in place. Verify your site links by using the Replication diagnostics utility (Repadmin.exe). Use this tool to verify correct site links and to display inbound and outbound connections. You can also use it to display the replication queue. You can get the tool by using the link at the end of this article.

Verifying That Information Is Synchronized
It’s often easy to forget to perform manual checks regarding the replication of Active Directory information. One of the reasons for this is that Active Directory domain controllers have their own read/write copies of the Active Directory database. Therefore, if connectivity does not exist, you will not encounter failures while creating new objects.

It is important to periodically verify that objects have been synchronized between domain controllers. This process might be as simple as logging on to a different domain controller and looking at the objects within a specific OU. This manual check, although it might be tedious, can prevent inconsistencies in the information stored on domain controllers, which, over time, can become an administration and security nightmare.

Verifying Authentication Scenarios
A common replication configuration issue occurs when clients are forced to authenticate across slow network connections. The primary symptom of the problem is that users complain about the amount of time it takes them to log on to the Active Directory (especially during times of high volume of authentications, such as at the beginning of the workday). Usually, you can alleviate this problem by using additional domain controllers or reconfiguring the site topology. A good way to test this is to consider the possible scenarios for the various clients that you support. Often, walking through a configuration, such as “A client in Domain A is trying to authenticate using a domain controller in Domain B, which is located across a very slow WAN connection,” can be helpful in pinpointing potential problem areas.

Verifying the Replication Topology
The Active Directory Sites and Services tool allows you to verify that a replication topology is logically consistent. You can quickly and easily perform this task by right-clicking the NTDS Settings within a Server object and choosing All Tasks => Check Replication Topology. If any errors are present, a dialog box alerts you to the problem.

You can verify the Active Directory topology using the Active Directory Sites and Services tool.

Besides for ensuring that replication always continues, you can also learn how to monitor it as well. There are several ways in which you can monitor the behavior of Active Directory replication and troubleshoot the process if problems occur. In our next article we will look at the replication monitor and part III of this article will cover the system monitor.

http://www.windowsnetworking.com/pages/article_p.asp?id=464

Radius and TACACS

2005-12-22T18:14:00.000-08:00

One of the solutions that was designed to accommodate the remote worker is that of RADIUS. Remote Authentication Dial-In User Service is what the acronym actually stands for. It is actually fairly descriptive as that is pretty much what it is used for. The worker will remotely authenticate for access to that remote network. I have previously mentioned that I like to map protocols before to the OSI Reference Model. This helps one visualize just what protocols belong where in the grand scheme of things. In the OSI model RADIUS fits into the application layer. This protocol is no exception either to the client/server model. A client will log into the RADIUS server and supply the required credentials. Also RADIUS uses UDP as a transport protocol to ferry about its information.

Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.

I want details!
The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.

Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;

Access-Request: where the user sends their credentials to the server
Acess-Challenge: where the server sends a challenge and the user must respond
Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.

TACACS and TACACS+
Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!

Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.

Windows System Errors

2005-12-13T21:33:00.000-08:00

System error 5 - Access is denied

This is a permission issue. If the net view command fails with a "System error 5 has occurred. Access is denied." message, 1) make sure you are logged on using an account that has permission to view the shares on the remote computer.
2) Need to cache credential: logon the same username and password on both computers or use net net use \\computername /user:username command.
3) Make sure the Netlogon service is running.

System error 8 - Not enough storage is available to process this command
or System error 234 - More data is available.

Symptoms: If you attempt to start the server service manually, the following errors may be displayed: System error 234 has occurred. More data is available. Or system error 8 has occurred. Not enough storage is available to process this command. The event viewer shows "Event ID: 7023. Description: The Server service terminated with the following error: More data is available. Or Event ID: 7001. Description: The Net Logon service depends on the Server service which failed to start because of the following error: More data is available.
Resolutions: 1) apply (or reapply) the latest Windows NT Service pack.
2) remove any unnecessary entries from this value in the registry, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer \Parameters\NullSessionPipes

System error 51 has occurred - The remote computer is not available

Symptoms: You may receive "System error 51 has occurred. The remote computer is not available" when using net use to map the computer drive.

Resolutions: 1. Make sure server service is running on the remote computer.

2. Enable file and printer sharing.

System error 52 - You were not connected because a duplicate name exists on the network.

Symptoms: you can ping a host but not net view it. When using net view \\hostname, you get system error 52 - a duplicate name exists on the network.

Resolutions: there are two host names or alias name (cname) are pointed to the same IP. 1) check the WINS records. 2) check DNS records. 3) Go to System in the Control Panel to change the computer name and try again.

System error 53 - The network path was not found.

Symptom: when using net view \\ip or \\computername, you get system error 53.

Resolutions: 1) if it is domain environment, check your WINS; 2) if it is peer-to-peer workgroup, enable NetBIOS over TCP/IP; 3) make sure the machine is running; 4) make sure file and Printer Share enabled on remote computer; 5) make sure client for ms networks is enabled on local computer; 6) make sure you type the correct name.

Still need help, contact consultant at http://www.ChicagoTech.net for the tech support.

System error 67 - The network name cannot be found

Symptom: When using net view \\computer, you may receive above error message.

Resolution: make sure you type the correct computer name or shared name.

System error 85 has occurred. The local device name is already in use

Cause: net use /persistent:yes is default settings for NT and win2000/XP. If you have mapped some network drives and check the reconnect at logon, or your network uses logon script to map network drives, the mapped network drives may show red Xs. If you enable echo and pause the logon script or if using net use to map the same drive manually, you may get "System error 85 has occurred. The local device name is already in use." One thing you may want to try is using net use /persistent:no, for example, net use i: \\servername\folder /persistent:no.

System error 1219 has occurred - The credentials supplied conflict with an existing set of credentials
Symptoms: 1) When you log on to a domain from w2k client; 2) when attempting to join a domain, you may receive the following error message: The credentials supplied conflict with an existing set of credentials.
Resolutions: This may cause because of attempting to make two or more connections to the same server using two or more sets of credentials
1. Go to windows explorer and disconnect all network drives. Then re-logon.
2. Delete the profile or copy another profile. Note: you may lost all settings and data in My Documents when deleting or copying profile.
3. If solution 1 and 2 doesn't work, try this: 1) Log on as an administrator at any workstation and run regedt32. 2) Select HKEY_USERS, but do not open. 3) From the Registry menu, click Load Hive. 4) This will bring up a Load Hive dialog box. Locate the Ntuser.dat file for the user with the errors. Select the Ntuser.dat and click Open. You may enter any string for the Key Name. Use TEST for ease of use pertaining to the remainder of this article. 5) Locate the Username value under the following key in the registry: HKEY_USERS\TEST\Network\Username. 6) Delete the string for Username (leaving it blank is sufficient). 7) Select the TEST hive that you previously loaded, click the Registry menu, and then click Unload Hive. 8) Quit Registry Editor.
4. If you get this message when joining the domain, make sure 1) you have delete the computer from AD; 2) delete it from DNS; 3) delete it from WINS.

System error 1231 has occurred. The network location cannot be reached.

Symptom: When using net view \\computername, you may receive System error 1231.

Resolutions: 1) make sure Client for MS Networks is enabled, 2) make sure you have permission to access it.

System Error 1240 - The account is not authorized to login from this station.
Symptoms: 1. You may get the system error 1240 when using net view \\remotecomputer'
2. “Workgroup_name is not accessible… Account is Not Authorized to Log In to this Station” when attempting to browse the workgroup from a networking computer.

Resolutions: 1. Use Regedit to enable unencrypted (plain text) passwords for the SMB client.
2. Enable Send Unencrypted Password to Connect to 3rd Party SMB Servers under Local Security Policy.
3. Set the following policies as showing:
Digitally sign client communications (always) - disabled
Digitally sign server communications (always)- disabled
Digitally sign server communications (when possible) - disabled
LAN Manager Authentication Level set to Send LM and NTLM - use NTLMv2 session security if negotiated - (default) send LM & NTLM responses
Secure channel: Digitally encrypt or sign secure channel data (always) - disabled
Secure channel: Require strong (Windows 2000 or later) session key - disabled
4. Contact the third-party SMB server manufacturer if you have a third-party SMB server, such as DEC Pathworks, Samba or Linux.

System error 1311 - There are currently no logon servers available to service the logon request

Symptoms: The primary purpose of logging on with cached credentials is to enable you to access the local workstation. However, if you have logged on by cached credentials, you may be unable to access network resources because you have not been authenticated. For example 1) after you log on to a w2k/xp laptop by using cached credentials, you may be unable to access the network resources. This issue is commonly experienced by laptop users whose computer resides in a Windows Server domain and who log on to the computer by using cached credentials prior to being able to establish a remote access connection. 2) You log on to a w2k/xp laptop with a domain logon option in a workgroup network. After you establish the connection and you try to map the network drives, the operation may be unsuccessful, and you may receive the following error message: "System Error: (1311) There are currently no logon servers available to service the logon request."

Resolutions: To authenticate the cached credentials, 1) if it is w2k/xp, use net command, for example, net use \\servername\sharename /user:username. 2) if xp, open Windows Explorer>Tools>Map Network Drive. Click Connect using a different user name, enter the username and password.
System error 1326 has occurred - Logon failure: unknown user name or bad password.

Symptom: when using net use to map a network drive, you may receive "System error 1326 has occurred. Logon failure: unknown user name or bad password." message.

Resolutions: 1) create a user account on remote computer; 2) need to enable the guest account; 3) make sure the remote computer doesn't use auto-logon and blank password; 4) make sure you have a folder or drive shared on the remote computer. 5) use net use \\servername /user:username command. Make sure you type correct command (e.g. use net use \\servername \user:username will get this error too)

System error 1331 has occurred - Logon failure: account current disable

Symptom: When using net use \\computername command, you may receive above error message.

Resolutions: this is cache credentials issue. To fix this problem and cache the credentials, use net use \\computername /user:username command.

System error 1385 has occurred - Logon failure: the user has not been granted the requested logon type at this computer

Symptoms: When using net use \\remotecomouter\ahredname, you may receive above message.

Resolution: The users do not have permission to connect to the remote computer. To resolve this problem: on the remote computer, select Administrative Tools>Local Security Settings>Local Policies>User Rights Assignment, right-click on Access this computer from the network>Properties>Add Users or Groups, add everyone or any users you want to be able to access the computer from the network.

System error 1396 has occurred - Logon Failure: The target account name is incorrect.

Symptoms: 1. when using net use, you may receive above message.
2. when using net view \\hostname, you may receive "System error 5 has occurred. Access is denied.". However, net view \\ip works fine.
3. You may receive above error while running logon script.

Causes: 1. SPN for the domain that is hosting the replica has not been propagated.
2. Incorrect target account name or the server is not online.
3. If you have DFS, make sure the DFSRoot is available.

Refer to RL060704

System error 6118 has occurred. The list of servers for this workgroup is not currently available
SYMPTOMS: 1) After enabling ICS/ICF, you can't see any computes on My Network places. If you try, you may get "workgroup is not accessible". 2) If you use the net view command, you may receive "System error 6118 has occurred. The list of servers for this workgroup is not currently available." message.
Resolutions:
1) This behavior can occur if you enable the ICF that will closes the ports for file sharing by default. To open these ports, right-click the network connection that is firewall protected> Properties>Advanced>Settings>Service Tab>Add, Enter 127.0.0.1) for the required Internet Protocol (IP) number. Enter UDP ports from 135 through 139, and TCP ports from 135 through 139 one by one (the external and internal port numbers should be identical).
2) This may occur if the workgroup name and the domain name are the different.
3) No master browser. Starting Computer Browser Service on one of w2k/xp computers should fix the problem

Recover passwords on Windows XP or Server 2003 machines

2005-11-09T07:04:00.000-08:00

Recover passwords on Windows XP or Server 2003 machines
By Bryan Muehlberger

Did you know that recovering a lost password for a local account on a
Windows XP (Professional or Home Edition) or Windows Server 2003 machine
is now possible with a new feature called the Forgotten Password Wizard?
This lightly publicized feature of Windows XP and Server 2003 may make
your job as an administrator a little easier.

Before this new feature can be useful, you must create a Password Reset
Disk (PRD) before you forget the password. To create the PRD, you can
open the Forgotten Password Wizard by pressing CTRL-ALT-DEL, selecting
Change Password from the Windows Security dialog box, and then pressing
the Backup button. Note however that the Backup button is only available
if you select the local machine from in the "Log on to" drop down box.
This also means that you can only create a PRD for local account (such
as Administrator), and not for domain accounts. Domain accounts still
require administrative rights in the domain to reset the password.

After you have launched the Forgotten Password Wizard, follow the
on-screen prompts that will walk you through the process. In less than a
minute, you will have your PRD successfully created.

Make sure that you store the PRD in a safe place. I would recommend a
locked safe or secure area where other items such as this are stored. If
someone gains access to the diskette, knows the machine for which the
account belongs, and knows which account the diskette is for, then they
have the ability to reset the password and break into your system.

Using the diskette is as easy as forgetting your password. When
attempting to logon with a bad password, Windows will prompt you with an
option to use a reset disk. By selecting this option, you will launch
the Password Reset Wizard, which will prompt you for your PRD. After the
wizard completes, the password has been reset.

There are a couple of things that you need be aware of:

1)The PRD can be used even if you change the password
multiple times, without having to update the PRD.

2)Use the latest service pack with Windows XP. If you don't have the
latest service pack, you may run into issues when you attempt to decrypt
files that were encrypted using Microsoft Encrypting File System (EFS)
prior to resetting your password with the Password Reset Disk. This is a
known issue and Microsoft has some KnowledgeBase articles that discuss
this in more detail.

--------------------------------------------------------------------------------

Scripting for Windows system administrators
By Bryan Muehlberger

As a Windows system administrator, you constantly perform many routine
tasks in an effort to manage, maintain, and support your Windows
environment. Occasionally the need will arise to create a script that
handles a repetitive task in a more efficient way, or gets a piece of
information that otherwise would be difficult to find out.

It is relatively easy to write scripts with the scripting technologies
that Microsoft provides. But if you are like most of us, taking the time
to learn all of the facets of a scripting language and the underlying
system requirements is difficult.

In this series of articles, I will provide you with a foundation upon
which you can successfully develop your scripting skills, and begin
writing scripts with a minimal amount of effort and time on your part.

Let's start with an overview of the different scripting technologies
that Microsoft has provided, and then in the weeks to come, I will touch
on each of the technologies in detail, and provide some basic code
snippets, along with links to where you can find more detailed
information.

Microsoft has created four independent, yet highly integrated components
that make up a well-rounded set of scripting technologies. These
include the Windows Scripting Host (WSH), Visual Basic Scripting Edition
(VBScript), Windows Management Interface (WMI), and Active Directory
Scripting Interface (ADSI). When combined, these components make up a
rich set of tools for developing basic to advanced administrative
scripts.

Each of these technologies provides you with different tools to develop
scripts:

* Windows Scripting Host (WSH) is the scripting engine that creates an
environment upon which scripts can execute on a Windows system.

* Visual Basic Scripting Edition (VBScript) is the scripting language,
based upon the Visual Basic framework, that actually provides the syntax
and program control that you will require within your script (i.e.
looping, if-then-else statements, function declarations, variable
storage, arrays, etc)

* Windows Management Interface (WMI) provides you with a consistent way
to access comprehensive system management information (i.e. hard drive
information, file system control, etc.)

* Active Directory Scripting Interface (ADSI) is the technology that
allows you to create scripts to administer directories such as Active
Directory.

Each of these technologies is very important when it comes to systems
management, but the two most important pieces are VBScript and WSH,
because without these two components, you would not be able to take
advantage of the features of WMI and ADSI (see Figure 1).

Figure 1
http://itw.itworld.com/GoNow/a14724a73317a97736788a3

--------------------------------------------------------------------------------

Determine directory resource usage with diruse.exe
By Bryan Muehlberger

Recently we needed to identify home directories on our file servers that
exceeded expected usage guidelines. Our servers are structured in such a
way that all of the home directories are named the same as the owner's
username. As a result, once we identify how much disk space a particular
directory consumes, we can easily identify the data's owner and correct
the problem.

To accomplish this, we needed a utility that allowed us to query the
size of a single folder's contents as well as its corresponding
subdirectories. During our search, we discovered a resource kit utility
called diruse.exe, which allows an administrator to query folders on a
Windows server to get the the content size. This utility is part of the
Windows 2000 Resource Kit, and can be downloaded from Microsoft at:

http://itw.itworld.com/GoNow/a14724a73074a97736788a0

The utility has a number of useful options available that make reporting
very easy. We used a command similar to the following:

diruse.exe" /* /M /, \\serverName\Share
In my example, the subdirectories under the share are all of the user's
home directories and look like the following:

\\serverName\Share\username1\\serverName\Share\username2\\serverName\Share\username3
By running the utility, I get an output that looks similar to the
following:

Size (mb) Files Directory
200.23 764 SUB-TOTAL: \\serverName\Share\username1 253.32 7902 SUB-TOTAL: \\serverName\Share\username2 153.70 838 SUB-TOTAL: \\serverName\Share\username3 .

By forcing the output to dump to a log file (i.e. using stdout
redirection 'command > logfile.txt'), I am able to open the output file
in Excel and sort by size. This allows me to narrow down the list to the
top users and handle them accordingly.

We typically look for users that exceed 2G-bytes of file server usage
within their home directory. After we get through these "high-end"
users, we target other categories of users.

--------------------------------------------------------------------------------

Learn to use Windows File Protection - part 2
By Bryan Muehlberger

Last week we talked about the Windows File Protection (WFP) service and
the associated utility System File Checker (SFC) utility. The SFC
utility is part of the Windows 2000/XP and Server 2003 platform and must
be used in conjunction with the WFP service. This week we'll discuss
some of the associated registry settings and command line parameters
that allow you to optimize and better control the functionality of the
SFC utility.

One of the most important components of the SFC utility is the DLLCache
folder. This folder contains the verified (via driver signing) system
files that your system maintains. If this folder becomes corrupt, you
can run "sfc /purgecache". This purges the existing, but corrupted
DLLCache folder and automatically begins a scan of the system.

Some administrators may want to control what files are contained in the
DLLCache folder. This may be necessary in an FDA-qualified environment
at a pharmaceutical or healthcare organization. To maintain a copy of
the DLLCache folder on shared network share for all users, you must
modify the following registry key on all of the machines that you want
to be using the shared location:

Location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Key = SFCDllCacheDir (REG_EXPAND_SZ)
Path = local or network location of the Dllcache folder (default is the
%SystemRoot%\System32\Dllcache folder)

NOTE: Modify the registry at your own risk. Incorrect modifications
can cause your system to fail.

The only caveat to doing this is that if a machine cannot access the
shared folder (i.e. a laptop user who is traveling), then they will not
be able to run the SFC utility until they are connected to the LAN
again.

Another useful registry setting is the SFCShowProgress registry key:

Key = SFCShowProgress (REG_DWORD)
0 = Do not display the System File Checker progress meter (default)
1 = Display the System File Checker progress meter

This registry setting allows you to show a progress meter while SFC is
running so that you know its status.

Last, due to the number of system files that WFP is monitoring for you,
you may want to increase the size of the DLLCache folder. You can do
this by setting the registry key:

Key = SFCQuota (REG_DWORD)
n = size (in megabytes) of the Dllcache folder quota
ffffffff = (default) cache all protected system files on the local hard
disk

The default size of the DLLCache folder is approximately 250M-bytes.

--------------------------------------------------------------------------------

Windows scripting host: Wscript vs. Cscript
By Bryan Muehlberger

Last week, I introduced you to a core component of the Windows Scripting
Technologies platform called the Windows Scripting Host (WSH). WSH is
included with Windows 98, Windows 2000, Windows XP and Windows Server
2003. However, each operating system came with a different default
version of WSH, ranging from version 1.0 to its current version of 5.6.
Depending upon the version you have installed on your system will
determine the features that are available to your scripts. To see a
comparison of the different versions of WSH check out:

http://itw.itworld.com/GoNow/a14724a74338a97736788a0

Please note that I will assume you are using WSH version 5.6 in my
discussions (to determine which version you are running, type cscript at
the command prompt)

This week we continue our discussion of WSH and discuss the two
different hosting environments provided to you by WSH - Wscript and
Cscript.

Both Wscript and Cscript are part of the WSH environment, but each
provides you with a different experience when executing your scripts.

Wscript is the GUI version of WSH. Most Windows operating systems
default to using Wscript when executing a script. Therefore, if you
double click a .vbs script, most likely it will run using the
wscript.exe version of WSH. This will send all output directly to the
screen in the form of message boxes. Alternatively, you can force the
use of Wscript by typing the following in a command prompt window:

Wscript.exe scriptName.vbs

On the other hand, Cscript is the command-line version of WSH. Cscript
allows slightly more control over your scripts and is typically the
preferred method for administrative scripts. You can use Cscript by
typing the following at the command prompt:

Cscript scriptName.vbs

Using Cscript causes all output to be sent to the command prompt window,
thus allowing you more control over the output, and prevents you from
having to respond to every message that is displayed (which is the case
when you use Wscript).

Both Wscript and Cscript come with a number of options. You can display
these options by typing wscript or cscript at the command prompt.

Next week we will begin our discussion Visual Basic Scripting Edition
(VBScript).

--------------------------------------------------------------------------------

Introduction to Windows scripting host
By Bryan Muehlberger

Windows Scripting Host (WSH) is the scripting engine that creates an
environment upon which scripts can execute on a Windows system. The key
here is that WSH "creates the environment" that allows your scripts to
execute on a Windows system. It is included by default on Windows 98,
ME, 2000, XP and the soon to be released Windows Server 2003. However,
different versions of WSH are included with each platform. You can find
out more about the different versions at:

http://itw.itworld.com/GoNow/a14724a73874a97736788a1

In the most simplistic way, WSH makes certain objects and services
available to your scripts. These objects and services allow your scripts
to map drives, modify the registry, print messages to the screen, and
many other things. Generally, scripts are written in either Jscript or
Vbscript, but throughout this article series, we will concentrate on the
Vbscript scripting language for our sample scripts.

To create a script that runs within the WSH environment, you need to
create text file and utilize the appropriate extension:

.VBS for VBScript
.JS for JScript

The contents of the script file will include your script code written in
either the Jscript of VBScript syntax (which we will discuss in future
articles).

For example, let's make a simple "Hello World" script. You would need
to create a text file and add the following lines to it:

Wscript.echo ("Hello World")

Then save the file as helloWorld.vbs. Now if you double-click the file
it will process the script using the VBScript scripting engine (because
of the .vbs extension) and process the WSH echo command which will
create a message box saying "Hello World". However, what if your script
is writing tons of information to the screen? This would cause you to
have to click OK to every message - which could be quite inconvenient.
There are other options though. This brings us to the topic of
cscript.exe versus wscript.exe, which we will talk about next week.

Next week we will take a more in depth look at the WSH and Cscript.exe
Veruse Wscript.exe.

Part 1: Scripting for Windows system administrators
http://itw.itworld.com/GoNow/a14724a73874a97736788a3

AD Mixed or Native mode

2005-11-02T06:39:00.000-08:00

By default, Windows 2000 (Win2K) networks operate in a mixed mode, which lets both Win2K and Windows NT domain controllers coexist. During migration to Win2K, the mixed mode provides the functionality that lets NT domain controllers offer domain services. After you upgrade all NT domain controllers to Win2K, switch from mixed mode to native mode, which doesn’t support NT domain controllers. However, before you switch to native mode, you need to understand the differences between the two modes. Depending on your organization, when you convert to native mode can be a critical decision with major implications. It’s a one-way conversion—there’s no going back.

Mixed Mode
In mixed mode, a Win2K domain assigns a domain controller to act as a PDC for NT BDCs. By default, the first domain controller in a Win2K domain acts as a PDC emulator. There can be only one PDC emulator in a domain, and you can assign the role to any domain controller in a domain. The PDC emulator performs several important tasks in mixed mode, including:

Emulating as a PDC and replicating account information to BDCs.

Handling account modifications, including password changes.

Acting as a master browser for NT clients.

Providing NT LAN Manager (NTLM) authentication services.

Supporting Active Directory (AD) replication to Win2K domain controllers and NTLM replication to BDCs.
If a Win2K site in mixed mode contains Win2K clients, make sure there’s at least one Win2K domain controller in that site because the Win2K clients first attempt to locate Win2K domain controllers using DNS. If a client doesn’t find a Win2K domain controller, it’ll try to use NTLM to log on to an NT domain controller. Obviously, NT doesn’t support group policies so your Win2K client users won’t be able to take advantage of either the group policies or the logon scripts.

In mixed mode, NT client users won’t be able to change their passwords if a PDC emulator, an operations master, isn’t available. In fact, a PDC emulator plays a role even in native mode, where it’s responsible for handling password changes and account lockouts.

Another operations master you must make available in mixed mode is the RID Operations Master, required to provide security descriptors to the NT clients. Also, you’ll have to address some issues in mixed mode relating to NT’s LAN Manager Replication (LMRepl) versus Win2K’s File Replication Service.

Native Mode
As I mentioned earlier, native mode doesn’t support NT domain controllers; you can only have Win2K domain controllers. However, you can have NT workstations and member servers in native mode.

Major advantages of native mode include support for universal groups, nested groups, and transitive trust relationships. One of the biggest drawbacks of mixed mode is that AD’s scalability is limited to 40MB because the PDC emulator replicates changes to NT domain controllers that inherit limited scalability by design. By default, Win2K domain controllers establish an automatic two-way Kerberos trust relationship with all other domain controllers in a domain. Because NT domain controllers don’t understand Kerberos transitive trusts, you have to establish explicit (manual) one-way trusts between domains to authenticate users from other domains.

Win2K clients process group policies, and there’s a Group Policy option that lets you enable NT-style system policies for Win2K clients—but that’s an option I’d caution against. NT clients support only system policies and don’t understand group policies. Even in a Win2K network, NT clients can take advantage of NT system policies. However, you might run into problems if you have both the group and system policies enabled on your Win2K network. System policies will overwrite the Win2K group policies. One solution is to ensure that your group policies and system policies match, which might be easier said than done. By switching to native mode, you only have to deal with Win2K’s group policies.

You should now have a better picture of the issues you’ll face in native mode. Most organizations will want to switch to native mode sooner rather than later. If you’re not switching to native mode because you suspect that you’ll have to add NT BDCs to your domain, don’t worry. You can always add a new domain to your Win2K network, which installs in mixed mode by default. Then you can add NT BDCs to that domain.

track the programs that a user executes on his or her workstation or the programs being executed on a server?

2005-09-25T19:12:00.000-07:00

Enable the Audit process tracking audit policy for the desired computers. You'll find this setting in any Group Policy Object (GPO) under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy in the Group Policy Management Console (GPMC). Then start monitoring for event ID 592 (A new process has been created), which Windows logs whenever a new executable is started. This event reports the full path of the program and the user who started the program, as Figure 1 shows. You can figure out when the program ended by looking in the log for an occurrence of event ID 593 (A process has exited) with the same Process ID value. For more information about these events, see my Windows Security Log Encyclopedia at http://www.ultimatewindowssecurity.com/encyclopedia.html. . . .

http://www.ultimatewindowssecurity.com/encyclopedia.html

EFS

2005-09-12T21:30:00.000-07:00

http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=47175

On various Internet security mailing lists, I often see administrators asking about secure and transparent file-encryption products for Windows. Just as often, senior management personnel ask for ways to prevent network administrators from seeing confidential company files. When I suggest using Windows' own Encrypting File System (EFS), most reply that they want something more reliable and secure.

Contrary to popular opinion, EFS is a reliable, easy-to-use, and secure encryption solution, and it can trump even the network administrator's rights. EFS is great for protecting confidential files on the network and on often-stolen laptop computers. Unfortunately, EFS has been wrongly maligned by users who refuse to objectively evaluate any Microsoft security product. In truth, EFS is among the best security products Microsoft has ever made, but it requires appropriate planning and understanding. In this article, I discuss the basics of EFS, talk about its purpose and functionality, and discuss basic administrative tasks and pitfalls.

EFS in a Nutshell
Microsoft first released EFS in conjunction with Windows 2000 and has been steadily improving the product in its Windows XP and Windows Server 2003 incarnations. EFS lets users encrypt any file or folder to which they have Read and Write permissions. After encryption is enabled, the resource is decrypted on the fly whenever the legitimate party needs to access it. Users attempting to access a protected file or folder without the appropriate EFS permissions can view the file or folder name, but they can't open, modify, copy, print, email, or move the file or folder. Interestingly, however, if users have the NTFS permissions to delete an EFS-protected file, they can delete it even if they can't read it. Like most encryption products, EFS is built to protect confidentiality, but it isn't concerned with preventing data loss. If EFS prevents an unauthorized user from seeing data in any form, it has done its job correctly. Some people argue that Windows falters by even allowing the name of a protected file or folder to be seen.

In addition, you don't need to have ownership or Full Control permissions of a file or folder to encrypt it. You need only Read and Write permissions—the same permissions necessary to access the resource. Once a file or folder is protected, only the user who encrypted it (as well as any additional users with whom the user wants to share the resource) can access it. The lone common exception is the data recovery agent (DRA). By default (in most instances), Windows makes the administrator a DRA, so he or she can access any file or folder that EFS encrypts. In a domain environment, the DRA is the domain administrator; in a nondomain environment, the DRA is the local administrator. (I'll talk more about DRAs in a moment.)

The ability to encrypt a file or folder is enabled by default, but you must select each file or folder separately (or indirectly through normal inheritance rules). For EFS to work, the file or folder must be located on an NTFS disk partition. Then, to protect a file or folder, you simply right-click the resource in Windows Explorer, choose Properties, then choose Advanced on the General tab. (Note: Don't click Advanced on the Security tab.) Finally, select the Encrypt contents to secure data check box.

If you select one or more files (as opposed to a folder), EFS will prompt you to choose whether to encrypt just the file(s) or to encrypt the parent folder and the current file(s). If you choose the latter, EFS will mark the folder as an encrypted folder. All future files added to the folder will be encrypted by default, although any existing files in the folder not selected during the EFS operation will be left unencrypted. Encrypting the entire folder instead of individual files is desirable in many cases, particularly because many applications (e.g., Microsoft Word) create temporary files in the same folder while a file is open. Temporary files are often left behind (e.g., in the event of a nongraceful reboot) and in plain text—ripe for unauthorized recovery.

By default, in XP Professional and later, EFS highlights encrypted files in green, but you can disable this behavior by choosing Tools, Folder Options in Windows Explorer, then clearing the Show encrypted or compressed NTFS files in color check box on the View tab. If you have the Attributes column selected in Windows Explorer's Details view, compressed files will contain an E attribute marking along with the normal Archive (A) attribute, resulting in an AE attribute setting. Note that you can't use Windows' built-in mechanisms to encrypt and compress a file at the same time, although you can use a third-party utility such as WinZip or PKZIP to compress a file, then encrypt the resulting compressed file.

It's Good Encryption
EFS offers good encryption—so good, in fact, that if you lose your EFS private key (which the software uses to decrypt EFS-protected files), there's a good chance the files might become unrecoverable. If EFS is appropriately configured, not even the administrator can access an EFS-protected file or folder, unless he or she is also the designated DRA.

At least one product on the market today—ElcomSoft's Advanced EFS Data Recovery (aka AEFSDR)—claims to recover EFS-protected files. Actually, it recovers the local administrator's password (a simple process if Windows isn't appropriately configured), which can then be used to recover the administrator's EFS private key. (If a user has a tool that recovers the administrator's password, he or she can do anything to the system. The user accessing EFS-protected files would be the least of your worries.) Minimizing the risk of unauthorized EFS private key recovery is the fact that in a domain environment, the DRA is the domain administrator's account, not the local administrator account that nearly every password-cracker tool recovers. Still, in XP, Microsoft implemented a new policy that makes this type of attack more difficult to accomplish. Note that if the recovery tool can't recover the current—and correct—administrator password (many password tools reset the password rather than recover the current one), EFS protection is still enabled.

How Does EFS Work?
EFS uses a combination of symmetric and asymmetric cryptography. With symmetric cryptography, the key that locks the file is the same key that unlocks the file. In asymmetric cryptography, a public key encrypts and a separate but related private key decrypts what the public key encrypted. As long as the one user who should have the decryption ability keeps the private key secure, the protected resource remains secure.

EFS is enabled by default on all Win2K and later systems. When someone uses EFS to protect a file or folder for the first time, Windows checks whether a public key infrastructure (PKI) server capable of generating EFS digital certificates is available. Windows 2003 and Win2K Certificate Services can generate EFS certificates, as can some non-Microsoft PKI products. If Windows can't find an acceptable PKI provider, it generates a self-signed EFS certificate for the user like the one you see in Figure 1. Self-signed EFS certificates are usable for 100 years—far longer than anyone would ever use one.

If Windows finds a Certificate Services server, that server will automatically generate and issue the user a 2-year certificate. Perhaps the thinking is that if you have PKI services running in-house, the PKI server can easily grant or renew EFS certificates when the original expires. In either case, you can view your EFS certificates by adding the Certificates snap-in to the Microsoft Management Console (MMC) and looking in the Personal container.

The user's private EFS key (which unlocks EFS-protected files) is encrypted with the user's master key and stored in the user's profile under Documents and Settings, username, Application Data, Microsoft, Crypto, RSA. If a roaming profile is in use, the private key resides in the RSA folder on the domain controller (DC) and is downloaded to the user's computer when the user logs on. Windows uses the user's current password and either the 56-, 128-, or 512-bit RC4 algorithm to generate the master key. Perhaps the most crucial fact to understand about EFS is that the user's private EFS key resides in his or her profile and is protected with a master key based on the user's current password. Note that EFS's encryption is only as strong as the user's password. If a malicious user cracks an EFS user's password or is able to log on as the legitimate user, the protection provided by EFS is compromised.

If the user's profile is ever lost, or if his or her password is reset (as opposed to the user changing it), the user could easily lose access to all EFS-protected files. For this reason, the user's private EFS key should always be backed up to two or more secure and separate offsite locations, or one or more DRAs should be defined (and their private keys exported and backed up to two or more separate and secure offsite locations). Failure to follow this advice could lead to data loss.

When a file or folder is encrypted for the first time, Windows randomly generates a symmetric key using 128-bit Data Encryption Standard X (DESX—the default in XP and Win2K) or 256-bit Advanced Encryption Standard (AES—in Windows 2003 and XP Pro Service Pack 1) algorithms. Both algorithms are widely accepted and trusted government standards, although the latter is the more current and recommended standard. You can also enable the government's older symmetric cipher standard, 168-bit Triple DES (3DES), should your organization require its use. See the Microsoft article "Encrypting File System (EFS) files appear corrupted when you open them" (http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech) for more details. The randomly generated symmetric key is known as the file encryption key (FEK), and it will be the only key that Windows uses to encrypt the file or folder, regardless of how many people have access to the EFS-protected resource.

Windows then encrypts the FEK, using the user's 1024-bit RSA public EFS key, and stores the FEK in the file's extended attributes. If any DRAs are defined, the OS stores another, encrypted copy of the FEK with the DRA's public EFS key. Then, Windows stores that encrypted copy of the FEK with the file. In XP and later, more than one user can have EFS access to a particular file or folder. Each authorized user will have his or her own copy of the FEK encrypted with a unique public EFS key. (Note that in Win2K, you can have only one DRA defined.)

Now, when an authorized user accesses a protected file, Windows decrypts his or her copy of the encrypted FEK by using the user's associated private EFS key. Windows then uses the FEK to unlock the encrypted file. Unlike the first versions of EFS in Win2K, EFS now securely manages all encryption and decryption of files and folders in memory, so no plain-text remnants are available for unauthorized recovery.

Sharing EFS Files
In Win2K, only one user at a time can EFS-protect a file, but in XP Pro and later, several users can share an EFS-protected file. In a shared scenario, the first user to EFS-protect the file or folder controls who else has access. After initially EFS-protecting a file or folder, the user can select additional users to participate by clicking Details, which Figure 2 shows. The user can then add as many users as he or she wants. Each user will have his or her own copy of the FEK encrypted with his or her private EFS key. This new feature in XP is terrific for letting groups of users share EFS-protected files. Unfortunately, you can set EFS file sharing only on individual files—not at the folder level. Note that a user must have encrypted one file or folder or received an EFS certificate before he or she can be available for selection as an additional EFS user.

The DRA
Because a user's profile can be wiped out so easily, and because administrators commonly reset users' passwords, network administrators must either back up users' EFS keys or implement one or more DRAs. You can back up a user's private EFS key by accessing the EFS digital certificate in the Certificates console and selecting the Copy to file check box on the Details tab. In XP Pro and later, you can also use the Backup Keys button, which you'll find under the Details button at the EFS file-sharing location. Lovers of the command line can use the command

cipher.exe /x
to back up EFS keys in Windows 2003, as well as XP Pro SP1 and later. During the resulting prompts, Windows gives you a chance to back up and/or export the related private key. You should never delete a user's private EFS key—as Windows prompts you to do during the export—because then the user won't be able to decrypt his or her protected files. After exporting the user's private key, the user should store the key in two separate offline locations.

Backing up individual users' EFS private keys is laborious. Beginning with Win2K, Microsoft lets you select a DRA. Whenever someone encrypts a file or folder, the DRA automatically gets a copy of the FEK. In Win2K (workgroup or domain mode), XP (domain mode only), and Windows 2003 (workgroup or domain mode), the administrator is the default DRA, although you can change the user account that is appointed to be the DRA. Unfortunately, in XP's workgroup mode, a DRA isn't defined. Microsoft made this decision in answer to criticism resulting from the ability to compromise EFS-protected files in the event of a compromised administrator password. Unfortunately, large numbers of XP Pro machines are in workgroup mode, and their EFS users are just one destroyed profile or reset password away from losing their files. Whenever using EFS (remember that it's turned on by default and available to users), ensure that either your EFS users back up their private keys or that one or more DRAs are appointed.

If you plan to choose a DRA different from the default administrator, the replacement user account must have an EFS Recovery Agent certificate already issued to it. You can request an EFS Recovery Agent Certificate from Certificate Services or install one from any other capable third-party PKI product. If you have Windows 2003 Certificate Services installed, you can implement Key Recovery Agents instead of using DRAs. Key Recovery Agents will end up recovering the user's lost key instead of directly recovering the file.

Unlike the private keys of normal EFS users, a DRA's EFS private keys should be exported and deleted from computers. If the DRA's private keys are compromised, all files that have FEKs protected by the DRA's public key could become compromised. Therefore, you should export the keys and store them securely in two offsite locations. If you need the keys to recover encrypted files, you can easily import and use the private keys.

Although the administrator is often the default DRA, you should choose one or more specifically created user accounts that are unlikely to be deleted. Because the DRA's public key also copies and protects each FEK, if you accidentally delete your DRA user account or reset the password, the DRA-protected FEK could be difficult to recover. If the user accounts that have DRA status are changed, you could end up with EFS-protected files with FEKs that are protected by old DRA keys. Whenever Windows accesses the files, DRA-protected FEKs are updated with the latest DRA keys; however, you can alternately use the Cipher command to force a mass update of all FEK keys with the current DRA keys. Note that regardless of whether you export and delete the DRA's private key from the system, backing up the DRA's recovery certificate to two or more offsite safe locations is essential.

Miscellaneous EFS
EFS doesn't protect files that are copied over the network. Windows copies any file opened on a network share in plain-text format. If you need real-time encryption of files stored on disk and copied over the network, you need to use another protection technology, such as IP Security (IPsec), Secure Sockets Layer (SSL), or WWW Distributed Authoring and Versioning (WebDAV). On a related note, in XP and later, you can enable EFS protection for offline files. (I'll discuss this functionality in a future article.)

EFS is a local protection process—Microsoft designed it for encrypting files on local disks. If you want to use EFS to protect stored files on remote computer shares, the remote computer must be trusted for delegation. Laptop users often use EFS on file-server shares. To implement EFS on a server, you need to select the Trust this computer for delegation to any service (Kerberos only) or Trust this computer for delegation to specified services only check box on the server's computer account, as you see in Figure 3.

If you don't want your users implementing EFS protection, you can disable EFS through Group Policy. Select the Computer Configuration container, then right-click Windows Settings and choose Security Settings, Public Key Policies, Encrypting File System. You can then clear the Allow users to encrypt files using EFS check box. You can enable or disable EFS per organizational unit (OU).

Before you use EFS, be sure that your applications support EFS and the EFS API. If your applications offer no such support, the EFS-protected files could become corrupted—or worse, unprotected without appropriate authorization. For example, if you use Windows' edit.com program (a 16-bit executable) to save or modify an EFS-protected file, it will remove any additional EFS users sharing the file. Most Microsoft applications—including Microsoft Office, Notepad, and Wordpad—readily support EFS.

If an authorized user copies EFS-protected files to a FAT volume, EFS protection will be removed. An unauthorized user should be unable to move or copy the files to any Windows volume. If, however, an unauthorized user utilizes a bootable floppy disk or CD-ROM program that can mount an NTFS file share (e.g., Knoppix, NTFSDOS, Peter Nordahl-Hagen boot floppy) to boot around the Windows NTFS permission system, that user might be able to copy or move the file, but unless he or she comes up with the authorized user's EFS key, the file will remain encrypted.

Best Practices

Here are some EFS best practices that you should consider:

Determine the number and identity of your DRA accounts.
Generate DRA certificates for the DRA accounts.
Import the DRA certificates into Active Directory (AD).
Export and remove the DRA's private keys and store them in two separate, secure offsite locations.
Educate end users about EFS uses and concerns.
Periodically test DRA file recovery.
Periodically run the Cipher command with the /u option, if necessary, to update FEKs to any added or deleted DRAs.
EFS provides a reliable and secure method for encrypting files and folders on Win2K and later systems. Network administrators should define and enable a DRA policy and educate end users about the benefits and concerns of EFS.

Figure 1

Figure 2

Figure 3

Default Access Control Settings in Windows 2000

2005-08-29T07:53:00.000-07:00

http://support.microsoft.com/default.aspx?scid=kb;en-us;825069
http://support.microsoft.com/default.aspx?scid=kb;en-us;278874

This white paper describes the default security settings for components of the Microsoft® Windows® 2000 operating system, including the registry and file system, as well as user rights and group membership. Implications for developers and system administrators are discussed, and answers to frequently asked questions are provided.

On This Page
Default Access Control Settings for Windows 2000
Summary
Frequently Asked Questions
Appendix A: Default File System ACLs for Power Users and Users
Appendix B: Default Registry ACLs for Power Users and Users

Default Access Control Settings for Windows 2000
Overview
A significant portion of the Windows 2000 operating system security is defined by the default access permissions granted to three groups: Administrators, Power Users, and Users. At a very high level, these groups may be described as follows:

Administrators are all-powerful. The default Windows 2000 security settings do not restrict administrative access to any registry or file system object. Administrators can perform any and all functions supported by the operating system. Any right that the administrator does not have by default, they can grant to themselves.

Ideally, administrative access to the system should only be needed to:

• Install the operating system and components (including drivers for hardware, system services, and so forth).

• Install Service Packs and hotfixes.

• Install Windows updates.

• Upgrade the operating system

• Repair the operating system.

• Configure critical machine-wide operating system parameters, for example, kernel mode driver configuration, password policy, access control, and audit functions.

In practice, administrative accounts must often be used to install and run legacy Windows-based applications.

Users are the opposite of administrators. Provided that the Windows 2000 operating system is clean-installed onto an NTFS partition, the default security settings are designed to prohibit Users from compromising the integrity of the operating system and installed applications. Users cannot modify computer-wide registry settings, operating system files, or program files. Users cannot install applications that can be run by other members of the Users group (preventing Trojan horses). Users cannot access other users' private data. Thus, two significant aspects of securing a Windows 2000-based system are as follows:

1.
Make sure that end-users are members of the Users group only.

2.
Deploy applications that members of the Users group can successfully run.

Ideally, Users should be able to run any application that has been previously installed by an Administrator, Power User, or themselves. Users should not be able to run applications that are installed by other Users.

In practice, members of the Users group will not be able to run most legacy applications because most legacy applications were not designed with operating system security in mind. Members of the Power Users group should be able to run such applications.

Applications that comply with the Windows 2000 Application Specification (http://msdn.microsoft.com/certification/default.asp) can successfully run in a normal Users context.

Power Users are ranked between Administrators and Users in terms of system access. The default Windows 2000 security settings for Power Users are backward-compatible with the default security settings for Users in the Windows NT® 4.0 operating system. In short, Power Users are indeed powerful.

Ideally, Power Users should be able to perform any task except for the administrative tasks described above. Thus, Power Users should be able to:

• Install and remove applications per computer that do not install system services.

• Customize system-wide resources (for example, System Time, Display Settings, Shares, Power Configuration, Printers, and so forth).

Power Users are not allowed to access other users' data stored on an NTFS partition.

In practice, Power Users cannot install many legacy applications, because these applications attempt to replace operating system files during the setup process.

Configuring Security During Setup
Default security settings are applied at the beginning of GUI-mode setup during a clean install of Windows 2000 or an upgrade from Windows NT/9x.

Note: File system security settings can only be applied when the Windows 2000 operating system is installed onto an NTFS partition.

The default security settings for workstations, servers, and domain controllers can be found in the following files respectively:

• %windir%\inf\defltwk.inf

• %windir%\inf\defltsv.inf

• %windir%\inf\defltdc.inf (Note that default domain controller security settings are applied during DCPromo.)

Since security is applied at the beginning of GUI-mode setup, no explicit security settings are defined for optional components; for example, Internet Information Services (IIS) or Terminal Services that may be chosen during the GUI-mode phase of setup. This allows optional components to specify their own security if it should be different than what is inherited by default.

Default File System and Registry Permissions
The backward compatible permissions (access control) for Windows 2000 Power Users are included in Appendix A for file system objects and Appendix B for registry objects. The backward compatible default permissions for Power Users are liberal enough that most applications should be able to be installed by a Power User. For example, Power Users have Modify access to:

• HKEY_LOCAL_MACHINE \Software

• Program Files

• %windir%

• %windir%\system32

Even though Power Users have Modify access to the %windir% and %windir%\system32 directories, Power Users have Read access to the files that are installed in these directories during Windows 2000 text-mode setup. This allows legacy applications to write new files into the system directories, but prevents Power Users from modifying the Windows 2000 system files. Additionally, Power Users are not allowed to install Windows 2000 services.

The default permissions for Administrators and Users are more easily described as follows:

• Administrators, System, and Creator Owner are given Full Control to all file system and registry objects that exist at the beginning of GUI-mode setup.

• Users are explicitly granted Write access to the locations specified in Table 1.

Table 1 Users Write Access Locations

Object Permission Comment
HKEY_Current_User
Full Control
User's portion of the registry

%UserProfile%
Full Control
User's Profile directory

All Users\Documents
Read, Create File
Shared Documents Location. Allows Users to create files that can subsequently be read (but not modified) by other Users.

%Windir%\Temp
Synchronize, Traverse, Add File, Add Subdir
Per-Machine temp directory. This is a concession made for service-based applications so that Profiles do not need to be loaded in order to get the per-User temp directory of an impersonated user.

\ (Root Directory)
Not Configured during setup
Not configured during setup because the Windows 2000 ACL Inheritance model would impact all child objects including those outside the scope of setup.

By default, Users have Read (or less) access to the rest of the system.

It is possible for applications that are installed by administrators to create their own subfolders and specify their own permissions on those subfolders. Certified applications that do not want to inherit the default security settings must create such subfolders in All Users\Documents or All Users\Application Data. For example, an application might want to store a centralized clip-art gallery that any User is allowed to modify. Such configurations should be reviewed by system administrators to determine whether the application functionality requiring this configuration is worth the potential security risk posed by the configuration. Isolating such configurations to these two locations (for certified applications), promises to make the task of identifying these potential security vulnerabilities easier.

Also of note is the fact that permissions on the root directory are not defined during setup. Setup does not change the permissions on the root directory because the Windows 2000 ACL Inheritance model would recursively try to configure all subdirectories of the root. This could result in undesired changes for non-Windows 2000-based directories that may exist on the install partition.

Since setup does not change permissions on the root directory, the permissions that previously existed on the root directory are maintained. These root permissions are inherited by any new subdirectories created off of the root, and may be inherited by non-Windows 2000-based directories that already exist off of the root. Thus, after a clean-install setup, the root directory and any non-Windows-based subdirectories should be configured according to the security needs of the organization and the requirements of the applications that need to be run.

Default User Rights
The default User rights for clean-installed workstation and member servers are defined in the Table 2. They differ only in one respect and that is in the Shutdownthe system right. On servers, Users are not granted this right by default.

Table 2 Default User Rights

User Right Default Workstation Default Server
Replace a Process-Level Token

Generate Security Audits

Logon as a Batch Job

Backup Files and Directories
Administrators, Backup Ops
Administrators, Backup Ops

Bypass Traverse Checking
Administrators, Backup Ops, Power Users, Users, Everyone
Administrators, Backup Ops, Power Users, Users, Everyone

Create a Pagefile
Administrators
Administrators

Create Permanent Shared Objects

Create a Token Object

Debug Programs
Administrators
Administrators

Increase Scheduling Priority
Administrators
Administrators

Increase Quotas
Administrators
Administrators

Logon Interactively
Administrators, Backup Ops, Power Users, Users, Guest
Administrators, Backup Ops, Power Users, Users, Guest

Load and Unload Device Drivers
Administrators
Administrators

Lock Pages in Memory

Add workstations to the domain

Access this computer from the network
Administrators, Backup Ops, Power Users, Users, Everyone
Administrators, Backup Ops, Power Users, Users, Everyone

Profile a single process
Administrators, Power Users
Administrators, Power Users

Force shutdown from a remote system
Administrators
Administrators

Restore files and directories
Administrators, Backup Ops
Administrators, Backup Ops

Manage audit and security logs
Administrators
Administrators

Log on as a service

Shutdown the system
Administrators, Backup Ops, Power Users, Users
Administrators, Backup Ops, Power Users

Modify firmware environment variables
Administrators
Administrators

Profile system performance
Administrators
Administrators

Change system time
Administrators, Power Users
Administrators, Power Users

Take ownership of files or other objects
Administrators
Administrators

Act as part of the OS

Deny Interactive Logon

Deny Batch Logon

Deny Service Logon

Deny Network Logon

Remove Computer from a Docking Station
Administrators, Power Users, Users
Administrators, Power Users, Users

Synchronize Directory Service Data

Enable computer and user accounts to be trusted for delegation

1 The Guest account must be enabled before it is allowed to log on interactively.

Additional Power User Permissions
In addition to those capabilities permitted by the default ACLs and User rights, Power Users can also:

• Create local users and groups.

• Modify users and groups that they have created.

• Create and delete non-admin file shares.

• Create, manage, delete and share local printers.

Administrators can also perform all of these actions. In the case of account management however, Administrators can create, delete or modify any account, while Power Users can only modify or delete accounts that they themselves have created. Users cannot perform any of these additional Power User actions.

Default Group Membership
A significant difference between Windows NT 4.0 and Windows 2000 default security settings is the way access control is assigned in each version of the operating system. In computers running Windows NT 4.0, the Everyone group was used as a catchall for file system ACLs, registry ACLs, and User rights. In a sense, the Everyone group is not a traditional group because an Administrator cannot define who should and should not belong to the group. Instead, the Windows NT operating system or domain automatically controls the group membership so that everyone is a member of the Everyone group. If an administrator wanted more granular access control, the default ACLs would have to be modified in order to remove the Everyone group and add the groups which the administrator could control.

In the Windows 2000 operating system, a different philosophy is used. Groups such as Everyone and Authenticated Users whose membership is automatically configured by the operating system are not used to assign permissions (There are some exceptions. For example, the Everyone group is used to grant read access to some file system and registry objects for backward compatibility with applications requiring anonymous read access. Also, the interactive group is used on Service ACLs where access depends on how you are logged on to the system rather than who you are logged in as). Instead, only those groups whose membership can be controlled by an administrator are used. Primarily, these are the three user groups discussed in this paper: Users, Power Users, and Administrators.

The following table, Table 3, describes which users constitute the default membership in these groups. When a user is a member of a group, they automatically have the permissions that have been assigned to that group.

Table 3 Default members of groups

Local Group Default Workstation Members Default Server Members
Administrators
Administrator
Administrator

Power Users

Users
Authenticated Users, Interactive Users
Authenticated Users, Interactive Users

By default, on computers with clean installations, the Authenticated Users group and the Interactive group are added to the Users group on Windows 2000 Professional and Windows 2000 Server-based computers. Membership in the Authenticated Users and Interactive groups is automatically controlled by the operating system. Authenticated Users is the same as the Everyone group except it does not contain anonymous users. Interactive includes anyone who is locally logged on to the system rather than connected over the network.

Since there are no members of the Power Users group by default, non-administrative users that log on to a Windows 2000-based computer that has been clean-installed onto an NTFS partion will automatically be subject to a secure access control policy. Although these users can run any certified Windows 2000-based application (http://msdn.microsoft.com/certification/default.asp), it is likely that they will not be able to successfully run non-certified legacy applications. In order to run legacy applications, one of two things must happen:

• The Users must be added to the Power Users group

• The default security granted to Users must be loosened up

Since Power Users have at least the same access that Windows NT 4.0 Users had, any application that ran as a User on a Windows NT 4.0-based system should run as a Power User on Windows 2000-based system.

Finally, when a workstation or server joins a domain, the same domain groups that were added to Windows NT 4.0 local groups are added to Windows 2000-based local groups. Specifically, Domain Administrators and Domain Users are added to the local Administrators and local Users groups respectively upon joining the domain.

Top of page
Summary
A significant portion of the Windows 2000 operating system security is defined by the access permissions granted to three groups: Administrators, Power Users, and Users. By default, on clean-installed NTFS systems, Administrators have complete access to critical operating system components while Users have read access (or less). These default access control settings defined for members of the (non-administrative, non-power) Users group provides a standard, secure Windows-based environment that application developers can target and which is easily testable.

Applications that satisfy the Windows 2000 Application Specification (http://msdn.microsoft.com/certification/default.asp) can run successfully in the normal Users context. Non-certified legacy applications are likely to require increased access such as that granted to Power Users in order to run. Thus, the single most important action customers can take to secure their desktops is to deploy certified applications that can run successfully in the Users context. Until such applications are deployed, the Power Users group provides a convenient, but insecure, backward compatibility mechanism for legacy applications that do not run successfully as a Windows 2000-based User.

Top of page
Frequently Asked Questions
What do the Windows 2000 default security settings mean for developers, testers, and system administrators?
If you are a developer, make sure your code meets the Windows 2000 Application Specification, specifically Chapter 4: "Data and Settings Management." Meeting these requirements offers customers maximum security without loss of application functionality and can be marketed as such.

If you are a tester, make sure the application you are testing meets the Windows 2000 Application Specification requirements, specifically Chapter 4: "Data and Settings Management." Testing the run-time aspects of the application is straightforward:

1.
Perform a clean installation of the Windows 2000 operating system on an NTFS partition (join a domain as necessary).

2.
Log on as an Administrator.

3.
Install the application into the Program Files directory.

4.
Create a test user account (non-administrative).

5.
Log on as the test user created in step 4.

6.
Run the application.

If you are a system administrator, contact the in-house developers or independent software vendors for each of the applications that are supported in your environment. The Windows 2000 operating system defines a standard secure platform that any developer can target and which is easily tested. Applications are required that can run successfully on this platform. As applications that can successfully run as User are deployed, users can be moved from the Power Users group into the Users group, resulting in significant improvements in security, reliability, and management. Applications that meet the Windows 2000 Application Specification requirements, specifically Chapter 4: "Data and Settings Management," will successfully run as User.

How can I synchronize upgraded computers with Windows 2000 default security settings?

Since the security on upgraded computers is not modified during Windows 2000 setup, the default security settings must be applied by an administrator after setup has completed: From the %windir%\security\templates directory, the following command can be run on workstations:

Secedit /configure /cfg basicwk.inf /db basicwk.sdb /log basicwk.log
/verbose

For servers, the default security settings are defined in basicsv.inf:

Secedit /configure /cfg basicsv.inf /db basicsv.sdb /log basicsv.log
/verbose

The basic configuration files will apply all default security settings except for User Rights and Group Membership.

The file system that the Windows 2000 operating system is installed on must be NTFS in order to obtain the default file system ACLs.

Why is the root directory not secure by default?

Setup does not change the permissions on the root directory because the Windows 2000 ACL Inheritance model would recursively try to configure all subdirectories of the root. This could result in undesired changes for non-Windows 2000-based directories that may exist on the install partition. As a result, administrators should configure root directory security according to their own system configurations and application requirements.

How will Windows 2000 default security settings impact legacy desktop applications?

Legacy desktop applications that ran under a User context on computers running Windows NT 4.0 will more than likely have to run under a Power User context on a Windows 2000-based system. By default, non-administrative Users that log onto clean-installed Windows 2000 computers are members of the Users group, so an administrator will need to add these users to the less secure Power Users group in order to run non-certified legacy applications. Applications that meet the Windows 2000 application specification do not require Power User capabilities in order to run successfully.

How will Windows 2000 default security settings impact legacy server-based applications?

Server based applications that ran under a User context on computers running Windows NT 4.0 will more than likely need to run under a Power User context in a Windows 2000-based system. Thus, the service accounts for such applications should be added to the Power Users group on Windows 2000 Server platforms in order to achieve backward compatibility with the Windows NT 4.0-based environment.

Service accounts that ran as local system or under an administrative context are not impacted by the default security settings.

What applications can successfully run as user?

Any application that meets the Windows 2000 Application Specification, specifically Chapter 4: "Data and Settings Management," will successfully run as User. Note that it is possible for an application to successfully run as User, but still not meet all of the other Windows 2000 Application Specification requirements.

Why define default security settings that few applications can run on?

The Internet has changed the threat landscape significantly. In response, customers are demanding secure environments in which to operate. Although the Windows NT operating system provides security mechanisms to meet these demands, these features often cannot be turned on because doing so causes problems for applications written on earlier versions of the Windows operating system. Providing a secure access control policy out of the box sets a standard that ISVs can target and that is easily testable. This, in conjunction with customer demand, will drive the development of security conscious applications necessary the security of any operating system environment. In short, for customers that have fully implemented the Windows 2000 operating system, an application that runs out of the box will have a competitive advantage over an application that does not. Furthermore, an application that runs out of the box on Windows 2000-based computers allows customers to easily secure their desktops simply by making sure that end-users are members of the Users group rather than Power Users or Administrators. Until such applications can be deployed, the Power Users group provides a convenient backward compatibility mechanism for running legacy applications.

What if I don't want end users to be Power Users when running legacy applications?

Some system administrators may consider the Power Users group too liberal because of the built-in permissions that members of the Power Users group have:

• Create local users and groups.

• Modify users and groups that they have created.

• Create and delete non-admin file shares.

• Create, manage, delete and share local printers.

All other additional rights, such as Change System Time, or Stop and Start non-autostarted services, can be reconfigured for the Power User by modifying the appropriate user rights or configuring the appropriate ACL.

Since there is no way to disable the built-in permissions allotted to Power Users, administrators who need to support non-certified legacy applications must loosen up the permissions allotted to members of the Users group to the point where their installed base of applications can be successfully run. The Windows 2000 operating system includes a security template for precisely this purpose. The template is named compatws.inf and can be found in the %windir%\security\templates directory. The template can be applied to a system using the Security Configuration Toolset. For example, the secedit.exe command line component of the Toolset can apply the template as follows:

secedit /configure /cfg compatws.inf /db compatws.sdb

This template loosens up security for Users in a matter consistent with the requirements of most legacy applications.

What can an Administrator do that a Power User can't?

By default, an administrator can:

• Install the operating system.

• Install or configure hardware device drivers, although Power Users are allowed to install Print Drivers.

• Install system services.

• Install Service Packs, hotfixes, and Windows Updates.

• Upgrade the operating system.

• Repair the operating system.

• Install applications that modify Windows system files.

• Configure password policy.

• Configure audit policy.

• Manage security logs.

• Create administrative shares.

• Create administrative accounts.

• Modify groups or accounts created by other users.

• Remotely access the registry.

• Stop or start any service.

• Configure services.

• Increase quotas.

• Increase execution priorities

• Remotely shutdown the system.

• Take ownership of arbitrary objects.

• Assign User rights.

• Override a locked computer.

• Format a hard drive.

• Modify system-wide environment variable's

• Access other Users' private data.

• Backup and restore files.

What can a Power User do that a User can't?

A Power User can:

• Create local users and groups.

• Modify users and groups that they have created.

• Create and delete non-administrator file shares.

• Create, manage, delete and share local printers.

• Change system time (default user right).

• Stop or start non auto-started services.

By default, Power Users also have

• Modify access to the Program Files directory.

• Modify access to many locations within the HKEY_LOCAL_MACHINE \Software registry hive.

• Write access to most system directories including %windir% and %windir%\system32.

These permissions allow Power Users to

• Perform per-computer installation of many applications. For example, applications that do not modify Windows system files or do not modify HKEY_LOCAL_MACHINE \System.

• Run legacy applications that improperly store per-user data in per-computer locations (without receiving error messages).

Unfortunately, these permissions are also the same permissions that allow Power Users to

• Plant Trojan horses that, if executed by administrators or other users, can compromise system and data security.

• Make system-wide operating system and application changes that affect other users of the system.

Can Users install applications?

Users cannot install applications per computer, because they cannot write to system-wide locations. However, there is no reason why a (non-administrator, non-power) User cannot install an application per user, provided that the application setup program supports this. Such an application would have to be installed in the User's Profile directory, and would have to modify only HKEY_CURRENT_USER registry settings and per-user Start menu items. As a result, only the User who installed the application can run that application. This is the only secure way to allow untrusted users to install applications.

Is it possible to easily switch between user contexts?

Yes, because administrators have complete control over the operating system, it is critical that system administrators avoid logging in as an administrator when performing non-administrative tasks. This can protect your system from malicious code executing under the privileged security context. The most common scenario is downloading and executing code from the Internet.

To promote running under a least privileged context, the Windows 2000 operating system provides a convenient tool that allows administrators to log on as a User or Power User, then start trusted administrative programs under an administrative context without having to log off and log back on. The tool is called RUNAS.EXE. As an example, to start a command window under the administrators context:

RUNAS /u:computername\administrator cmd

Applications started from this command window inherit the parent's access token. Runas is also integrated into the Windows 2000 shell so that programs and shortcuts to programs can be started from the user interface under a different user's context. To use Runas from the shell, select an executable, and press Shift+Right Click.

What about domain controllers?

Domain controllers support a broader range of built-in groups than workstations or servers. For example, domain controllers support the notion of Account Operators and Print Operators. Rather than granting default access permissions to all of the Domain Controller built-in groups, file system and registry access on Domain Controllers is primarily granted to

• Authenticated Users

• Server Operators

• Administrators

Authenticated users, whether they are Account Operators, or Print Operators, or any normal User remotely accessing the domain controller, have the same restricted default permissions that Users have on workstations or servers (that is, Read access to System Locations, Full Control over their own profile and HKCU).

Server Operators on domain controllers are much more powerful than Power Users are on workstations or servers. For example, Server Operators can replace Windows System files and thus must be completely trusted users.

Note that the Power Users group does not exist in domain controllers, thus there is no backward compatibility mechanism for applications that ran under a User context on Windows NT 4.0-based domain controllers. In general, Microsoft does not recommend running applications on computers configured as domain controllers, and certainly not applications that require more than Authenticated User privileges in order to run successfully.

Top of page
Appendix A: Default File System ACLs for Power Users and Users
Table 4 describes the default access control settings that are applied to file system objects for Power Users and Users during a clean installation of the Windows 2000 operating system onto an NTFS partition. For directories, unless otherwise stated (in parentheses), the permissions apply to the directory, subdirectories, and files.

• %systemdir% refers to %windir%\system32.

• *.* refers to the files (not directories) contained in a directory.

• RX means Read and Execute.

Table 4 Default Access Control Settings for File System Objects

File System Object Default Power User Permissions Default User Permissions
c:\boot.ini
RX
None

c:\ntdetect.com
RX
None

c:\ntldr
RX
None

c:\ntbootdd.sys
RX
None

c:\autoexec.bat
Modify
RX

c:\config.sys
Modify
RX

\ProgramFiles
Modify
RX

%windir%
Modify
RX

%windir%\*.*
RX
RX

%windir%\config\*.*
RX
RX

%windir%\cursors\*.*
RX
RX

%windir%\Temp
Modify
Synchronize, Traverse, Add File, Add Subdir

%windir%\repair
Modify
List

%windir%\addins
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\Connection Wizard
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\fonts\*.*
RX
RX

%windir%\help\*.*
RX
RX

%windir%\inf\*.*
RX
RX

%windir%\java
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\media\*.*
RX
RX

%windir%\msagent
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\security
RX
RX

%windir%\speech
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\system\*.*
Read, Execute
RX

%windir%\twain_32
Modify (Dir\Subdirs)
RX (Files)
RX

%windir%\Web
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%
Modify
RX

%systemdir%\*.*
RX
RX

%systemdir%\config
List
List

%systemdir%\dhcp
RX
RX

%systemdir%\dllcache
None
None

%systemdir%\drivers
RX
RX

%systemdir%\CatRoot
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%\ias
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%\mui
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%\OS2\*.*
RX
RX

%systemdir%\OS2\DLL\*.*
RX
RX

%systemdir%\RAS\*.*
RX
RX

%systemdir%\ShellExt
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%\Viewers\*.*
RX
RX

%systemdir%\wbem
Modify (Dir\Subdirs)
RX (Files)
RX

%systemdir%\wbem\mof
Modify
RX

%UserProfile%
Full Control
Full Control

All Users
Modify
Read

All Users\Documents
Modify
Read, Create File

All Users\Application Data
Modify
Read

Note that a Power User can write new files into the following directories, but cannot modify the files that are installed there during text-mode setup. Furthermore, all other Power Users inherit Modify permissions on files created in these directories.

• %windir%

• %windir%\config

• %windir%\cursors

• %windir%\fonts

• %windir%\help

• %windir%\inf

• %windir%\media

• %windir%\system

• %systemdir%

• %systemdir%\OS2

• %systemdir%\OS2\DLL

• %systemdir%\RAS

• %systemdir%\Viewers

For directories designated as [Modify (Dir\Subdirs) RX (Files)], Power Users can write new files, however, other Power Users will only have Read access to those files.

Top of page
Appendix B: Default Registry ACLs for Power Users and Users
Table 5 describes the default access control settings that are applied to registry objects for Power Users and Users during a clean installation of the Windows 2000 operating system. For a given object, permissions apply to that object and all child objects unless the child object is also listed in the table.

Table 5 Default Registry ACLs

Registry Object Default Power User Permissions Default User Permissions
HKEY_LOCAL_MACHINE

HKLM\Software
Modify
Read

HKLM\SW\Classes\helpfile
Read
Read

HKLM\SW\Classes\.hlp
Read
Read

HKLM\SW\MS\Command Processor
Read
Read

HKLM\SW\MS\Cryptography
Read
Read

HKLM\SW\MS\Driver Signing
Read
Read

HKLM\SW\MS\EnterpriseCertificates
Read
Read

HKLM\SW\MS\Non-Driver Signing
Read
Read

HKLM\SW\MS\NetDDE
None
None

HKLM\SW\MS\Ole
Read
Read

HKLM\SW\MS\Rpc
Read
Read

HKLM\SW\MS\Secure
Read
Read

HKLM\SW\MS\SystemCertificates
Read
Read

HKLM\SW\MS\Windows\CV\RunOnce
Read
Read

HKLM\SW\MS\W NT\CV\DiskQuota
Read
Read

HKLM\SW\MS\W NT\CV\Drivers32
Read
Read

HKLM\SW\MS\W NT\CV\Font Drivers
Read
Read

HKLM\SW\MS\W NT\CV\FontMapper
Read
Read

HKLM\SW\MS\W NT\CV\Image File Execution Options
Read
Read

HKLM\SW\MS\W NT\CV\IniFileMapping
Read
Read

HKLM\SW\MS\W NT\CV\Perflib
Read (via Interactive)
Read (via Interactive)

HKLM\SW\MS\W NT\CV\SecEdit
Read
Read

HKLM\SW\MS\W NT\CV\Time Zones
Read
Read

HKLM\SW\MS\W NT\CV\Windows
Read
Read

HKLM\SW\MS\W NT\CV\Winlogon
Read
Read

HKLM\SW\MS\W NT\CV\AsrCommands
Read
Read

HKLM\SW\MS\W NT\CV\Classes
Read
Read

HKLM\SW\MS\W NT\CV\Console
Read
Read

HKLM\SW\MS\W NT\CV\ProfileList
Read
Read

HKLM\SW\MS\W NT\CV\Svchost
Read
Read

HKLM\SW\Policies
Read
Read

HKLM\System
Read
Read

HKLM\SYSTEM\CCS\Control\SecurePipeServers\winreg
None
None

HKLM\SYSTEM\CCS\Control\Session Manager\Executive
Modify
Read

HKLM\SYSTEM\CCS\Control\TimeZoneInformation
Modify
Read

HKLM\SYSTEM\CCS\Control\WMI\Security
None
None

HKLM\Hardware
Read (via Everyone)
Read (via Everyone)

HKLM\SAM
Read (via Everyone)
Read (via Everyone)

HKLM\Security
None
None

HKEY_USERS

USERS\.DEFAULT
Read
Read

USERS\.DEFAULT\SW\MS\NetDDE
None
None

HKEY_CURRENT_CONFIG
= HKLM\System\CCS\HardwareProfiles\Current

HKEY_CURRENT_USER
Full Control
Full Control

HKEY_CLASSES_ROOT
= HKLM\SW\Classes

• HKLM = HKEY_LOCAL_MACHINE

• SW = Software

• MS = Microsoft

• CV = CurrentVersion

• CCS = CurrentControlSet

• W NT = Windows NT

Certificate Authority (CA) service in Windows Server 2003

2005-08-22T01:18:00.000-07:00

How can I install the Certificate Authority (CA) service in Windows Server 2003?

Windows Server 2003 can be used as a Certificate Authority (also known as CA) to provide extended security by offering support for Digital Certificates.

Digital Certificates can be granted to users based upon their roles and group membership. For example, a regular user that wants to enroll for a certificate will only be allowed to enroll for a specific set of Digital Certificates, while another user that is a member of the Domain Admins group will be allowed to enroll for a different set of certificates that can be used for a variety of functions, including Recovery Agents, IPSec, SSL and so on.

User Digital Certificates are valid for different purposes, including:

Allowing data on disk to be encrypted
Protecting e-mail messages
Proving the user's identity to a remote computer
and more.

Note: There may be scenarios where a company might opt to use 3rd party issued Digital Certificates instead of creating their own, especially when that company's users will be dealing with out-of-the-company users, exchanging encrypted e-mail messages between themselves and these outside users, or when using SSL on a secured web site. This is because the outside users might not be willing to trust the company's internal CA.

Step 1: Install the IIS Service
In order to install the CA you will first need to install IIS on a Windows Server 2003 computer. On Windows Server 2003 IIS is not installed with the default Windows 2003 installation.

Click Start > Control Panel > Add or Remove Programs.

In Add or Remove Programs, click Add/Remove Windows Components.

Under Components, click on Application Server (but do NOT select it) and press on the Details button.

In the Application Server window click to select IIS and click Ok.

Click Next

After the wizard completes the installation, click Finish.

Step 2: Install the CA Service
To install the CA service perform the following steps:

Click Start > Control Panel > Add or Remove Programs.

In Add or Remove Programs, click Add/Remove Windows Components.

Under Components, select Certificate Services.

You will get a warning about domain membership and computer renaming constraints, and then click Yes.

On the CA Type page, click Enterprise root CA, and then click Next.

On the CA Identifying Information page, in the Common name for this CA box, type the name of the server, and then click Next.

On the Certificate Database Settings page, accept the defaults in the Certificate database box and the Certificate database log box, and then click Next.

You will get a prompt to stop Internet Information Services, click Yes.

Enable Active Server Pages (ASPs), by clicking Yes.

When the installation process is completed click Finish.

Step 3: Obtain a User Digital Certificate from the CA
After installing and configuring the CA on your domain you will now need to ask your users (at least those who will require message security) to enroll for a Digital Certificate.

In order to obtain a Digital Certificate from the CA please follow the steps outlined in the Obtain a Digital Certificate from an Online Certificate Authority (CA) article.

Related articles
You might also want to read the following related articles:

Configure Message Security in Exchange 2003
Configure Message Security in Outlook 2003
Configure Message Security in OWA 2003
Obtain a Digital Certificate from a 3rd Party Certificate Authority (CA)
Obtain a Digital Certificate from an Online Certificate Authority (CA)

Big Brother and Ndisuio.sys

2005-06-18T22:25:00.000-07:00

Big Brother and Ndisuio.sys
A new Internet phenomenon?
By Red Squirrel

Ndisuio.sys, a very mysterious system file is present in Windows XP and is a driver for wireless things such as wi-fi and bluetooth. However, there have been many issues with this file downloading immense amounts of data and perhaps causing activity that is "big brother"ish.

The fact that hardly any information on this file downloading data is available by Microsoft makes things quite suspicious about it. It has even been noted that it looked as if it was transferring data to major companies like Comcast, Road Runner, Time Warner, BTC and Verizon.

The good news is, it turns out this file duplicates data that is sent/received, so wherever you go, it will also transfer the data to that file but it does not leave the computer/network so it's not spyware. So it's not as much of a big brother situation then it looks like. It simply performs internal communication tasks and stands for NDIS user I/O, hence, NDISUIO. NDISUIO is also used as a driver by many developers as it makes certain wireless network tasks easier such as implementing it for 802.11x connections. Some firewalls also use it as it can get the data in order to filter it.

But duplicating this data can hog resources for no reason, so disabling it is the best thing to do. The data rate of this file's received data is huge, so that indicates that the data transfer is not over the Internet, but locally. So it's just a duplicate of network activity but because it's local everything transfers faster but uses more resources then casual internet usage as there's more data involved at a given time span of 1 second, for example.

To disable this file, go to the control panel, administration tools, services, Wireless Zero Configuration, double click and disable it. This file is probably required to run if you use any linksys wireless devices.

Because I use win2k and not XP I have never experienced anything with this file myself, so this is only a summary of what this file does and what it is for and not based on my own experience but researched information.

-Red Squirrel
IceTeks Owner

Here are a few links having to do with this file:

This was a thread here at Iceteks discussing about this file's strange network behavior.
http://www.iceteks.com/forums/show.php/showtopic/1290

NDIS User Mode I/O (NDISUIO) Version Dependencies
http://www.ndis.com/pcakb/KB01010301.htm

DHCP Does Not Obtain a New Address When EAP Reauthenticates Across Access Points with IP Subnets That Differ
http://support.microsoft.com/default.aspx?kbid=822596

NDIS User-mode I/O Driver
http://msdn.microsof...fndisuser-modeiodriver.asp

Microsoft Computer Browser

2005-06-17T01:58:00.000-07:00

The browser service maintains a list of the domain name or workgroup name the computer is in, and the protocol being used for each computer on the network segment being served by the computer running the browser service. On each network segment, a master browser is elected from the group of computers located on the segment that are running the browser service.

The master browser is responsible for collecting host or server announcements, which are sent as datagrams every 12 minutes by each server on the network segment of the master browser. The master browser instructs the potential browsers for each network segment to become backup browsers. The backup browser on a given network segment provides a browse list to the client computers located in the same segment.

NOTE: In a Windows NT domain structure, the primary domain controller (PDC) is always selected as the domain master browser. Only the PDC can be a domain master browser. If a PDC is not present, a domain master browser is not available and you are unable to obtain browse lists from workgroups other than the workgroup you are located in.

On a given network segment, there is only one master browser. All domain controllers other than the PDC are designated as backup browsers. Additionally, one backup browser is allocated for every 32 computers on the network segment.

In a workgroup configuration containing Windows NT Workstation-based computers, there is always one master browser. If there are at least two Windows NT Workstation-based computers in the workgroup, there is also one backup browser. For every 32 Windows NT Workstation-based computers in the workgroup, there is another backup browser.

If there is not a domain controller present on a given network segment, then an election process is started that chooses a master browser and backup browser from the computers on the segment using the following order of priority:

Windows 2000 Server
Windows 2000 Professional
Microsoft Windows NT 4.0 Server Enterprise Edition
Microsoft Windows NT 4.0 Server
Microsoft Windows NT 4.0 Workstation
Microsoft Windows 98
Microsoft Windows 95
Microsoft Windows for Workgroups 3.11
Domain Master Browser Role
Because the browser service is bound by broadcast segments and each master browser maintains its own separate list, there must be a way to merge these lists into a single domain-wide list. This functionality is provided by the domain master browser that is the PDC for the domain. This functionality is not required for network protocols other than Transmission Control Protocol/Internet Protocol (TCP/IP).

The PDC has is also responsible for connecting to its primary Windows Internet Name Service (WINS) server every 12 minutes to obtain a list of all the DomainName type <1b> entries that are registered by the PDCs throughout the enterprise. This is done by issuing an MSRPC R_WinsGetBrowserNames request. These names, along with the workgroup announcement datagrams collected by the master browsers throughout the WAN, build the full list of domain and workgroup names. The names discovered by workgroup announcements take precedence over those obtained from WINS. These domain and workgroup names also contain the name of the server registering any given computer in the browse list. In the event that a WINS server is not available, or it is not registered, the client's browser requests the list of servers from the computer that registered the name. This operation is done on behalf of the client by its browser and is called a double-hop.

The PDC merges all the lists gathered by the master browsers on each segment across the WAN. Every 12 minutes, the master browser connects to the PDC to obtain the domain-wide list. The list is obtained by first issuing a NetServerEnum request with a flag of 0xFFFFFFFF. This request retrieves the complete list of servers within the domain. The master browser then issues the same request with a flag of 0x8000000, which requests all of the domain and workgroup names.

To signal the PDC to retrieve the list collected by this master browser, the master browser sends the PDC a directed master announcement frame over User Datagram Protocol (UDP) port 138. This signals the PDC to immediately connect to the master browser and retrieve its list. This communication is also performed with two NetServerEnum requests. First, a NetServerEnum request with flag 0x40000000 is issued to request the local list of servers collected by the master browser. Then, a NetServerEnum request with flag 0xC0000000 is sent to retrieve the local workgroup announcement frames sent by the master browser of other domains or workgroups on its segment. Each backup browser on the segment issues a NetServerEnum request with flags of 0xFFFFFFFF and x80000000 at 12-minute intervals to obtain the complete list of servers, domains, and workgroup names.

Registration And Propagation Time
Because the browser service relies on server broadcasts, its communication is connectionless and by definition unreliable. When a server starts, it immediately sends a host announcement frame. This process is repeated at 4 minutes and again at 8 minutes. The process is then repeated every 12 minutes thereafter.

Allowing for the loss of a few datagram frames, it is reasonable to expect that the network segment's master browser will add a given computer's name to the browse list within 12 minutes after startup. Beyond this point, connection-oriented traffic is used and the sequences are more deterministic. Within 12 minutes, the segment's master browser will connect to the PDC to obtain the domain-wide list, and at the same time the PDC will connect to the master browser and learn of the new server.

Master browsers on remote segments also connect to the PDC at 12-minute intervals and soon learn of a new server. Within 12 minutes of the remote master browser learning of a new computer's name, all the backup browsers connect to their master browser. At this point, all browsers on a remote segment know about the new server. In a multi-segment WAN environment, the maximum amount of time it should take for all clients within the domain to see the new computer is 48 minutes (12 + 12 + 12 + 12). On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (24 minutes).

Removing computers from the browse list may take more time. To allow for lost datagram frames, the master browser does not remove a server from its list until 3 announcement periods have passed. If the server is not shut down gracefully or if network connectivity is lost, the server can remain in the master browser's list for up to 36 minutes. After this time, the PDC is notified to remove the server name. The same communication flow follows to remove a server's name. Within 12 minutes, a master browser on a remote segment obtains the domain-wide list from the PDC, and within 12 minutes each backup browser connects to the master browser. This process can take as long as 72 minutes to finish (36 + 12 + 12 + 12). If the server is shut down gracefully, the browser sends a single Host Announcement frame indicating that it is no longer acting as a server. Upon receipt of this datagram, the master browser immediately removes the server from its local list. On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (36 minutes).

Because a server's browser role is defined dynamically with periodic elections, determining the flow of communication used to provide the browse list to a specific client computer can be difficult. If a master browser is shut down gracefully, the master browser forces an election for a new master browser during shutdown. If the backup browser that wins the election has been present on the network long enough to receive a complete browse list, it starts as a master browser with a fully populated browse list, and browse functionality continues on the network segment without interruption.

If a server that was acting as the master browser is not shut down gracefully or if the master browser's force election request datagram is lost, there may be a delay before browse functionality is available on the network segment. An election of a new master browser is caused if a client computer requests a browse list and is unable to locate a master browser. It may take up to 12 minutes for a backup browser to discover that no master browser is present, depending on network usage.

Name Resolution Requirements
Name resolution across the domain is critical for the distributed browsing model to operate. All computers across the WAN that are potential master browsers must be able to resolve the DomainName type <1b> entry for the PDC. After a potential master browser receives a positive response to the query for a PDC, the master browser must also be able to resolve the computer name type <00> entry of the PDC. The PDC must be able to resolve the names of all computers that are potential master browsers in order to be able to connect to them. The PDC listens for directed master announcements from the master browsers on UDP port

This announcement triggers the PDC to resolve the computer name type <00> of the master browser, and to request the browse list maintained by the master.

Once a browse list is presented to a client computer, the client computer must resolve the NetBIOS name entry of any computer listed in order to view shared resources. Therefore, all client computers must be able to resolve the Internet Protocol (IP) address of all computers in the domain. In most networks configurations, this means that the distributed WINS infrastructure must be working properly.

Sharing access denied - XP

2005-06-16T01:34:00.000-07:00

The problem is on the machine you are trying to connect to.
Simple file sharing uses the guest account on the machine you are connecting
to.
This requires that the Guest account is:

1) Enabled; and
2) Granted permissions to log in across the network.

Starting with (1):

The option to turn the Guest account on and off from the control panel is
mis-labeled. It does not actually disable the account when you turn it off
here. It just sets an option on the account called Deny Local Logon. What
is required is that the guest account is active behind the scenes, which is
what is required for network access.

On XP-Pro:
R-click 'My Computer' | Manage | Local Users and Groups | Users
Check the Guest account does not have a red X on it.
If it does, then double-click the Guest account and un-check 'Account is
Disabled'.

XP Home is missing some essential tools to manipulate user accounts and
permissions. So on XP-Home, we need to use a command. ( This will work on
both XP-Home and XP-Pro ) :

Go to a command prompt ( not start | run ), and type:

net user guest

The output should contain a line like this:

Account active Yes

If it shows the account is not active, then type:

net user guest /active:yes

( It can remain off in the user control panel app, so long as it is enables
as per the above. )

Now, on to (2).
( This is the cause of your error. )

On XP-Pro, start | Run | secpol.msc
Local Policies | User Rights Assignments

Double-click the policy "Access this computer from the network".

Add the 'Everyone' group if it's not there:
'Add User or group' button;
Click 'Advanced' button;
Click 'Find Now'
Select 'Everyone' on the list, and OK all the way out.

Now double-click the policy "Deny access to this computer from the network".
Remove the Guest account if it's listed there.

OK your way out of there.
That should grant the necessary permissions.

For XP-Home,

Download and install the Windows 2003 Server Resource Kit Tools:
http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

To run it, go to:
Start | All Programs | Windows Resource Kit Tools | Command Shell.

A command prompt window will open.
Type these commands, be carefull to use capital letters exactly as shown:

net user guest /active:yes

( this enables the guest account, necessary for XP-Home Simple File
Sharing )

ntrights +r SeNetworkLogonRight -u Guest

( This grants the user 'Guest' the rights to log on across the network )

ntrights -r SeDenyNetworkLogonRight -u Guest

( This ensures the Guest account is not explicitly prohibited from accessing
the machine across the network. )

Then check this worked by using these commands:

showpriv SeNetworkLogonRight
showpriv SeDenyNetworkLogonRight

Ensure the Guest account is listed in the first, and not in the second.

Use DHCP Class to deny Internet access to unauthorized machines

2005-02-15T07:06:00.000-08:00

http://techrepublic.com.com/5100-6265-5498436.html

TechRepublic provides content, context and community to IT strategists, network administrators and other enterprise computing professionals so they can be more successful. Enjoy this article and if you find it useful, join TechRepublic to take full advantage of all our services.
http://techrepublic.com.com/registration.html

Run Terminal Services in Remote Administration Mode

2005-02-12T00:48:00.000-08:00

Many remote management tools exist to help you remotely manage your organization's servers. Some examples of these tools include pcAnywhere and Virtual Network Computing (VNC). Of course, each tool has advantages and disadvantages.

When you need to manage a server remotely on the LAN or via a VPN connection to a remote network, Terminal Services just might be your best solution. All you need to do is enable Remote Administration Mode for Terminal Services on the server.

To enable Terminal Services, open the Add/Remove Programs applet in Control Panel, and click Add/Remove Windows Components. Scroll through the list of components, and select Terminal Services. Click Details, select Enable Terminal Services, click OK, and click Next.
The Windows Components Wizard then asks if you want to run Terminal Services in Remote Administration Mode or Application Server Mode. Choose Remote Administration Mode, and click Next.

When prompted, provide the Windows Server CD, and restart the server after installation is complete. After the server reboots, you'll be able to connect to the server using Remote Desktop Connection.

SysLog Servers for NT/2000/XP

2005-01-28T22:31:00.000-08:00

SysLog Servers for NT/2000/XP

Don't know what a syslog is? It is essentially the eventlog for Unix boxes. Unix oriented shops solved the consolidation of log files with Unix syslog based management systems using a central syslog daemon which is the source of all monitoring and alerting in these environments. A syslog daemon normally listens for incoming syslog messages on UDP port 514 and then decodes and processes the messages for logging and notification purposes. If you need to integrate Windows NT, Windows 2000 and Windows XP into the syslog system, there are products to do this.
Adiscon's Eventlog Reporter Syslog integration for Windows. Syslog facility codes are fully supported. Trialware version available. Part of their Monitorware line of products.
BackLog - Windows NT Event Redirection BackLog is a Windows NT service that facilitates the real time central collection and processing of Windows NT Event Log information. All three event logs (Application, System and Security) are monitored, and event information is converted to comma delimited text format, then delivered over UDP to a remote server.
Windows NT syslog service This program runs as a service under Windows NT 4.0 and Windows 2000. It formats all System, Security, and Application events into a single line and sends them to a syslog(3) host.
SANS : Practical Implementation of Syslog in Mixed Windows Environments for Secure Centralized Audit Logging
For more information, see my general Logging / Syslog / Log Analysis Resources tip or Adison's How to Monitor Windows NT from Unix if you interest is limited to Windows.
If you are predominantly Windows-based and need to centrally manage devices such as Cisco routers which are syslog-based? Need a syslog server for Windows?
WinSyslog web site
SL4NT 2.1 syslog deamon for windows runs as a service
Kiwi's Syslog Deamon for Windows freeware
3COM has a free syslog daemon
MT Syslog Deamon

How a Kerberos Logon Works in Windows 2000

2004-11-12T19:04:00.000-08:00

As most of you are aware, Windows 2000 includes a new authentication package, which is Microsoft's implementation of MIT's Kerberos protocol. This protocol is much more secure than NTLM and NTLMv2. And with that, I'm going to show you how a client logon happens with Kerberos.

Bob comes into work in the morning, grabs his coffee, and sits down at his workstation. He looks at the Windows 2000 professional logon at the logon screen, hits ctrl+alt+del, and proceeds to type his username, password, and after being authenticated by a Windows 2000 domain controller, logs onto his domain. He starts Microsoft Outlook, to take a look at this morning's pile of email. This seems like a simple process, but that's far from the truth.

Let's take a look at what happened in the past few seconds. Domain Logon Authentication When Bob pressed "Enter" after typing his password, the Kerberos client on his workstation converted his password to an encryption key. Kerberos is based on the concept of symmetric encryption keys, which means that the same key is used to encrypt and decrypt a message. This is also referred to as a shared private key. After the Kerberos client converted Bob's password to an encryption key, it's saved in the workstation's credential cache.

The workstation then sent an authentication request to the Domain Controller, or KDC (Key Distribution Center is a Kerberos term, used to describe the service that distributes the "keys to the kingdom"). The authentication request identifies Bob, and names the service that he's requesting access to, and some pre-authentication data, that proves that Bob knows the password.

The first portion of the authentication request identifies Bob, and asks for access to the TGS(Ticket Granting Service). The TGS is the service on the KDC that issues tickets for access to other services. All of the services within the Kerberos domain trust the TGS, so they know if a ticket was issued by the TGS, that the user successfully authenticated (him/her) self, and is really who he claims to be.

The second part of the authentication request contains the pre-authentication data, and is a generic timestamp, encrypted with Bob's long-term key (or password in this case) When the KDC receives the authentication request, it checks the local AD database for Bob's password. Decrypts the pre-authentication info that was sent in the package, and if the timestamp is within the permissible guidelines (allowable clock difference, usually of 5 minutes or so), sends Bob a TGT (Ticket Granting Ticket) that he's going to use to access the TGS in the future.

But even this process isn't so simple (Kerberos is much more complicated than NTLM). To accomplish this task, the KDC creates a session key for itself and Bob to use in their future communications, then it encrypts that session key with Bob's password, and embeds another copy of the session key and some authorization info about Bob (This authorization info is the list of Bob's SID's (SID history, group membership, and Bob's own SID) which is used where ACL's are applied.). It encrypts all of this with it's own long-term key. (The portion that was encrypted with the KDC's long-term key is the actual TGT) The Kerberos implementation in Windows 2000 places the SIDS in the TGT in a field that is defined as optional in the RFC's, which Win2k uses for access control information, which extends Kerberos from not only authentication, but a piece of the access control puzzle as well. When Bob's workstation receives a reply from the KDC, it decrypts the session ticket with Bob's password, and stores this in the credentials cache. This is the authentication info that Bob's workstation will use to communicate with the KDC from now on, the next time Bob logs on, the session ticket will be completely different, as the KDC doesn't reuse it's session keys. The workstation also extracts the TGT, which will still be encrypted with the KDC's long-term key, (which Bob's workstation doesn't know) and stores the encrypted TGT in it's credentials cache.

"What does all of this have to do with the way I access resources?" you might ask. I'm going to give you a bonus, here's how resource access works in the same domain, with the user being authenticated by Kerberos. Authentication works a bit differently when you are traversing trusts. I will show you that process in an upcoming article.

Resource Access Authentication Since Bob was authenticated by the KDC, he received a TGT, which allows him to request access to other resources. Since Bob needs to access the word doc reports.doc on the FILESERV1 fileserver, he's going to request access to FILESERV1. Bob might be opening the document from the recent documents menu, or browsing for it in Windows Explorer, however Bob is opening the file, is irrelevant. The Kerberos client performs all authentication in the background, without any user intervention. Below is a detailed process of the entire negotiation.

First Bob's workstation sends a message to the domain controller that granted it's TGT. The message is a Ticket Granting Service Request, that includes Bob's username, the authenticator, the TGT that was sent back to Bob's workstation during the logon, and the name of the service that Bob is requesting access to. (In this case it's FILESERV1) When the KDC receives the message from Bob's workstation, it decrypts the TGT portion of the message, with it's own private long-term key, and pulls out the session key that it embedded during the logon session. It uses the session key to decrypt the authenticator section of the message. If everything checks out OK, it creates a session key for Bob to utilize when talking to FILESERV1.

The KDC now constructs a message to Bob in 2 parts.

The first part is the actual session key for Bob to use when talking to the FILESERV1 file server, which is then encrypted in Bob's logon session key.

The second part is the session key that Bob is going to use to talk to the FILESERV1 server, but it's encrypted in FILESERV1's long-term key. This message is sent to Bob's workstation. When Bob's machine gets this message, it decrypts the first part of the message and saves the session key for FILESERV1 in it's credentials cache. Then, it pulls the second portion of the message out (which is encrypted in FILESERV1's long term key, which by the way, Bob's workstation does not know the key by which it was encrypted) and also stores it in it's credentials cache.

Now Bob's workstation is going to access the FILESERV1 server. Bob's machine sends FILESERV1 a Kerberos App Request, which sends the has in it an authenticator encrypted in the session key that the KDC gave to Bob to use when talking to FILESERV1, and the encrypted ticket that the KDC gave to Bob, which is the Bob-FILESERV1 session key, encrypted in FILESERV1's long-term key, that the KDC stores in the Database.
When FILESERV1 receives this message, FILESERV1 decrypts the ticket with it's own long-term key, and is able to read the session key that the KDC gave to Bob for use with FILESERV1. It then decrypts the rest of Bob's message with the session key, viola', an authenticated session is established.

I know this seems extremely complicated, but in relative terms of authentication, it's a simple, and secure process. I'm more than satisfied with Microsoft's implementation of Kerberos in Windows 2000, I think it's a long needed building block for a secure OS. We won't see full benefit of Kerberos, until all of our clients are Win2k, since AD servers still support the old NTLM, and NTLM2 authentication protocols, but I think that day is coming soon.... There is another set of events that occurs after this exchange, that set of events refers to access control, I'll also explain that in another article.

Kerberos vs. LDAP for authentication

2004-11-12T18:13:00.000-08:00

The SASL/GSS mechanism supported by the LDAP server is used to securely access the directory. Using SASL/GSS and LDAP does not help authenticate a user so he/she can use an application which then presents the users identity to another application components in a secure manner - this is one of the many requirements for application security which Kerberos is idealy suited.I think we need to compare the LDAP directory and Kerberos protocol in order to answer the original question asked. Admitedly, if SASL/GSS is used to securely access a directory so that a password can be read and compared, then LDAP can be used to authenticate a user.I have provided a short list of some differences, not necessarily a complete list so maybe others on this email discussion can add comments and think of other important differences ?LDAP server for user authentication- can be used to store password + other information about users.- useful for simple user authentication requirements where checking of password is all that is required.Kerberos for user authentication- uses security credentials which have a lifetime - LDAP does not have this capability- built in prevention from network replay attacks and protect against other network security concerns - LDAP does not protect against these issues- removes the need to pass any form of password across a network - LDAP requires password transmission- A protocol that alows support for userid/password, token card, smart card authentication and other forms of user authentication - LDAP is only suited to userid/password- works well in a client/server and multi-tier environment especially when using credential delegation or impersonation- can be used to setup a security context between application components on the network - LDAP cannot be used for this.- provide mutual authentication, integrity, confidentiality services - LDAP does not do any of these- makes single signon easy, especially since Microsoft Active Directory does the Kerberos authentication when a user logs onto a MS network- works well in a heterogeneous environment- supported and utilised by a growing number of application vendors and standards- a strategic protocol in many ways because of having many uses - it can even be used very effectively to allow an unattended application to authenticate itself to another application (e.g. ftp -> ftpd).

Part 5: Active Directory Naming Paths

2004-11-12T01:14:00.000-08:00

One of the big benefits of Active Directory over the "flat" domain structure of Windows NT 4 (and earlier) domains is that objects can be stored in a hierarchical folder-like structure. In earlier domains, however, at least you knew where all of the objects were - they were in one big long list - no searching for them, just scrolling (and scrolling, and scrolling). In Active Directory, objects can be stored down in several layers of Organizational Units (OUs). So how does Active Directory keep track of where these objects are? It uses LDAP (Lightweight Directory Access Protocol) naming paths. These naming paths can take three forms: Distinguished Names, Relative Distinguished Names and Canonical Names.
Distinguished NamesEach AD object has a distinguished name - and no, that doesn't mean they are called "Sir" or "Madam." By distinguished, we mean that the name itself distinguishes the exact location of the object in the directory. There are several notations that are used in the distinguished name:

DC
Domain Component
Part of the DNS name of the domain such as COM or EDU
OU
Organizational Unit
One of the containers in AD that holds other objects
CN
Common Name
Objects in AD, such as users, computers, printers, etc.
These components can be used more than once in a distinguished name, if necessary, to accurately name the path to the object. For instance, the user Fred Jones in Accounts Receivable, in Accounting at My Company might have a distinguished name like this:
CN=Fred Jones,OU=AR,OU=Accounting,DC=mycompany,DC=com
In this example, you can see that there are two OU components, and to DC components.

Relative Distinguished NamesThe Relative Distinguished Name is simply the portion of the Distinguished Name that uniquely identifies an object within the object's parent container. For instance, Fred's Relative Distinguished Name from the example above, would be:
CD=Fred Jones
Keep in mind that the user Fred Jones in the Shipping department might also have the exact same Relative Distinguished Name, though his Distinguished name would, of course, indicate that his account was in a different OU.

Canonical NamesThere is a third naming path that Microsoft sometimes refers to. This is just a different way of displaying the distinguished name (that is easier to read), and looks like this:
mycompany.com/Accounting/AR/Fred Jones
It not only removes the notation for the Distinguished Name (e.g.: DC=) it is also the reverse order of the Distinguished Name.

Part 4: Active Directory Schema

2004-11-12T01:13:00.000-08:00

Understanding that all resources in Active Directory are represented by objects, and that all objects have attributes, we can now understand that the schema contains the definitions for all these objects and attributes. Put another way, the schema is the rules that govern what objects can be in the directory, and what attributes those objects can have.
An Active Directory forest can have only one schema, and all domains in that forest share the same schema. This ensures that all objects in the forest conform to the same set of rules. The schema can be changed, or extended, to include new definitions. The schema is protected from unauthorized changes by permissions, similar to other Active Directory objects.
The schema is made up of two things: object classes, and attributes.
Object Classes:We know that there are objects represented in Active Directory, such as the user "Bob," or the printer "Accounting." These objects are examples of the object classes "User" or "Printer." Every object that can be created in AD is an example of a object class. So one of the things that the schema is made up of is a list of all of the possible object classes. Every new object that is created must belong to an object class in this list.
Attributes:A list of all of the possible attributes for object classes is the second part of the schema. These attributes are defined just once in this list, but can be used in multiple object classes. For instance, the attribute "Location" may be used for the object classes of both printers and computers, but it is defined only once in the schema. By defined, we mean that it is given a unique name, as well as a syntax. The syntax tells what data type the attribute is. The schema keeps track of which attributes are used with each object class, so that when a new object of the class "User" is created, it will have all of the same attributes as all the other user objects (full name, telephone, etc.).
The schema itself is actually stored inside Active Directory, as opposed to being read in from a text file, as is common with some databases or directories. According to Microsoft, this has three advantages:
The schema is dynamically available to user applications, so they can read it and discover what object classes and attributes are available for use.
The schema is dynamically updateable, so that an application can extend the schema (add object classes and attributes) "on the fly."
The schema can be protected using DACLs (discretionary access control lists), enabling only authorized users to make schema changes.
The schema can be a challenging concept to understand. Fortunately, it is rarely necessary for changes to be made, and users must have the appropriate permissions to make those changes. For more in-depth information on the schema, particularly regarding extending the schema, look to the Windows 2000 Server Resource Kit books (specifically the Distributed Systems Guide).

Part 3: Active Directory Objects

2004-11-12T01:12:00.000-08:00

So far we've briefly touched on Active Directory in general, and the benefits of using it, but what does it really do? In simplest terms, Active Directory is really just a database of information about Objects. In Active Directory, every resource is represented as an object. This includes real physical objects, such as printers, computers, servers, etc., as well as logical, or virtual (cyber?) objects, such as users, groups, sites, domains, etc. No matter what it is, if it goes in Active Directory, it is pretty much an object.
Furthermore, each object that resides in AD has properties, or attributes. These attributes are different depending on the type of object. For instance, user objects have such attributes as "First Name" or "Zip Code" or "Title" to name only a few. Computer objects, on the other hand, have such attributes as "Role" or "Description" or "Location." Objects can and do have hundreds of attributes, some of which can be manipulated or changed, and some of which are assigned by the system. One of the handy things about an object's attributes is that you can search on them. For instance, if you are looking for a nearby printer, you can search on the location attribute for printer objects.
The tool used most commonly for working with AD objects is the Active Directory Users and Computers tool. You can view or modify the attributes of many objects in this tool by simply right-clicking an object and choosing Properties (or by simply double-clicking the object in most cases). Of course, what you can do with an object, including simply viewing its attributes, depends on the permissions that you have to the object.
Since all resources in the network are represented in AD as objects in a centralized database, these resources can easily be administered from a central location (or locations), and by a single or multiple administrators

Part 2: Benefits of Active Directory

2004-11-12T01:11:00.000-08:00

So far we've pointed out that Active Directory is a complex networking technology that requires planning in intimate detail in order to work properly when implemented. So why bother? What benefit does AD bring that would make it worth the trouble? The answer, of course, is that "it depends." However, even in a small and simple network, the benefits can outweigh the costs of design and implementation.
ScalabilityOne of the most apparent advantages to using Active Directory over using either NT4 Domains or a Workgroup model is that Active Directory can accommodate size. In a workgroup environment, a user account with password has to exist on each computer with shared resources. If you have three servers and ten users, that means creating thirty user accounts total, and each user would have to remember or synchronize three passwords each. AD also overcomes the limitations and work-arounds for large enterprises using NT4 domains. Active Directory domains can contain many more groups and users, rendering the Account domains, and Resource domains from NT4 obsolete.
Organization - MacroActive Directory is tied tightly to the DNS structure, and follows the DNS hierarchy for domains. In this way a large company can organize its domains similar to the business structure. If a business has operations in several different regions of the world, it can organize the domain along those lines: europe.domain.com, australia.domain.com, asia.domain.com, etc. Active Directory introduces the concept of the "forest" of domain trees, which share certain things in common, but remain separate domains for administrative purposes.
Organization - MicroActive Directory is created hierarchically, allowing for better organization and ease of use at the resource level, too. No longer are all of the users and groups organized in a single list, as in User Manager for NT4 Domains. Sub-containers, called Organizational Units (OUs) can be created, so that, for instance, all of the user, groups, printers, etc., for a single geographic location can be placed together, making them easier to find and administer.
Centralized Management/ControlWith a single set of management tools, the entire Directory can be managed from a single location. AD also allows for much more granular delegation of rights, so that certain administrative tasks can be delegated, while still retaining a secure environment.
Single Sign-onActive Directory brings us that much closer to the administrator's dream of single sign-on for users. This means only one login name to remember, one password to remember and change, and so on. As more applications become AD-enabled, this dream becomes a reality. Imagine, for instance, when an accountant leaves the company, disabling a single AD account, rather than disabling the NT domain account, the AP/AR software account, the Payroll software account, etc.
Ultimately, you and/or your company will have to evaluate the risks versus the rewards of implementing Active Directory in your computing environment, but in most cases, I believe it will be a step forward.

Part 1: Introduction to Active Directory

2004-11-12T01:09:00.000-08:00

Active Directory: you can't buy it, you can't touch or hold it, and yet most Windows 2000-based networks rely on it to function properly. So what exactly is Active Directory? It's a simple question, but the answer becomes more complex the more you discuss it. In simplest terms, Active Directory is a service (or group of services) that runs on Windows 2000 servers. More specifically, you could say that Active Directory is a "directory service" for Windows 2000. This service is used to store and organize information about the network and the resources that are available on the network. More importantly, Active Directory can be used to control access to network resources.
Microsoft refers to Active Directory as the way to "provide a consistent way to name, describe, locate, access, manage, and secure information about resources" on a Windows 2000 network.
Directory services are not a new concept: Novell's NDS instantly comes to mind when thinking about directories, as well as DNS, and even Microsoft Exchange has had its own directory for years.
If you are familiar with Windows NT (3.x & 4.x) domains, you will be able to appreciate the features that Active Directory brings to a Windows network. Active Directory brings a hierarchical structure to the domain concept of earlier versions of NT. In comparison, it's like using a single pile of lose papers on your desk as a way of organizing your work (NT domains), compared to placing those loose papers in labeled hanging folders in a filing cabinet (Active Directory).
As much as Active Directory adds in functionality, organization and user experience, it also adds much more complexity in design, implementation and support. Planning was important when implementing an NT 4 domain; it is imperative when implementing Active Directory.
Over the next few features, we will begin looking at some of the benefits of using Active Directory, as well as some of the properties of Active Directory, best practices for implementing it, technologies that it depends on (e.g.: DNS), and technologies that depend on it (e.g.: Group Policy).

Windows 2000 Startup and Logon Traffic Analysis

2004-10-25T01:34:00.000-07:00

http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/w2kstart.mspx

Active Directory

2004-10-25T01:24:00.000-07:00

A structure consisting of one domain that is simultaneously one forest consisting of one tree is not only possible, but may be the optimal way to organize your network. Always begin with the simplest structure and add complexity only when you can justify doing so.

Transitive trusts
Each time you create a new domain in a forest
forest
One or more Active Directory domains that share the same class and attribute definitions (schema), site and replication information (configuration), and forest-wide search capabilities (global catalog). Domains in the same forest are linked with two-way, transitive trust relationships., a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child domains are added to the new domain, the trust path
trust path
A series of trust relationships that authentication requests must follow between domains. Domain controllers determine the trust path for all authentication requests between a domain controller in the trusting domain and a domain controller in the trusted domain.flows upward through the domain hierarchy
domain hierarchy
The parent/child tree structure of domains.extending the initial trust path created between the new domain and its parent domain.
Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.
Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated at any other domain in the forest. With a single logon process, accounts with the proper permissions can access resources in any domain in the forest. For more information, see Authentication.

Trees
In the Windows 2000 operating system, a tree is a set of one or more domains with contiguous names. If more than one domain exists, you can combine the multiple domains into hierarchical tree structures. One possible reason to have more than one tree in your forest is if a division of your organization has its own registered DNS name and runs its own DNS servers.
The first domain created is the root domain of the first tree. Additional domains in the same domain tree are child domains. A domain immediately above another domain in the same domain tree is its parent.

Forests
An Active Directory forest is a distributed database, which is a database made up of many partial databases spread across multiple computers. Distributing the database increases network efficiency by letting the data be located where it is most used. The forest's database partitions are defined by domains, that is, a forest consists of one or more domains.
All domain controllers in a forest host a copy of the forest Configuration and Schema containers in addition to a domain database. A domain database is one part of a forest database. Each domain database contains directory objects, such as security principal objects (users, computers, and groups) to which you can grant or deny access to network resources.
Often, a single forest, which is simple to create and maintain, can meet an organization's needs. With a single forest, users do not need to be aware of directory structure because all users see a single directory through the global catalog. When adding a new domain to the forest, no additional trust configuration is required because all domains in a forest are connected by two-way, transitive trust. In a forest with multiple domains, configuration changes need be applied only once to affect all domains.

Organizational Units
New in the Windows 2000 operating system, organizational units (also called OUs) are a type of directory object into which you can place users, groups, computers, printers, shared folders, and other organizational units within a single domain. An organizational unit (represented as a folder in the Active Directory Users and Computers interface) lets you logically organize and store objects in the domain. If you have multiple domains, each domain can implement its own organizational unit hierarchy.

Global Catalog
The Windows 2000 operating system introduces the global catalog, a database kept on one or more domain controllers. The global catalog plays major roles in logging on users and querying.
By default, a global catalog is created automatically on the initial domain controller in the Windows 2000 forest, and each forest must have at least one global catalog. If you use multiple sites, you may wish to assign a domain controller in every site to be a global catalog, because a global catalog (which determines an account's group membership) is required to complete the logon authentication process. This refers to a native-mode domain. Mixed-mode domains do not require a global catalog query for logon.

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/projplan/adarch.mspx
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/default.mspx
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/w2kdomar.mspx

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/projplan/adarch.mspx

Windows 2000 Domain Architecture: Design Alternatives

2004-10-24T22:15:00.000-07:00

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/w2kdomar.mspx

Integrate UNIX and Windows 2000 using Windows Services for UNIX 3.0

2004-10-22T21:52:00.000-07:00

In our interconnected world, it’s often necessary to integrate different types of systems. Connecting systems that are completely foreign to each other can be challenging—for example, Windows 2000 and UNIX don’t always play nice. Let’s look at how to use Microsoft’s Windows Services for UNIX 3.0 to integrate Windows 2000 and UNIX in a way that makes them work well together.Windows Services for UNIX 3.0Windows Services for UNIX is a suite of server applications all bundled into a single package. All the applications and components included in the package are designed to help you to integrate Windows into your existing UNIX environment, or UNIX into your Windows 2000 system.Windows Services for UNIX has been around for a while, and Microsoft has recently released version 3.0. The biggest difference between 3.0 and the previous version is that Microsoft Interix subsystem, which allows you to run both Windows and UNIX applications on a single machine, has been fully integrated.Basically, Interix provides a true UNIX environment that runs on top of a Windows kernel. This means that UNIX applications and scripts can run alongside Windows applications and scripts. The great thing about this is that if your company previously used UNIX and is migrating to Windows, your existing applications can run on the new Windows servers without being recoded from scratch.In addition to the Interix environment, Windows Services for UNIX also includes a software development kit (SDK) that supports some 1,900 common UNIX migration tools and APIs. To top things off, Windows Services for UNIX also includes 300 UNIX tools designed to function exactly as they would on a true UNIX machine. Some of these tools are the GCC, G++, and G77 compilers, as well as RCS, MAKE, YACC, LEX, C89, CC, NM, GDB, and STRIP. Some other tools included are AWK, GREP, SED, TR, CUT, TAR, and CPIO.In addition to Interix, the SDK, and all the UNIX tools, Windows Services for UNIX also includes many other major components, which we’ll discuss in the following sections.

NFS
NFS is the UNIX file system, which Windows doesn’t natively support. This means that if a Windows client wants to access files and other resources from a UNIX server, the Windows machine will need to be made NFS-aware. Windows Services for UNIX provides three different components for accomplishing this task:

Client for NFS: The first of the NFS components is the Client for NFS. The NFS client allows Windows 95, 98, Me, NT, 2000, and XP workstations (or servers) to access an NFS share point. There really isn’t a whole lot to the NFS client. It’s similar to the client for NetWare Networks in that it allows a client to authenticate into, and access files from, a foreign file system.

Server for NFS: The Server for NFS works in the opposite direction as the Client for NFS; it allows a Windows NT 4.0 or a Windows 2000 Server to emulate a UNIX Server. UNIX workstations are able to attach to the Windows server in a way that makes the Windows server appear to be a UNIX server. This means that both Windows and UNIX clients can access a share point on a Windows server simultaneously.

Gateway for NFS: The Gateway for NFS option is a great way to make UNIX resources available to Windows users who are unfamiliar with UNIX. It lets a Windows NT or 2000 server act as a UNIX client that is capable of accessing a predetermined set of resources. The Windows server then reshares those resources with the Windows clients.

When you create a share point with Gateway for NFS, Windows users access the share point on the Windows server in the usual manner (using the SMB protocol). Although the files that the Windows workstations access appear to be on the Windows server, they are actually on a UNIX machine. If a Windows workstation requests a file, the Windows server retrieves the file from the UNIX machine and passes it to the Windows workstation.Although Gateway for NFS is a new feature, it’s very reminiscent of Gateway Services for NetWare (GSNW). What’s nice about this gateway is that it seems Microsoft has learned from its experience in GSNW and has really beefed up security.If you’ve ever used GSNW, you know that its biggest weakness is its total reliance on share-level security. If two shares happen to overlap and a user has different permissions on the two shares, the user could pass through the less restrictive share to gain an unauthorized level of access to the more restrictive share.Microsoft addressed this problem in the Gateway for NFS component with the creation of client groups. You can create groups similar to Windows 2000 security groups and assign them to UNIX share points. While the entire operation still relies on share-level security, there’s a handy check box you can use to block access to the share’s root level, thus preventing the security problems associated with GSNW.

NIS Server
Another major component of Windows Services for UNIX is the NIS Server. The NIS Server allows a Windows 2000 domain controller to administer a UNIX network. The Windows domain controller uses Active Directory, while the UNIX network uses the Network Information Service (NIS). The NIS Server component provides the translation between these two environments.If you’ve used NIS in previous versions of the Windows Services for UNIX, then you’ll be happy to know that Microsoft has made a few enhancements to the NIS Server in version 3.0. The NIS services now support MD5 encryption. Microsoft also has made scalability and performance improvements and enhanced the logging functionality. In fact, NIS now supports 64,000 users.The NIS services have also been integrated with another component, the pluggable authentication module, that’s new to Windows Services for UNIX 3.0. The pluggable authentication module allows users to maintain a single user name and password across the two operating systems. The module then synchronizes the password, thus ensuring that your corporate password policy is maintained across both operating systems. The best part of the pluggable authentication module is that you can change passwords in Windows or UNIX, and those changes automatically replicate to the other operating system.

Telnet server and Telnet client application
No UNIX interface would be complete without Telnet support. Windows Services for UNIX includes both a Telnet server and a Telnet client. The server-side component allows Windows 2000 servers to host Telnet sessions, while the client-side component allows Windows users to access UNIX servers via a Telnet session.Microsoft has also improved the scalability of the server-side Telnet component and has added IPv6 support. Another change in the Telnet component involves the way that zone checking is accomplished. Now zone checking occurs prior to the issuing of NTLM credentials so that users can’t use the NTLM credentials outside of the authorized zone.User

Name Mapping Server
Another feature that’s new to version 3.0 is the User Name Mapping Server. The User Name Mapping Server supports pooling of redundant name mapping servers. This brings increased performance, scalability, and fault tolerance.Microsoft has made some other functional modifications to the User Name Mapping Server as well. In previous versions, the maximum number of groups a user could belong to was hard-coded to match the maximum number of groups supported by the system. The number of groups that a user can belong to is now dynamic. Another improvement is that user names are now truly UNIX compliant in that they can contain non-ASCII characters.

Administrative GUI and command line toolset
Windows Services for UNIX allows administration via the command line or through a GUI interface. If you prefer to take the command prompt approach, you’ll be happy to know that, although the UNIX shell is designed primarily to use UNIX commands, you can actually run Windows applications from the UNIX shell on Windows machines. This works because the UNIX shell is built on top of the WIN32 subsystem.The GUI management interface is based on the Microsoft Management Console (MMC). The Windows Services for UNIX Administration tool, shown in Figure A, allows administrators to manage all of the major components through a single tool.

Performance enhancements
One of the problems with previous versions of Windows Services for UNIX is that many performance adjustments required a system reboot. Microsoft has finally realized that this just isn’t acceptable in a performance environment and has made the performance settings more dynamic. For example, when you modify a performance-related registry key in the latest version of Windows Services for UNIX, the program instantly recognizes and applies the change.The NFS service has also been rewritten for greater performance. Perhaps the most notable difference is that NFS now supports directory caching. So when clients need to browse the directory, they can read the directory contents from the server’s memory rather than from the hard disk. You can even use the Windows Services for UNIX Administration tool to specify how much memory you want to reserve for directory caching. The default setting is 128 KB.Still another enhancement is the way that Windows Services for UNIX handles case sensitivity. By default, Windows Services for UNIX is configured to preserve case sensitivity. This boosts file performance considerably, since no case translation is needed. However, you have the option to translate filenames into upper or lower case, should you wish to. Furthermore, case translation is set individually for the NTFS, FAT, and CDFS file systems. You can see the screen that controls many of the NFS performance enhancements in

System requirements
Windows Services for UNIX is designed to operate on Windows NT (Service Pack 6a), Windows 2000 (Service Pack 2 or later), and Windows XP. Windows Services for UNIX runs on both the server and workstation versions of Windows NT and Windows 2000. It’s designed to be compatible with all major versions of UNIX. However, Microsoft officially supports only Solaris 2.7, HP-UX 11, AIX 4.3.3, and Red Hat Linux 7.0. Windows NT Server 4.0 Terminal Server Edition isn’t supported, and neither are Windows 9x, Windows Me, or Windows XP Home Edition.The Windows machine that Windows Services for UNIX runs on requires 184 MB of free hard disk space, and, according to the Microsoft Web site, 1 MB of RAM, although 16 MB of RAM isn’t even enough to run Windows in most situations. A more realistic recommendation is 256 MB of RAM. I also recommend that your server have at least a 600 MHz processor and at least one NIC that’s configured to use TCP/IP.

Licensing and availability
The full Windows Services for UNIX package is available from any Microsoft distribution channel for about $99. Microsoft also offers the software on a try-before-you-buy basis. You can download a 120-day evaluation edition as well. The download file is a hefty 140 MB, so if you don’t have a broadband connection, you might be better off ordering the trial version on a CD. Microsoft supplies trial software CDs for free, although a nominal shipping charge usually applies.Depending on your individual installation, the software may also require client access licenses. If you install Windows Services for UNIX onto a Windows 2000 or Windows NT Server product, the server will be running in either Per Seat or Per Server licensing mode. If the server is running in Per Seat mode, each device that accesses the server must have a valid client access license. Likewise, if the server is running in Per Server mode, then the maximum number of devices that may access or otherwise use the server is equal to the number of client access licenses you have.The good news is that a standard client access license for Windows NT Server 4.0 or for Windows 2000 Server allows the client to also use Windows Services for UNIX. Therefore, as long as a client already has a client access license for the server, an additional license isn’t required.Windows Services for UNIX also runs on Windows NT Workstation 4.0, Windows 2000 Professional, and Windows XP Professional. These operating systems simultaneously access up to 10 devices. No special licenses are required when running Windows Services for UNIX on a workstation.The best of both worldsWindows Services for UNIX provides a great way to simplify the process of integrating Windows and UNIX environments. When you deploy Windows Services for UNIX, your network can benefit from the strengths of both Windows and UNIX, and you can better integrate your legacy systems into your current network.

http://techrepublic.com.com/5102-6268-5031918.html

Integrate Windows and UNIX systems with NFS - providing access to NFS shares on a UNIX server

2004-10-22T21:48:00.000-07:00

Windows Services for UNIX (SFU) is an add-on for Windows 2000 Server that provides several components to enable integration between Windows systems and UNIX/Linux systems. One SFU component is the Network File System (NFS), which provides the Client, Server, and Gateway components that support file sharing between Windows and UNIX-based systems.
The Client component enables Windows clients to access files shared on UNIX-based NFS servers. The Server component displays Windows-hosted shares as NFS file systems, making them available to NFS clients in both UNIX and Windows environments.
Installing and managing an NFS client on Windows workstations is one solution to providing access to NFS shares on a UNIX server, but a better option is to use the Gateway component of NFS for Windows 2000. The Gateway component enables a Windows 2000 server to act as a gateway for NFS shares on UNIX hosts.

To the client, it appears that the Windows server is hosting these shares. Because the Windows clients can access the Windows server without any additional client software, these clients don't require NFS client software to access NFS shares on remote UNIX hosts. Eliminating the need for NFS client software simplifies network and client management.

http://techrepublic.com.com/5102-6268-5031918.html

L2, L3 and L4 switching

2004-09-24T18:29:00.000-07:00

With the rapid development of computer networks over the last decade, high-end switching has become one of the most important functions on a network for moving data efficiently and quickly from one place to another.
Here’s how a switch works: As data passes through the switch, it examines addressing information attached to each data packet. From this information, the switch determines the packet’s destination on the network. It then creates a virtual link to the destination and sends the packet there.
The efficiency and speed of a switch depends on its algorithms, its switching fabric, and its processor. Its complexity is determined by the layer at which the switch operates in the OSI (Open Systems Interconnection) Reference Model (see above).
OSI is a layered network design framework that establishes a standard so that devices from different vendors work together. Network addresses are based on this OSI Model and are hierarchical. The more details that are included, the more specific the address becomes and the easier it is to find.
The Layer at which the switch operates is determined by how much addressing detail the switch reads as data passes through.
Switches can also be considered low end or high end. A low-end switch operates in Layer 2 of the OSI Model and can also operate in a combination of Layers 2 and 3. High-end switches operate in Layer 3, Layer 4, or a combination of the two.
Layer 2 Switches (The Data-Link Layer)Layer 2 switches operate using physical network addresses. Physical addresses, also known as link-layer, hardware, or MAC-layer addresses, identify individual devices. Most hardware devices are permanently assigned this number during the manufacturing process.
Switches operating at Layer 2 are very fast because they’re just sorting physical addresses, but they usually aren’t very smart—that is, they don’t look at the data packet very closely to learn anything more about where it’s headed.
Layer 3 Switches (The Network Layer) Layer 3 switches use network or IP addresses that identify locations on the network. They read network addresses more closely than Layer 2 switches—they identify network locations as well as the physical device. A location can be a LAN workstation, a location in a computer’s memory, or even a different packet of data traveling through a network.
Switches operating at Layer 3 are smarter than Layer 2 devices and incorporate routing functions to actively calculate the best way to send a packet to its destination. But although they’re smarter, they may not be as fast if their algorithms, fabric, and processor don’t support high speeds.
Layer 4 Switches (The Transport Layer)Layer 4 of the OSI Model coordinates communications between systems. Layer 4 switches are capable of identifying which application protocols (HTTP, SNTP, FTP, and so forth) are included with each packet, and they use this information to hand off the packet to the appropriate higher-layer software. Layer 4 switches make packet-forwarding decisions based not only on the MAC address and IP address, but also on the application to which a packet belongs.
Because Layer 4 devices enable you to establish priorities for network traffic based on application, you can assign a high priority to packets belonging to vital in-house applications such as Peoplesoft, with different forwarding rules for low-priority packets such as generic HTTP-based Internet traffic.
Layer 4 switches also provide an effective wire-speed security shield for your network because any company- or industry-specific protocols can be confined to only authorized switched ports or users. This security feature is often reinforced with traffic filtering and forwarding features.

rss

2004-09-17T20:31:00.000-07:00

http://rss.windowsecurity.com/allnews.xml

Implementing and Troubleshooting Account Lockout

2004-09-17T20:12:00.000-07:00

http://www.WindowSecurity.com/articles/Implementing-Troubleshooting-Account-Lockout.html

Keep your activation status intact when reinstalling XP

2004-09-17T18:23:00.000-07:00

Have you ever wanted to reformat the hard disk and reinstall Windows XP on a system but you didn't want to mess around with Microsoft's Product Activation after the reinstall? Fortunately, you don't have to.
As long as you aren't making any hardware alterations, you can back up the activation status files before you reformat the hard drive and then restore them after you reinstall the operating system.
To perform the backup, follow these steps:
Use Windows Explorer to open the C:\Windows\System32 folder.
Copy the Wpa.dbl and Wpa.bak files to a floppy disk or CD.

To perform the restore, follow these steps:
Decline the activation request at the end of the installation procedure, and restart Windows XP.
During bootup, press [F8] to access the Windows Advanced Options menu.
Choose the Safe Mode (SAFEBOOT_OPTION=Minimal) option.
Use Windows Explorer to open the C:\Windows\System32 folder.
If they exist, rename the new Wpa.dbl and Wpa.bak files to Wpadbl.new and Wpabak.new.
Copy the original Wpa.dbl and Wpa.bak files from the floppy disk or CD to the C:\Windows\System32 folder.
Restart the system.

Windows routing tables

2004-09-15T22:32:00.000-07:00

Below is the syntax to add a new route:
ROUTE ADD MASK METRIC IF
Here's an example:
ROUTE ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
In this example, 192.168.0.9 is the gateway for all traffic to the destination 192.168.1.0/24. The metric is 2, and the interface number is 2.
When you add a route using this syntax, the route doesn't persist across restarts of the computer. To make a route persist, add the -p switch to the command, as shown below:
ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.9 METRIC 2 IF 2
To delete a route, use the DELETE keyword and the destination address. Here's an example:
ROUTE DELETE 192.168.1.0

Handle basic password management on your Cisco router

2004-09-12T22:14:00.000-07:00

http://techrepublic.com.com/5100-6265_11-5034567.html?tag=e036

Deciphering Authentication Events on Your Domain Controllers

2004-09-07T21:45:00.000-07:00

Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. This article will explain how to decipher authentication event on your domain controllers.

Beginning with Windows 2000, Microsoft introduced a new audit policy called “Audit account logon events” which solved one of the biggest shortcomings with the Windows security log. Until this new category it was impossible to track logon activity for domain accounts using your domain controllers’ security logs. (You can view and configure your domain controllers’ audit policy from the Default Domain Controllers Security Policy shortcut in Administrative Tools. Use Event Viewer to view your security log.) Prior to Windows 2000 all you had was the “Audit logon events” category which didn’t work the way most people expected. When you enable “audit logon events” on NT and later domain controllers, the only logon events you’ll see in the domain controllers’ security logs are users and computers logging on to the domain controller itself. With “audit logon events” enabled, domain controllers do not record any activity related to domain users logging on at their workstations or other servers. The reason is that the concept of a logon is different than authentication. When you logon at your workstation with a domain account – you are logging into the workstation – not the domain controller. The domain controller is simply performing the authentication check. Therefore the old “audit logon events” audit policy doesn’t do you much good for tracking domain user logon activity or failed logon attempts. You’d have to enable “audit logon events” on each workstation and server on your network and then monitor those logs and you still wouldn’t see failed logon attempts by attackers using their own workstation. Thus, the need for the new audit policy introduced with Windows 2000 – “audit account logon events”. When you enable this policy on Windows 2000 or 2003 domain controller this policy records all domain account authentication that occurs on that domain controller in that domain controller’s security log. This activity is categorized as “Account Logon” in the security log as opposed to “Logon/Logoff” for the “audit logon events” policy. When you analyze the combined “Account Logon” activity of all your domain controllers you now how a complete picture of the logon activity of all domain accounts in your domain regardless of where the logon attempts are initiated from – computers of the local or trusted domain or even unknown computers completely outside your AD forest and external trusted domains.

Windows 2000 and 2003 domain controllers support Kerberos and NTLM authentication protocols. When a Windows 2000 or later computer needs to find out if a domain account is authentic the computer first tries to contact the DC via Kerberos. If it doesn’t receive a reply it falls back to NTLM. In an AD forest comprising computers running Windows 2000 and later all authentication between workstations and servers should be Kerberos. Windows 2000 and later domain controllers log different event IDs for Kerberos and NTLM authentication activity so it’s easy to distinguish them. In an AD forest of Windows 2000 or later computers, any NTLM authentication events you see on domain controllers can only have a few explanations. First, Windows will fall back to NTLM if routers for some reason block Kerberos traffic (UDP port 88). Second, if your domain trusts another domain outside your forest (defined in Active Directory Domains and Trusts) you’ll see NTLM events on you domain controllers since Kerberos doesn’t work for external trust relationships. (Note: Windows Server 2003 supports a new type of trust call cross forest trusts. A cross forest trust is a transitive, 2-way trust between 2 Windows Server 2003 domains. Cross forest trusts use Kerberos – not NTLM.) The third explanation for NTLM events on your domain controller’s security log are rogue computers.

Contrary to popular misconception, Windows does not prevent a user at a computer from an un-trusted domain or stand-alone computer (Windows computer that doesn’t belong to any domain) from connecting to a server in your domain using a domain account. To prove this just map a drive to a computer in an untrusting domain using the “net use” command. For instance in the below example I connect to a file server called NYC-FS-1 in the NYC domain using the domain Administrator account and a password of #dk32HE4.
net use \\nyc-fs-1.nyc.acme.local\c$ #dk32HE4 /user:nyc\administrator

If you have an application such as an IIS web application that uses NTLM authentication you will see NTKM also. About the only other explanation for NTLM events on your domain controller security logs is more mundane - you just have some pre Win2k computers somewhere in your local domain or in the overall forest.

The bottom line is that if an outsider is attacking accounts in your domain you will most likely see them as NTLM authentication errors – not Kerberos. Windows 2000 logs just 2 event IDs for all types of NTLM authentication activity – 680 and 681. A successful NTLM authentication yields an event ID 680 and a failure produces event ID 681. Both events list the user name that failed authentication as well as the name of the computer from when the authentication attempt originated (usually the user’s workstation). To determine why the authentication failed you need to look at the error code in event ID 681’s description.

See figure 1 for a listing of NTLM error codes. NTLM yields an authentication event whenever a user logs on to a computer interactively or over the network. For instance, imagine a user logs on to his NT workstation with a domain account and then uses a share folder on server A and server B. On whichever domain controller(s) that handles those authentication requests you’ll see a total of 3 event ID 680s – one for the interactive workstation logon and 2 for the network logon at server A and server B.

Things are a little different on Windows Server 2003 however. Annoyingly, in Windows Server 2003 Microsoft eliminated event ID 681 and instead uses event ID 681 for both successful and failed NTLM authentication attempts. So on Windows Server 2003 don’t look for event ID 681 and be sure to take into account the success/failure status of occurrences of event ID 680.
So turn on auditing for “audit account logon events” on your domain controllers and keep an eye out for event IDs 680 and 681 – they might reveal some computers that have missed being upgraded or worse an attack from an outsider. If you have multiple domain controllers and servers it helps to have a tool like this site’s sponsor – GFI’s LANGuard SELM – that can merge all that activity into one database and provide centralized alerts and reporting.

While tracking NTLM authentication is important, don’t forget about Kerberos authentication which will likely be the bulk of authentication activity in your domain controller security logs. We’ll look at Kerberos security events in my next article.
Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, is the creator and exclusive instructor for the 5 day Ultimate Windows Security seminar at ultimatewindowssecurity.com.

http://www.windowsecurity.com/articles/Deciphering-Authentication-Events-Domain-Controllers.html

How can I gain access to a Windows 2000/XP/NT computer if I forgot the administrator's password? How can I reset the administrator's password if I for

2004-08-30T19:12:00.000-07:00

http://www.petri.co.il/forgot_administrator_password.htm

http://home.eunet.no/~pnordahl/ntpasswd/

How can I gain access to a Windows 2000/XP/NT computer if I forgot the administrator's password? How can I reset the administrator's password if I forgot it?
Featured Product:
Windows XP/2000/NT Key - Easy to use utility to reset Windows 2003/XP/2K/NT local and domain controller administrator passwords. Download FREE version now!
Ok, so you say you forgot your Windows administrator's password, huh? Oh well, it doesn't really matter if you did or you just say you did. The fact is that you need to gain access to a computer and you cannot "remember" the administrator's password.
How can you get out of this situation without formatting and re-installing the operating system?
Well, you can always try to remember the login password, or if that doesn't work (you wouldn't be sitting here reading my crap if you did remember, would you?) you can restore a backed up System State (in W2K DC) or a ERD (in NT 4.0) in which you do remember the password. The problem with doing so is that you'll probably lose all of the recently add users and groups, and all the changed passwords for all of your users since the last backup was made.
Note: If you are looking for password cracking tools that can be used for miscellaneous objectives such as password-protected PDF documents, zipped archives, Office documents, BIOS protection and so on then this pages is NOT for you. See some links at the bottom of this page for hints on where to find such tools, but I can tell you right away that Google might be a better choice for you.
Free Tools
Free Windows password-cracking tools are usually Linux boot disks that have NT file system drivers and software that will read the registry and rewrite the password hashes for any account including the Administrators. This process requires physical access to the console and an available floppy drive but it works like a charm! I've done it myself several times with no glitch or problem whatsoever.
Beware!!! Resetting a user's or administrator's password on some systems (like Windows XP) might cause data loss, especially EFS-encrypted files and saved passwords from within Internet Explorer. To protect yourself against EFS-encrypted files loss you should always export your Private and Public key, along with the keys for the Recovery Agent user. Please read more about EFS on my What's EFS? page.
Here are 4 of these free tools:
Petter Nordahl-Hagen's Offline NT Password & Registry Editor
Openwall's John the Ripper
EBCD – Emergency Boot CD
Austrumi
If you happen to know about other free tools please let me know .
For Domain Admin password resetting procedures please see the Related Articles section at the bottom of this page.
Offline NT Password & Registry Editor (v040818)
Petter Nordahl-Hagen has written a Windows NT/2000/XP offline password editor:
http://home.eunet.no/~pnordahl/ntpasswd
This is a utility to (re)set the password of any user that has a valid (local) account on your NT system, by modifying the encrypted password in the registry's SAM file.
You do not need to know the old password to set a new one.
It works offline, that is, you have to shutdown your computer and boot off a floppy disk or CD. The boot-disk includes stuff to access NTFS partitions and scripts to glue the whole thing together.
Works with syskey (no need to turn it off, but you can if you have lost the key)
Will detect and offer to unlock locked or disabled out user accounts!
Caution: If used on users that have EFS encrypted files, and the system is XP or later service packs on W2K, all encrypted files for that user will be UNREADABLE! and cannot be recovered unless you remember the old password again!
Download links:
bd040818.zip (~1.1MB) - Bootdisk image, date 040818
cd040818.zip (~1MB) - SCSI-drivers (040818) (only use newest drivers with newest bootdisk, this one works with bd040818)
sc040818.zip (~2MB) - Bootable CD image with same version and drivers as floppies above.
To write these images to a floppy disk you'll need Raw Write, Win Image or any other writing software you want.
Support and Problems? Don't call me! Talk to the creator of this great tool. He also has a good FAQ set up covering most of the day-to-day questions. Read it right HERE
Author claims that this tool was successfully tested on NT 3.51, NT 4, Windows 2000 (except datacenter), Windows XP (all versions) and Window Server 2003. Notice that it is NOT compatible with Active Directory.
Need to change Windows NT/2000 Domain Admin password? This tool, however useful, will only reset the local administrator's password (e.g. the one found in the local computer's SAM). To reset a password of a domain administrator (or any other user for that matter) you must perform the routine that is described in the following page: Forgot the Administrator's Password? - Reset Domain Admin Password in Windows 2000 AD.
Note: This trick will probably not work under Windows Server 2003 due to service account security changes. To work around these limitations please read the Forgot the Administrator's Password? - Reset Domain Admin Password in Windows Server 2003 AD page.
John the Ripper (v1.6)
John the Ripper is a fast password cracker, currently available for many flavors of Unix (11 are officially supported, not counting different architectures), DOS, Win32, BeOS, and OpenVMS. Its primary purpose is to detect weak Unix passwords. Besides several crypt(3) password hash types most commonly found on various Unix flavors, supported out of the box are Kerberos AFS and Windows NT/2000/XP LM hashes, plus several more with contributed patches.
Read more at http://www.openwall.com/john/
Download links:
John the Ripper 1.6 (768kb)
EBCD – Emergency Boot CD (v0.60)
EBCD is a bootable CD, intended for system recovery in the case of software or hardware faults. It is able to create backup copies of normally working system and restore system to saved state. It contains the best system software ever created, properly compiled and configured for the maximum efficient use.
EBCD will be very useful when you need to:
Copy/move files (with long names, not necessary in CP437 encoding) from/to the disk but OS which can handle them (windows, Linux...) cannot boot. In particular, you may create a backup copy of normally installed and configured Windows and later restore Windows from such backup copy. So, in the case of fault OS itself and all software and its settings can be restored in 5-10 minutes.
Perform emergency boot of Windows NT / 2000 / XP. When the loader of this OS on the hard disk is damaged or misconfigured, you are able to load OS using another, standalone loader from this CD.
Recover master boot record of HDD. This allows to boot OS after incorrect uninstallation of custom loader (LILO, for example), which made all OS on your PC not bootable.
Delete, move, copy to file (image) and re-create partition from file. Image transfer over network is also supported: so you may configure one PC and then make contents of hard disks of other PCs same as contents of the hard disk of the first one.
Change password of any user, including administrator of Windows NT/2000/XP OS. You do not need to know the old password.
Recover deleted file, even file re-deleted from Windows Recycle Bin, and, in contrast, wipe single file or a whole disk so that it will be impossible to recover it in any way.
Recover data from accidentally formatted disk. Sometimes it helps to recover data from the disk, damaged by a virus.
Recover data from a floppy disk, which is not readable by OS. Format 3.5" disk for 1.7 Mb size.
Also the disk includes full set of external DOS commands, console versions of the most popular archivers/compressors.
Moreover, emergency boot CD includes minimal Linux distribution (Rescue Linux distribution) which may be very useful to a professional user.
Read more at http://ebcd.pcministry.com/
Download links:
EBCD Pro distribution (18mb)
More download links: HERE, HERE, HERE and HERE. One of them has got to work, and if not, please send me a note.
Austrumi (v0.84)
Reader Cory Zerwas pointed out this tool. I haven't tested it myself, but from what I read about it it seems to do the job.
Austrumi is a Linux bootable ISO image for recovering NT passwords and other cool tools and methods, sized for Business Card size CD media (50Mb). It allows you to change any password, including that of the Administrator, on a partition occupied by Windows NT, Windows 2000 or Windows XP. Simply boot the CD and when you get to the initial boot prompt, type:
boot: nt_pass
This will launch a console utility that will detect Windows partitions on the hard disk and provide you with a menu to modify any user or Administrator passwords on the Windows system. It will even give access to the Windows registry for recovery purposes. Quite a handy utility to keep in your wallet (AUSTRUMI is small enough to fit on a business card-size CD) if you are unfortunate enough to having to deal with Windows machines in your line of work.
Read more at http://sourceforge.net/projects/austrumi
Download links:
Austrumi v0.84 (ISO file, 52mb)
Commercial Tools
Here are some of the commercial tools that will help you get out of the mess you're in. Make note that theses tools are not listed in any particular order:
Lostpassword.com
O&O BlueCon XXL
Administrator's Pak, NTFSDOS, ERD Commander 2003
LC5 - The Password Auditing and Recovery Application
NTAccess 1.4
These tools cost money. Sometimes more than you think.
Other commercial password recovery tools (not administrator or OS related):
http://www.elcomsoft.com/prs.html
See this page that has links to lots and lots of password cracking tools (for Office, PDF, ZIP etc.):
http://www.openwall.com/PR
Note: I'd like to put together all the info you have about these issues. If you have any tips, recommended links or any ideas about how to figure out a lost password - please e-mail me and I'll get back to you .
Related articles
You may find these related articles of interest to you:
Change Recovery Console Password
Change User Password from a Remote Computer
Change User Password from the Command Prompt
Forgot the Administrator's Password? - Alternate Logon Trick
Forgot the Administrator's Password? - Reset Domain Admin Password in Windows 2000 AD
Forgot the Administrator's Password? - Reset Domain Admin Password in Windows Server 2003 AD
What's the Password Reset Disk in Windows XP?
Links
Changing the Administrator password if you have forgotten it (Windows NT 4.0 only)
Lost your Administrator password and need the ultimate hack? (Windows NT 4.0 only)
Recover Lost Windows NT Administrator Password
Password Recovery Resources

XP bugs

2004-08-25T07:21:00.000-07:00

Probably biggest gotcha! is that Windows XP Pro and Windows XP Home are very different products. Lots is missing in XP Home and it is much less stable than XP Pro.
Acdsee May Cause an Error Message
ACPI Troubleshooting
Admin file ownership in XP Inconsistent
Admin pw : Cannot Change the Password for the Administrator Account in User Accounts in Control Panel
Admin can't install updates? Only happens if your workstation is part of domain it has either reg key HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoWindowsUpdate set and/or has changed full control permission from admin on HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate.
Audit accounts: if you have auditing enabled, users may be prompted for a password even if no password is required. If this happens there is nothing you can do except assign passwords. You could try the current SP to see if it resolves the bug. Its actually an odd situation. What environment would had auditing enable and allow auto logon?
audio or video files don't play - GSpot Codec Information Appliance will tell you what codec are required
Backup utility for XP Home - where is it? On the install CD in \VALUEADD\MSFT\NTBACKUP. Double-click the Ntbackup.msi to start the wizard that installs the Backup utility.
Bandwidth : XP needlessly consumes 20% of available bandwidth. The QoS packet scheduler dialogue box in XP Pro has a default bandwidth limit of 20%. Some interpreted this setting to mean that XP will hold back 20% of your bandwidth even if its packet scheduler was turned off. Not true.
Blank activate Windows page in the Windows Product Activation Wizard
Booting
BootVis.exe Tool
How to Disable a Service or Device that Prevents Windows from Booting
"System Has Recovered from a Serious Error" message every reboot (Q317277)
CD - when you copy files from a CD to your HD, XP copies them read-only. Need to update them? Remove the read only attrib : attrib -r * /s
CD-R Drive or CD-RW Drive Is Not Recognized As a Recordable Device
CD-ROM Drive or DVD-ROM Drive Missing After You Install Windows XP
"Incorrect Function" Error Message When You Access the CD-ROM Drive, DVD-ROM Drive, or CD-RW Drive
"CD Recording Software Will Cause Windows to Become Unstable" Error Message When You Start Windows
CD-ROM Access Is Missing and Messages Cite Error Code 31, Code 32, Code 19, or Code 39 After You Remove Easy CD Creator in Windows XP
CDRom : Limited users can not burn CDs in Windows XP Home if you have setup limited users and want them to be able to burn CDs, set value HLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\AllocateDASD = 2.
C-Media Cmaudio.ax Driver : Problems When You Are Using an Out-of-Date Version
Compiling programs take 30-40% longer on XP rather than NT. Solution: Compile on a Windows XP-Based Computer Takes Longer to Complete Than on a Windows NT-based Computer
Compressed files : XP search treats zips as directories and searches through them. If you have lots of compressed files, this can extend XP search time to hours. Solution: Disable Windows XP's builtin zip support
Computer Does Not Start After You Change the Active Partition by Using the Disk Management Tool
Control Panel icons missing after upgrading to XP delete the HKEY_CURRENT_USER\Control Panel\Don't load key.
Copying from XP to Windows 2000 SLOWWWWWWWWWW Q321169: Slow SMB Performance When You Copy Files from Windows XP to a Windows 2000 Domain Controller
Crashes :
XP setting crashes dorm networks Bill Brawley, director of user communications at Computing Services, said that the problem begins when a laptop with Windows XP switches between the wireless Internet card and an Ethernet cable connection. "There are two sort of network interfaces then," Brawley said. "The bridge feature is handy on a home network, but on our network it bridges those two devices and sets up a loop in which packets travel between the networks, sort of a feedback loop. This messes up both networks for the whole building." For background on bridging issues:
XP Bridging and Media Support for Home Networking
CreativeLabs :
Audigy registration program causes error message : InetReg.exe has encountered a problem and needs to close. We are sorry for the inconvenience
Error Message When You Shut Down Computer: DEVLDR Not Responding
Ctplay2.exe has encountered a problem and needs to close. Creative SoundBlaster Audigy Audio May Cause an Error
CPU : Explorer.exe Process Uses Many CPU Cycles When Windows Is Idle
Desktop Icons gone !!! This is a setting available in XP. Maybe your buddy is screwing with you. In any case:
Right-click desktop
Select Arrange Icons by
Check/uncheck Show Desktop Icons
Device conflicts: Troubleshooting Device Conflicts with Device Manager
Disk Cleanup : Stops Responding when searching for compressed files Q812930 : caused by incorrect entry in the registry This can also be caused by a corrupt temporary file. Clear the files from the Temp folder:
Close all applications
Start, click Run and type %temp% which opens the Temp folder
Type Ctrl+A to select all files
Press Delete
Close Windows Explorer
Open the Control Panel Internet Options applet
Select the General tab, then click Delete Files
Select the Delete all offline content check box
Click OK
DSL : XP kills Verizon DSL
DVD : Windows 2000 DVD-ROM Drive Cannot Read Windows XP-Formatted DVD Q304841 Although Win98 can read the XP formatted DVD!
XP often will not read or write to a floppy formatted by an earlier version of Windows Keep it in mind. No prob if formatted by XP.
Hard Disk Performance Is Slower Than You Expect in XP
IE issues - probably not unique to any particular OS
IE only saves graphics as BMPs
Internet Connection Sharing in Windows XP Troubleshooting
Dial-Up Connection in ICS Does Not Prompt to Disconnect when you quit Microsoft Internet Explorer on an Internet Connection Sharing (ICS) client computer,
Infrared Data Transfer Slower in Windows XP Than in Windows 2000workaround
information about the hardware installed on his computer hangs with message: 'all.part2' is null, or it is not an object
IIS : can't install IIS web server under XP Home - have to upgrade to XP Pro or use Apache instead
Language gotcha! : Cannot Upgrade or Install a Different Language Version of Windows XP
Mail Folders, Address Book, and E-mail Messages Are Missing After You Upgrade to Microsoft Windows XP
Media Player Info Exposure XP Windows When you play media files, Media Player collects titles, artiles and album art from the Internet. It also leaves behind info about you and your computer. To block Windows Media Player from providing your info: click Tools > Options and go to the Player tab and disable option Allow Internet sites to uniquely identify your player?
Modem Does Not Work After You Upgrade a Hewlett Packard Pavilion Computer to Windows XP this occurs when you upgrade certain models of the HP Pavilion computer that are equipped with a modem based on the Rockwell chip set.
Modem, external serial modem can't be installed because XP does not recognize any COM ports except for the LPT port for the printer. Enable com port in BIOS and reboot. Now XP will have serial port available.
Mouse Pointer Moves Erratically or Does Not Respond with Windows XP
Netware : Poor Performance with File and Print Services for NetWare
My Network Places vulnerability
Outlook Express : can't make it default mail client you try to set Outlook Express in XP as your default mail client. It resets saying "this is not the default mail client" every time you go into the options menu. Solution: Click Start, Run and enter MSIMN.EXE /REG Then if needed, go to Control Panel, Internet Options, Programs and click the Reset Web Settings Button.
passwords:
Admin resets user's password and user loses access to EFS-encrypted files, email and various credentials No problem if PC is a member of a domain but a real problem for non-domain PCs.
Admin pw : Cannot Change the Password for the Administrator Account in User Accounts in Control Panel
No Password Expiration Notice Is Presented During the Logon Process
Q811493 - Windows XP Security : after applying it, XP systems are SLOW
Random crashes - causes
USB hub - got one? XP crashing? Worse - using an unpowered hub? Remove it and see if crashes stop. what I see more often is that hub works well before upgrading to XP but not under XP.
memory - my first thought - remove existing memory and replace with known good memory. Sometimes you just need to reseat cards and memory; vibrated ever so slightly loose.
drivers or bios - always check with vendors - particularly sound cards
power supply - not as common with modern boxes but if your PC is older, it may literally be underpowered. upgrade to a 400w.
Recovery Console in Windows XP 'The Password Is Not Valid' Error Message Appears When You Log On to Recovery Console in Windows XP
Remove programs - can't - get Error 1719 occur when you try to add or remove a program that uses the Windows Installer Microsoft Software Installation (MSI) package file (.msi).
Restore Point
Restore Point : Restoration Incomplete occurs when the computer is not shut down properly
When you start the System Restore tool and view the "Select a Restore Point" page, some of your restore points may be missing : Q301224
When you run the System Restore tool on a Windows XP-based computer, the calendar on the left side of the "Choose a Restore Point" window is not displayed : Q313853
"RUNDLL32.EXE - Entry Point Not Found" Error Message When You Start Your Computer Believe it or not, if you get this error, one major cause is older NVIDIA video drivers. Update them.
Scandisk missing ? XP like NT uses chkdsk.exe. Open a cmd prompt and type in chkdsk.exe /? to checkout the available parameters you may use.
Search function in Windows® XP has a known issue of not finding a number of File Types when you do a Search for Files "containing text" or using the "A word or phrase in the file" option. See Using the "A Word or Phrase in the File" Search Criterion May Not Work for Microsoft writeup or Search - Text for an alterative.
XP by default only searches for registered file types. Use a registry hack to make XP Search for All File Types
Security Exposure : XP Windows Universal Plug and Play
Security flaw : IE I can't begin to list the number of security problems found in IE. Use Windows Update often or if you fear it, monitor current security issues and patch when needed. Really Windows Update will save you a world of hassle. I would schedule the updates manually. See Automatic Updates Give XP Users New Headaches.
Security tab missing in XP If your hard drive is formatted NTFS, you can set permissions on files if you right-click file and choose properties. If your XP workstation is standalone or part of a workgroup, the security tab will be hidden. To have it show,
Open Windows Explorer
Choose Folder Options from the Tools menu
On the View tab, scroll to the bottom of the Advanced Settings
Clear the check box next to "Use Simple File Sharing."
Click OK to apply the change
Serious privacy problems in Windows Media Player for Windows XP
Services : disable service with services.msc rather than msconfig msconfig will allow you to disable any service including required services - services.msc will not allow you to do that kind of damage.
Sony MovieShaker : "This Application Cannot Use This File as a Clip" error message appears after an upgrade to Windows XP on a Sony VAIO PCV-R553DS computer that runs Windows 98 Second Edition and has MovieShaker version 1.1 installed. this version of Sony MovieShaker is not compatible with Windows XP
Shutdown : Resources to Help Troubleshoot Shutdown Problems in Windows XP
Startup : Resources for Troubleshooting Startup Problems in Windows XP
STOP errors:
STOP 0x00000073 CONFIG_LIST_FAILED Error Message in Windows XP one of the core Windows system hives (the SAM hive, the SECURITY hive, the SOFTWARE hive, or the DEFAULT hive) cannot be linked in the Windows registry. However, this error does not mean that the hive is damaged or that it was not loaded successfully.
STOP 0x00000074 BAD_SYSTEM_CONFIG_INFO Error Message in Windows XP caused by having one or more RAM sticks that are either damaged or not placed into the computer correctly. turn off the computer and double check the RAM seating. If the memory is seated correctly, it could be that you have a bad DIMM. Try swapping out the DIMMs one at a time.
STOP 0x0000009C MACHINE_CHECK_EXCEPTION Error Message in Windows XP processor detected an unrecoverable hardware error and reported it to Windows XP
"Stop 0x000000A5" Error When You Are Installing Windows XP Windows has detected that the BIOS in the computer is not fully compliant with Advanced Configuration and Power Interface (ACPI).
Stop 0x000000C2 error in Windows XP kernel-mode process or driver incorrectly attempted to perform a memory operation. This error message is typically caused by a faulty device driver or software.
Stop 0x000000D1 Error Message When You Turn Your Computer Off the OHCI endpoint is unable to find the transfer descriptor in the list of USB devices attached
Stop 0xc0000135 Damaged Registry Repair and Recovery in Windows XP Registry damage often occurs when programs with access to the registry do not cleanly remove temporary items that they store in the registry. This problem may also be caused if a program is terminated or experiences a user-mode fault.
System restore points taking up LOTS of space. This can consume several gigs. Solution is to set maximum space allocated to System Restore In the System Restore tab of the system applet in the Control Panel, click on settings and reduce the amount of space allotted to System Restore. This will remove older restore points using space not allocated and it will prevent System Restore from getting too large in the future.
System Restore Tool Displays a Blank Calendar in Windows XP
Taskbar Is Missing When You Logon
Upgrade gotcha!:
"Setupapi.dll File Appears to be Corrupt" Error Message When You Try to Upgrade to Windows XP
Existing Computers Are Not Updated to the DNS-Style Domain Name After You Upgrade the Domain to Active Directory
User Profiles May Not Be Migrated During Windows XP Upgrade
Missing Third-Party Control Panel Icons After Upgrade to Windows XP
Video Drivers : How to Determine Which Video Driver Is Loading in Windows XP
Webfolders : Cannot Add FQDN Web Folders that Require Basic Authentication to "My Network Places"
Windows XP Stops Responding at the Welcome Screen System restart has been paused : computer enters into the Hibernate mode and accesses a corrupted memory snapshot
XP SP1 Problems
SP1 : 100 Percent CPU Usage May Occur Under Some Battery Conditions
SP1 : Network File Errors Occur After You Install Windows XP SP1

Reinstall TCP/IP in XP PRo

2004-08-16T02:59:00.000-07:00

You receive an "An operation was attempted on something that is not a socket" error message when you try to connect to a network

View products that this article applies to.
Important This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS
When you try to connect your computer to a network, you may receive the following error message:
An operation was attempted on something that is not a socket.
This symptom occurs on a computer that obtains an IP address from a Dynamic Host Configuration Protocol (DHCP) server. If you assign a static IP address to your computer, you do not receive this message.

CAUSE
This issue may occur if you have a third-party product installed that uses Windows sockets and also uses the ipconfig, release, and renew commands. The Windows sockets registry subkeys may be corrupted.

RESOLUTION
Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.To resolve this problem, use either of the following methods.

Method 1
We recommend that you use Method 1 if either of the following conditions are true:
You only have one computer.
You do not have access to a computer that is similar to the first computer where you experienced the symptoms that are described in the "Symptoms" section. A computer that is similar to the first computer is another computer that has the same operating system version and a similar hardware configuration.
Use Registry Editor to export and delete the Winsock and Winsock2 registry subkeys, and then remove and reinstall TCP/IP on Microsoft Windows 2000 or Microsoft Windows XP. To do this, follow these steps.
Export and delete the corrupted registry subkeys
1. Insert a floppy disk in the floppy disk drive of the computer whose registry entries you are exporting.
2. Click Start, click Run, type regedit, and then click OK.
3. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Winsock
4. On the File menu, click Export.
5. In the Save in box, click 3½ Floppy (A:), type a name for the file in the File name box, and then click Save.
6. Right-click Winsock, and then click Delete. When you are prompted to confirm the deletion, click Yes.
7. Repeat steps 3 through 6 for the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Winsock2
Note Each .reg file that you save must have a different name.
8. Right-click Winsock2, click Delete, and then click Yes.
9. Quit Registry Editor.

Windows 2000-based computer
Remove TCP/IP on a Windows 2000-based computer
1. Log on to Windows as administrator.
2. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then click Properties.
3. Under This component uses the following items, click Internet Protocol (TCP/IP), and then click Uninstall.
4. Follow the instructions on the screen to remove TCP/IP.
5. Restart your computer, but click No if you are prompted to let Windows enable a protocol.
Install TCP/IP on a Windows 2000-based computer
1. Log on to Windows as administrator.
2. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then click Properties.
3. Click Install.
4. In the Select Network Component Type dialog box, click Protocol, and then click Add.
5. Under Network Protocol, click Internet Protocol (TCP/IP), and then click OK.
6. When the protocol is installed, click Close.
7. Restart your computer.

Windows XP-based computer
Reinstall TCP/IP on a Windows XP-based computer
In Windows XP, the TCP/IP stack is a core component of the operating system. Therefore, you cannot remove TCP/IP in Windows XP.
1. Install TCP/IP on top of itself. To do this, follow these steps:
a. In Control Panel, double-click Network Connections, right-click Local Area Connection, and then click Properties.
b. Click Install.
c. Click Protocol, and then click Add.
d. Click Have Disk.
e. In the Copy manufacturer's files from box, type System_Drive_Letter:\windows\inf, and then click OK.
f. In the list of available protocols, click Internet Protocol (TCP/IP), and then click OK.
2. Restart your computer.

Method 2
If you are correcting this problem on several computers and you have access to a working computer with the same operating system version and a similar hardware configuration, we recommend Method 2.
To resolve this issue, delete the corrupted registry entries, and then replace them with the registry key information that you exported from a computer that has a working installation of TCP/IP. To do this, follow these steps.
Delete the corrupted registry entries
On the computer that has the corrupted registry entries, follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
.
3. Right-click Winsock, and then click Delete. When you are prompted to confirm the deletion, click Yes.
4. Right-click Winsock2, and then click Delete. When you are prompted to confirm the deletion, click Yes.
Export the registry entries to a floppy disk
On the computer that has a working installation of TCP/IP, follow these steps.
Note The computer that you are importing the registry entries from must use the same version of Windows and be either similar to or a duplicate of the computer that is experiencing the symptoms that are described in the "Symptoms" section.
1. Insert a floppy disk in the floppy disk drive of the computer that has the registry entries that you are exporting.
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry subkey and then click Winsock:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
4. Click File, and then click Export.
5. In the Save in box, click 3½ Floppy(A:), type a name for the file in the File name box, and then click Save.
6. Click Winsock2, click File, and then click Export.
7. In the Save in box, click 3½ Floppy(A:), type a name for the file in the File name box, and then click Save.
Note Each .reg file that you save must have a different name.
8. Quit Registry Editor.
Import the registry entries from the floppy disk
On the computer that had the corrupted registry entries, follow these steps:
1. Insert the floppy disk that contains the .reg files in the floppy disk drive of the computer that is experiencing the symptoms that are described in the "Symptoms" section.
2. Start Windows Explorer, click My Computer, and then double-click 3½ Floppy(A:).
3. Double-click each .reg file that you created and saved to the floppy disk in the "Export the registry keys to a floppy disk" section.
4. Click Yes when you are prompted to add information to the registry.
5. Click OK when you receive the message that the information is successfully entered in the registry.
6. Quit Registry Editor.

MORE INFORMATION
These methods restore basic functionality to the Winsock and the Winsock2 subkeys. You may have to reinstall some third-party proxy software or firewalls.