Windows 2000 – 2000Trainers.com

Add Remote Control to Active Directory Users and Computers

If you’re an administrator of a network running Active Directory, then you probably spend a great deal of your time working within the Active Directory Users and Computers MMC. While there’s no question that this and other management tools can be extended in cool ways to perform additional tasks (similar to what Alan outlined in his recent Windows Scripting article Extending the Capabilities of Active Directory Users and Computers Using VBScript), scripting isn’t the only option. In fact, you can add “remote control” capabilities to Active Directory Users and Computers by installing a simple (and free) Resource Kit utility available for download from the Microsoft web site.

The Remote Control Add-on for Active Directory Users and Computers (rControlAD.exe) is a tool that adds the ability to connect to any computer running Remote Desktop or Terminal Services directly from the popular MMC tool. Once installed on one server in your Active Directory forest, you can simply right-click on any computer object and select Remote Control. Doing so launches a Remote Desktop-style connection to that system, without the need to specify a computer name or IP address manually.

The rControlAD tool can be downloaded here. Just extract the downloaded file, and then install it. You be presented with a message similar to one shown below.

Once the installation is complete, just fire up Active Directory Users and Computers, browse to a computer object, right-click, and select Remote Control. That’s all there is to it!

Whether you’re looking for an easy way to access your Windows XP Professional desktops or a way to seamlessly connect to Terminal Services on Windows servers, this tip makes it a snap.

Managing Windows Servers with Terminal Services

Administering multiple Windows 2000 Servers in a multi-site environment can sometimes become a tedious task to say the least. Picture this scenario: your company has four offices, two within a kilometer of each other, another approximately 100 km away, and the fourth resides in a totally different country. You are responsible for all the Win2K servers in each office. How much travel time do you have to account for in your daily administrative workload, just to perform minor updates, troubleshooting, or configurations of these servers? Fortunately, Microsoft has bundled a very useful component into the Win2K OS called Terminal Services, which can be used to remotely administer Windows 2000 Servers on your network. The Microsoft Terminal Services Client software used to make connections to Terminal Serves communicates over a TCP/IP network connection using the Microsoft Remote Desktop Protocol (RDP). When configured in Remote Administration Mode, Terminal Services provides a free and powerful tool that can save you time and your company money, by allowing you to remotely administer your servers right from your desk, using a variety of client connection options.

Terminal Services can be installed in one of two modes: Remote Administration mode or Application Server mode. Remote Admin mode provides you with up to two connections, and does not require any additional licensing or cost. By default, Users in the Administrators group will have permissions to make a connection to your server configured for Remote Admin. Application Server mode provides connections based on purchased client licenses and is used in a thin client server-based computing environment. To install Terminal Services on your server, select the Add/Remove Windows Components icon located in Add/Remove Programs in Control Panel.

Pages: 12345

Network Address Translation (NAT) Quick Start Guide

One topic that seems to cause users a great deal of anguish is the configuration of Network Address Translation (NAT) for the purpose of providing shared Internet access on private network. This guide is meant as a quick reference for those who need to implement NAT on networks, especially small networks that include Active Directory.

For all intents and purposes, the most simple way to provide your internal network with shared access of a broadband (or for that matter dial-up or ISDN) Internet connection is the Internet Connection Sharing (ICS) feature of Windows 2000. However, ICS also imposes a number of limitations that make it a poor choice for environments that include Active Directory. For example, when the external connection (the one to which a public IP address is assigned) is shared, it will automatically give the internal adapter an IP address of 192.168.0.1. On top of this, ICS automatically configures itself as a mini-DHCP server, allocating addresses to internal clients in the 192.168.0.0/24 range. Finally, ICS also works as a DNS proxy, expecting that your clients will use the ICS system as the destination for all DNS-related queries to the public Internet.

While this may work fine for small LANs, ICS makes life complicated on networks that already have an IP addressing structure in place (either through the use of static addresses or a via a separate DHCP server), as well as those running Active Directory (and by extension, DNS). In cases where you don’t want to undo your current IP addressing, and want a more robust Internet sharing solution, Windows 2000 NAT is the answer.

In this quick guide, I assume that the server on which you want to configure NAT is running Windows 2000 Server at a minimum, and has two network cards installed – one connected to your external network (using a DSL or cable connection, for example), and one connected to your internal LAN. NAT can also work with dial-on-demand modem or ISDN connections, but that’s another topic, for another time.

