Network Computingwww.networkcomputing.com

Getting to Know Your Users

In pcAnywhere 9.0, authentication methods are restricted to Microsoft Windows domains and an internal user database. The new version extends authentication to numerous methods, such as LDAP queries, Microsoft Active Directory, FTP, HTTP and HTTPS (HTTP Secure) login.

After I installed pcAnywhere and configured the host in our Real-World Labs® at Syracuse University, I examined our eight user-authentication options and tested several of them successfully, starting with FTP authentication. I already had an FTP server, so I simply entered the server address and the user name. When

I tried to connect to the pcAnywhere host, my authentication request was proxied to the FTP server for verification. Be aware that FTP and HTTP logins are passed in the clear from the pcAnywhere host to the destination server for authentication.

Next I added callers using HTTP authentication by giving the host name of the Web server and the user name I would use to connect to the server. When I authenticated to the pcAnywhere host, the authentication data was forwarded to our Web server. Because HTTP authentication travels over the network in clear text, you should use the SSL (Secure Sockets Layer)-enabled HTTP Authentication option on the pcAnywhere host to ensure that communication between the host and the Web server is encrypted.

Setting up the Netscape Directory Server authentication took a little more work. I configured our directory to be readable by the world. First I had to add the directory server to the pcAnywhere application, which I did by entering the directory server address and search base, leaving the user name and password blank. This configuration offered anonymous browse access to the directory. Once the entry was completed, pcAnywhere tried to verify the configuration but didn't succeed because I was binding as an anonymous user. It did let me continue without verifying the configuration and successfully bound me to the server once my system was properly configured.

After the directory server entries were established, I added callers to the host by browsing the directory tree and selecting users. This version of pcAnywhere uses the FQDN (fully qualified distinguished name) as the user name given to send the authentication request to the directory server. The user ID is automatically entered as the login name in the pcAnywhere host, which tells pcAnywhere which FQDN to use for authentication against the directory server.

Finding Remote

The pcAnywhere directory also can be used so host objects can register their status and remote objects can search for hosts. First, because I was planning to add data to the directory via pcAnywhere, I needed to configure pcAnywhere for authenticated access using a directory administrator's user name. Once that setup was verified, I then had to extend the schema of the directory and add a new object class to hold the pcAnywhere configuration data. I selected the "Use Directory" check box in pcAnywhere's host settings page, which caused the host to push its status to the directory. This let pcAnywhere's remote-control objects query the directory to see which hosts were available.

The directory search method is more reliable than a subnet scan, which sometimes misses hosts objects or misreports their status.

Intruders know that attacking improperly configured remote-access and remote-control machines is often far more simple than trying to break through a firewall. Version 10.0 ships with RAPS, which scans IP networks and phone lines for a variety of remote-control applications and unprotected remote-access servers. Scanning our local network, RAPS discovered remote-control applications as well as some X Window servers. You also can set up RAPS to dial lists of phone numbers and exchanges, so you can find those pesky remote-control applications waiting for a remote user dialing in over the PSTN (public switched telephone network).

Controlling the Installation

One of the biggest boons for administrators rolling out pcAnywhere is the new packager tool for distributing customized installations. Gone are the days of the clunky configurator; the new pcAnywhere Packager lets you customize and build installation packages that users can install. After creating an option set that configured basic application parameters -- such as directory services, network addressing and performance settings -- I crafted a new package. Through the packager, I limited the installation to only the components required to launch a pcAnywhere host (which reduced the install footprint) and locked the host from modification by end users.

Given that users often try to find a way around access restrictions -- and that one of the easiest methods is to reinstall the application -- pcAnywhere offers integrity checking of the installed application. If the executables, pcAnywhere connection objects or registry entries are changed from the packaged install, the application will not run. This means that users attempting to overwrite an installation with pcAnywhere or someone trying to modify the connection objects will not be able to launch pcAnywhere. It also means that users cannot install a full copy of pcAnywhere over a limited installation or if the executables are altered by a virus. Either action will stop pcAnywhere from running. Users can, however, uninstall the package and then reinstall a new version of pcAnywhere, so you have to make sure users can't install or uninstall applications.

If you have pcAnywhere 9.X deployed, you are probably familiar with the old PCA Config utility and have built up a host object repository. Version 10.0 gives you a better configuration, more authentication methods and directory service support, but I don't necessarily see these improvements as worthy of an upgrade. If you are a first-time buyer of pcAnywhere or are upgrading from a version older than 9.X, however, this package makes a lot of sense.