Pages: 1234

Active Directory Quick Start Guide

Setting up Active Directory is far from difficult. However, many people experience problems with their installation shortly after completing it because they neglect to properly plan their implementation of DNS. I receive emails on almost a weekly basis from users who have gone ahead and run dcpromo, and then wonder why client systems can’t properly connect to the Internet. The purpose of this article is to act as a quick primer towards ensuring that Active Directory works, while at the same time allowing your network systems proper Internet access.

Before I begin, it’s worth mentioning that this article is aimed at users who are looking to install and work with Active Directory on a small or home network. It is not aimed at users upgrading from NT 4, or planning a major Active Directory deployment including Exchange 2000, although the central concepts outlined still hold true. However, if you are looking for a quick and easy guide to setting up an AD test network, then this article should help to ensure that you get started on the right foot. I assume that the server we are configuring will be the first domain controller in your new Active Directory domain, and that your internal systems can already access the Internet via some method, such as Internet Connection Sharing, NAT, or perhaps some type of connection-sharing hardware router.

Pages: 123

Deploying Scripts Using Group Policy

In a Windows NT 4.0 domain environment, assigning scripts to users was more of less restricted to simple logon scripts. Not particularly flexible, but generally enough to get the basic jobs done – mapping directories, printers, environment variables, and so forth. For all intents and purposes, however, you were still in a simple batch file environment. In order to get into any more advanced scripting, you needed to use an additional scripting language such as Kixstart. In a Windows 2000 domain, however, the power of Group Policy unleashes script deployment capabilities that make NT 4.0 pale in comparison.

For those who like their networks a little old school, you can still deploy logon scripts in the properties of a user account in a Windows 2000 domain. While this is still acceptable, it constitutes a waste of a wonderful opportunity. With Group Policy, not only can you deploy scripts to multiple users in a single step, you can also define scripts settings in a hierarchical fashion. Scripts can be assigned not only to all users in a domain, but also according to sites and OUs. In cases where multiple GPOs affect a user, multiple scripts can be applied. This capability represents a powerful feature that shouldn’t be overlooked by system administrators.

Logon scripts aren’t the only type that can be defined with Group Policy. GPOs can be used to apply Logon and Logoff scripts to Users, and Startup and Shutdown scripts to computers. As the names suggest:

Logon scripts are applied once a user logs in
Logoff scripts are applied once a user logs off
Startup scripts are applied when a computer boots
Shutdown scripts are applied when a computer shuts down

The ability to define scripts in these different ways provides an additional level of functionality not experiences in previous versions of Windows. Furthermore, you are no longer limited to simple batch scripts – more powerful VBScripts can be used to further extend the abilities of the administrator.

Pages: 123

Encrypting File System (EFS)

Although the idea behind the Encrypting File System (EFS) in Windows 2000 seems pretty straightforward, there is a great deal more to it than first meets the eye. The purpose of this article is to explain how EFS actually works, and to provide practical configuration advice for system admins.

Why use EFS? The simple answer is that relying on NTFS permissions alone is sometimes not enough. There are simply too many utilities that will allow a user to bypass NTFS security on the market, such as NTFSDOS. Beyond the utilities, imagine the scenario with a mobile user. If the user’s laptop were stolen, the thief would only need to either remove the hard drive and place it into another W2K system, or reinstall W2K and take ownership of the folder as the new administrator account. In either scenario, highly confidential data is not safe. If you’re looking for more security EFS may be the answer you’re looking for, and you can’t beat the price.

I’m going to try not to bore you with the details of what you probably already know. Here’s the useful beginner stuff, just to get it out of the way:

EFS can only be used on NTFS formatted volumes.
EFS cannot encrypt files if any of the following attributes are set: Read-only, System or Compressed.
If you have ‘write’ permissions to a file, you can encrypt it.
If the user who encrypted the file moves it to a FAT volume, the file is no longer encrypted.
EFS encryption is relatively transparent to the user. To encrypt a file, the user need only set the encryption attribute on the file, or save it to an encrypted folder.
EFS is file-system encryption. That means that when an EFS-encrypted file moves over the network, it is NOT encrypted.
EFS does not prevent a user with the appropriate NTFS permissions from deleting a file.
To encrypt many files at once, use Cipher.exe from the command line.
When an encrypted file is opened, so are temporary copies if they exist.
Users cannot share encrypted files.
Only the user who encrypted a file can open it (with exceptions, of course!)

The last item on the list is important. Although the only person who can open an EFS-encrypted file is officially the person who encrypted it, there is still a back door of s orts – the recovery agent. The recovery agent is by default the domain Administrator account (more on this later, but there can be more than one), and can open files that were EFS-encrypted by another user. The reason for this is simple. If a user somehow loses their private key, or snaps and go encryption-crazy on their last day on the job, we have a way to recover their files.

Pages: 1234

Installing Certificate Services

Installing Certificate Services on Windows 2000 is quite simple, though the choices available to you will again depend on your environment. For the purpose of this illustration I will walk through the process of creating a Standalone Root CA – mainly because my computer is not configured as a domain member at the moment. Since it is not installed by default, you will need to add Certificate Services using the Add/Remove Programs – Windows Components option in Control Panel.

Note that when you attempt to choose Certificate Services, you will be presented with the dialog box shown below. Note the fact that you will not be able to rename the system or join or be removed from a domain without first uninstalling Certificate Services.

After choosing Next, you will be asked to decide what type of CA you wish to create. My system has only the Standalone CA options available, since it is not a member of an Active Directory domain.

Note that the Advanced options checkbox on the screenshot above will allow you to choose advanced cryptographic options in the key generation process. I would suggest allowing the default values to be used unless you are certain of the need to make other choices.

Clicking Next again will bring you into the CA Identification screen, where you should enter the appropriate information. Note that while not all fields are mandatory, they should be completed in full.

The final screen in the process asks for where you wish to place configuration and logging data.

Once Certificate Services is installed, the Server is ready to accept certificate requests from clients. For a Standalone CA these requests must be made a web browser by accessing the certificate server using the URL http://computername/certsrv. A wizard that walks you through the process step-by-step handles the actual request process.

The certificate request process also includes providing information about the user, the use of the certificate, and so forth. I am requesting a certificate to secure email.

After the request is completed, the user is presented with the following message. Note that the request has been made, but the certificate will not be issued until approved by the Administrator.

The approval process for a requested certificate is pretty straightforward. Using the Certificate Authority tool in Administrative Tools, open the Pending Requests option, and choose to Issue the certificate or deny the request.

Note that once completed, the user can again access the Certificate Services web site and download and install their new certificate. The certificate just issued will now be found in the Issued Certificates section from the screen above, and can be revoked from this interface as well. In an Active Directory environment, note that users can also request certificates using the Certificates MMC snap-in, or can be configured for auto-enrollment of certificates (on both a user and computer basis) via Group Policy. In large environments running an Enterprise CA, this is often the most practical idea.

Certificate Server Types

Before covering the installation of Certificate Services in Windows 2000, it is important to understand the different types of Certificate Authorities that can be installed. A root CA is the top link in a chain of CAs, while a subordinate CA is a downlevel server that has one or more CAs above it (and eventually reaching a Root CA). Windows 2000 supports 4 types of CAs, as described below.

Enterprise Root CA – An Enterprise Root CA is used in corporate environments for issuing certificates to users and computers. An Enterprise CA requires that Active Directory exist, DNS be configured correctly, and that the user configuring the server have Enterprise Administrator privileges. In an Active Directory environment, an Enterprise Root CA is automatically registered in Active Directory and trusted by domain computers. In a large PKI setup, the Enterprise Root CA is usually used to issue certificates only Enterprise subordinate CAs, who then issue certificates to users and computers. Though this is often the case, it does not have to be, as an Enterprise Root CA can issue user and computer certificates as well.

Enterprise Subordinate CA – An Enterprise Subordinate CA is a certificate server that exists hierarchically under an Enterprise Root CA. Often Subordinates are used to for a specific purpose, such as granting certificates for users, or computers, or for a specific portion of an organization. A Subordinate CA requires all of the same services and privileges as an Enterprise Root CA, and cannot be created unless an Enterprise Root CA exists. Note that although the Enterprise Root CA might be another internal Windows 2000 certificate server, it might also be an external CA such as Verisign. In fact, if you want the outside world to trust the authenticity of your certificates, it is pretty much imperative that you trust an External Root CA such as Verisign. Otherwise, external users will need a copy of your Root CA’s certificate, which they are certain not to have, unless as part of some partner relationship.

Standalone Root CA – For environments without Active Directory, a Standalone Root CA can meet certificate requirements. These servers require only Administrator privileges on the server. If Active Directory does not exist in the environment, this is the only type of Root CA that can be installed.

Standalone Subordinate CA – Much like the Enterprise Subordinate CA, this certificate server might be used to issue certificates to certain departments or users or computers, but does not require Active Directory. However, it does require a Root CA, which can again be internal or external.

An important consideration when choosing the type of CA is the environment and the way in which you intend to use the certificates. If it is strictly for internal use, then your options are wide open according to your environment (for example is you have AD, then use you can use either Enterprise or Standalone CAs). If however you need certificates to secure a public website, then an external certificate authority will need to be involved, either providing the certificates for that site directly, or via a chain of trust.

Introduction to Certificate Services and PKI

Of all the many services that Windows 2000 offers, one of the least understood is probably Certificate Services. While it may seem that anything that has to do with cryptography is unnecessarily complex, understanding the main elements is certainly not difficult. Certificate Services exist for one primary purpose – to help in the creation of something referred to as a Public Key Infrastructure (PKI). The purpose of a PKI is simple – to allow data to be encrypted, to have users (or computers or services) authenticated and verified, and to have some system of trust that allows this all to work efficiently. You should also have an awareness of what certificates can be used for in Windows 2000 – in other words, why you should even care. Examples include authentication by Smart Cards, encrypting files and email messages, authenticating to web sites, authenticating computers for L2TP connections, and so forth – each of which relate to or rely on PKI in some respect. The key to understanding how a PKI works first involves understanding the two main elements that it is made up of – certificates and Certificate Authorities.

To make things easier, from now on I would suggest thinking of a certificate as being like a drivers license. For all intents and purposes, it is a piece of identification that tells something about you and can be used as proof of your identity. The most important detail about your driver’s license is that fact that it was issued by a trusted third party, more than likely a department of local government. The license bares the department logo or signature, and as such they vouch for your identity. The only reason that a drivers license works as identification is because we have established trust in the system – I believe that your license is real because it was issued by government, and also because I too carry a license which is proof of my identity. I trust the government and so do you, so the system works (whether you really think the government is trustworthy is another story). In this case, the government is acting as the trusted third party – the Certificate Authority (CA). So first and foremost, think of the certificate as something that can prove your identity, with the CA acting as the one who has actually verified that you are who you say you are.

Pages: 123

Implementing IPSec

IPSec is a security protocol included in the Windows 2000 TCP/IP stack. Its function is simple – to secure TCP/IP communications within or between networks according to the parameters and rules that you lay out. While the concept itself is simple enough, the actual implementation of policies that will do what you want actually requires a deeper understanding of TCP/IP. Not only must you understand how communication takes place on the network, but you must also be able to translate your security needs into specific explicit policies. That requires knowledge of protocols, port numbers, and more, as well as a plan for how and where you need to encrypt or confirm the integrity of traffic. While it might immediately seem like a good idea to encrypt all traffic on your network, that isn’t necessarily practical or a good idea. Understand that you pay a price for encryption in the form of higher CPU utilization. This might not be a big deal for an individual workstation with a high-speed processor, but consider also the load on the server that it handling (and encrypting) multiple simultaneous encrypted connections. Instead, focus on using encryption where required for security purposes, creating a setup that meets the needs of your organization. It will seldom be a one-size-fits-all scenario.

If you are considering using IPSec, you first need to understand a bit about how it works. First of all, IPSec encryption / authentication differs from what you may already be familiar with in terms of security products. Most people have worked or are familiar with application-level encryption, where a program (such as PGP or similar) actually handles the encryption/decryption/signing processes. In contrast, IPSec actually resides in the protocol stack, independent of applications. Because of this, you are able to encrypt the data from any application prior to transmitting it over the network. Imagine that a client application on computer 1 wants to send encrypted data to a server application on computer 2. While there certainly needs to be some coordination between the two systems (we’ll get to that in a bit), the applications on either side actually have nothing to do with the encryption process. The client application would simply begin passing data down the protocol stack like normal, where it would be ‘intercepted’ by IPSec, encrypted, and sent to the server system. On the server, the data moves up the stack, and is decrypted by IPSec prior to being passed to the application. For all intents and purposes, the encryption is transparent to the person on the client side – something very favorable indeed.

Pages: 123456