Watching the Big Three After you patch, life with NetWare consists of being careful about three environments that substantially affect your security: Server environment Server console and configuration Client environment Workstations, client software and configuration NDS (Novell Directory Services) environment In what can be a hugely complex system, it's useful to distill all your NetWare security concerns into these three groups. Not every individual is responsible for each group, but every individual suffers the consequences if these categories are not tended to. (If you're "lucky" enough to be the only person in your shop who tends to all three of these, pat yourself on the back and demand a raise.) Accordingly, you'll want to figure out who's responsible for what in your organization it doesn't do any good for only one of these subsystems to be locked down. Server Environment It's an understatement to say that, when an intruder is able to access your server console, the battle is lost. If you're new to NetWare, here's a basic, horrible fact about the OS: There is no explicit login to the console. The default access when you boot up amounts to "The dude who's driving is large and in charge." Huh? This sounds awfully weird, if you're used to UNIX or (properly configured) NT. Why would the console offer supervisor privileges to just anybody? The answer is, it doesn't explicitly offer these privileges. Many of NetWare's NLM (NetWare Loadable Module) tools require authentication before they allow you to perform privileged operations. But, because NetWare in its default configuration allows anybody who is driving the keyboard to load an NLM, it implicitly allows the driver to perform any privileged operation that is coded into that NLM. For example, simply by loading an NLM (and without causing undue suspicion you don't have to reboot to do these things), you can Set the administrative password (which would alert the real administrator that something's awry) Add an additional administrative user to the system with a password of your choice (which would not alert the administrator) Snag the entire NDS database (if you're driving a server with a replica on it) for offline decryption with publicly available tools Commit other mayhem at will Sound bad? It is. Again, merely by inserting the right floppy diskette in the drive or by loading an NLM from a user's directory on the server you can, as an untrusted user, be treated as a trusted user at the console. Novell offers a partial solution, the SECURE CONSOLE command. It's a hard call: On the one hand, SECURE CONSOLE protects your servers from a keyboard interloper who wants to Load NLMs from anywhere but SYS:\SYSTEM or C:\NWSERVER Gain access to the NetWare debugger (right-shift+Alt+left shift+ESC), and possibly hand-enter malicious code Change the time to try to break security On the other hand, SECURE CONSOLE can be a real pain when you have to do maintenance. Even a legitimate user (you) can't change the time to correct for clock drift, you can't add a search path, and you cannot load NLMs from anywhere but the two system locations. It would be a wonderful thing if you didn't have to reboot the system to disable it. Unfortunately, using SECURE CONSOLE is a must if your physical security is at all in question if there's even a possibility of an unauthorized person sitting down at your server keyboard even for a moment. Physical Security Here's the obvious: Keep your consoles (and backup tapes!)behind locked doors. But as with other operating systems/routers/pieces of key infrastructure, there is usually some point when your space gets shared, be it with the cleaning people, outside consultants, or your own folks. Note I was once in an IT shop where an application consultant was invited to set up his office in the computer room there wasn't any extra office space. That's Huge Problem #1. Then, the consultant started doing ad hoc training for users of his application right in the data center. Huge Problem #2? He gave out the passcode to the data center door, and the user was sitting at an NT console merrily playing Solitaire when the consultant arrived. ("Oh, was that a server?") Notwithstanding how trusted the consultant was, the user could have been anybody. All of the data center's physical security was compromised the instant the consultant was trusted in the data center. A corollary: Any server that is not physically secure must not be part of your production NDS tree. Any machine that isn't physically secure can't be considered trusted, and any untrusted console can wreak havoc on your tree. This means new servers that are being set up on an unsecured workbench; lab machines; test machines, and so on. Naturally, any switches or hubs that your servers or administrative workstations are connected to also need to be behind locked doors, particularly in light of how easily NetWare's default remote control encryption is defeated. (See the section "RCONSOLE," later in the chapter.) Physical security can be a pretty large and ongoing task (for more on physical security you can refer to Chapter 26, "Policies, Procedures, and Enforcement)." After you've set up physical security for your production servers, you need policies, procedures, and regular checkups to make sure that your secured areas stay secure. Securing an Insecure Console The best thing to do with an idle console is to use a utility to lock down the keyboard, and only unlock it if someone authenticates. NetWare 5 has just such a utility, scrsaver.nlm. It's pretty easy to use; just type scrsaver help at the console prompt for on-the-fly directions. I like to set up the screensaver to kick in and lock down after four minutes of idle time. (You can see what this looks like in Figure 21.1) The screensaver is not a default action; you must load and configure the screensaver each time. You can do this by putting the following line in your AUTOEXEC.NCF: Figure 21.1. It's a good idea to load scrsaver.nlm upon server startup, so that it locks down the keyboard when the console has been idle. 
scrsaver enable; delay=240 Some folks also like to start the screensaver up as the last action of the AUTOEXEC.NCF. This way, even if someone does get access to one of the servers right after boot time, they need to authenticate. In this case, the last line of your AUTOEXEC.NCF should look like this: scrsaver enable; delay=360; activate Note Activating the screensaver at boot time is not a sure-fire way of keeping someone out of your console; an intruder could, at first-stage boot time, avoid execution of the AUTOEXEC.NCF by typing server -na from the DOS prompt. NetWare 4 Console Lock NetWare 4 doesn't have a cool password-protected screensaver. Novell's considering making one available, and it might be by the time you read this. Check out the status of this enhancement request at http://support.novell.com/cgi-bin/search/tidfinder.cgi?2952871 In the meantime, you can always use the MONITOR.NLM to manually lock your console down when you're not using it (see Figure 21.2), or get a third-party tool (check the end of this chapter for product listings). Figure 21.2. Although NetWare 4's MONITOR.NLM has a lock function, it requires an administrator to explicitly lock the server, rather than doing so after a timeout. 
RCONSOLE RCONSOLE, the remote-control tool for NetWare servers, can be a NetWare administrator's best friend. Unfortunately, it's not exactly a very secure friend. The first problem with RCONSOLE is that, by default, its password is stored in plain text. If you're an old-style CNE (Certified NetWare Engineer), your AUTOEXEC.NCF might have a line like LOAD REMOTE MYPASSWORD in it. (If you use INETCFG.NLM to configure remote access, the password is stored in plain text in SYS:ETC.) Obviously, this is a Bad Thing. You don't want someone printing out your AUTOEXEC.NCF for troubleshooting purposes, and then accidentally leaving it around for the entire world to see. Furthermore, because RCONSOLE sends screens over the network "in the clear," someone with a sniffer could watch you scroll through or edit your configuration file and read your password. What to do? NetWare has a method of "encrypting" the REMOTE password (REMOTE ENCRYPT at the server console), but it is worthless in terms of secure encryption. In less than a second, you can use a DOS-based, publicly available tool, REMOTE.EXE, to break even the largest passwords encrypted this way. Don't use REMOTE ENCRYPT; it will do nothing but give you a false sense of security. In short, using RCONSOLE over potentially untrusted networks is a really bad idea. If you really must use it, make sure that Your data link and network infrastructure is secured from eavesdropping. The two server-possible directories in which the password might be stored are unreadable by anybody but Admin-equivalents (directories such as SYS:SYSTEM and SYS:ETC). RCONJ, the "pure Java" version of RCONSOLE, has similar problems, and should be treated with similar care. If you are serious about secure remote control of the console and you should be, if you are responsible for an enterprise's security see the end of this chapter for third-party tools that are much more secure. Network Computing's October 16, 2000, issue has a detailed workshop by Kevin Novak that discusses RCONSOLE and RCONJ, available at http://www.networkcomputing.com/1120/1120ws1.html. UNIX-Compatibility Utilities Speaking of plain-text remote control utilities, XCONSOLE, the Telnet server for NetWare, is no safer than RCONSOLE. It uses plain-text Telnet for the authentication, and either Telnet or the X protocol both non-encrypted protocols for the session data. You should avoid XCONSOLE as well, unless you're absolutely sure that your infrastructure is un-tappable. The same goes for FTP. Although FTP is arguably less of a risk than RCONSOLE if non- administrative users are ftping, FTP is just as grave a risk as RCONSOLE if administrative users ftp in to the server. All passwords for FTP are sent in the clear. Avoid, avoid, avoid. As with any service, if you have no pressing business reason for using the service, you should probably use UNICON.NLM to deconfigure both of these tools(see Figure 21.3). Figure 21.3. Use UNICON, NetWare's UNIX Services Configuration tool, to stop unwanted UNIX-compatibility services from running. 
WWW Services In the past, NetWare 4.1 and IntranetWare shipped with the NetWare Web Server not the Netscape Enterprise Server. The Web server included a PERL.NLM, that allowed arbitrary execution of code on the server a very bad thing indeed. Although this hole has long been plugged in newer versions of the Web server, we mention this because the Web server is not part of the NetWare 4 core OS and thus not part of the OS's service pack. You need to go out and separately update it (or, upgrade to NetWare 5). Finally, as with any Web server, you'll want to search-and-destroy any sample scripts. Leaving them there is simply asking for trouble. NETBASIC.NLM Get rid of NETBASIC.NLM unless you have a pressing need for it. There are several attacks involving NETBASIC. This is particularly true of NetWare 4, which doesn't have NetWare 5's SCRSAVER.NLM. Even if you've used the SECURE CONSOLE command, NETBASIC.NLM allows someone who accesses the console to Drop to a NETBASIC shell Copy untrusted NLMs into the SYS:SYSTEM directory Copy the NDS files from the hidden SYS:SYSTEM\_NETWARE directory to arbitrary locations on the file server Perform trusted file operations that could potentially make your life miserable Again, if you've got NetWare 5 and SCRSAVER.NLM (or NetWare 4 and a third-party utility), this isn't as hot an issue, but it is still due diligence to remove this tool from the server unless you need it. TOOLBOX.NLM Toolbox is one of the most useful administrator tools available for NetWare. It even attempts to keep its operations secure you must authenticate to the tree before it will obey your commands. However, Toolbox is frequently used in batch files, and administrators tend to save authentication information to the Toolbox database. (For example, many administrators use Toolbox to reboot the server, purge limbo blocks from volumes, and so on.) In a nutshell, an intruder who's familiar with Toolbox will likely type AUTH LOAD at the console. If an administrator has previously done an AUTH SAVE, then the intruder can use Toolbox's functions without logging in. Basically, if you're doing AUTH SAVEs, the same rules apply to Toolbox as were previously described for NETBASIC. If a screensaver is unavailable, the potential amount of damage is huge. If a screensaver is in use, AUTH SAVE has a more acceptable level of risk. Server Environment Parameters There are publicly available tools that can spoof NCP (NetWare Core Protocol) packets thus making hijacking a session a real possibility. To prevent this from happening to your users, you'll want to set your server's NCP parameters to include packet signature, packet length, and packet component checks. For example, to get the highest level of NCP security, you'd type SET NCP Packet Signature Option = 3 SET Reject NCP Packets with bad components = ON SET Reject NCP Packets with bad lengths = ON at the server console. (NetWare 4 users have to put these in the AUTOEXEC.NCF as well.) Note You will definitely want to do tests in your environment before you enable a packet signature level of 3. Level 3 means, "Don't communicate with ANYBODY if they don't sign their packets." This might be a bad thing if you haven't enabled your clients'packet signature options. (Although, Novell's latest client defaults to "will-do," as discussed later in the chapter.) Furthermore, you will want to test your servers to see how they'll hold up under the load with a signature level of 3. The amount of processing dedicated to cryptographically signing packets is non-trivial. Bindery Context A bindery context is only necessary on a server if its third-party software doesn't understand how to communicate via NDS. Unfortunately, there are still NetWare utilities that don't. Upgrade them, if you can, to utilities that are NDS savvy because there are publicly available tools that attack based on bindery contexts. (See the "Guest and Other No-Password Users" section for an example of this.) NetWare servers default to having a bindery context; get rid of it by typing set bindery context= (That's right, there's nothing to the right of the equal sign). The system will warn you that bindery services have been disabled. If you don't need 'em, this is a good thing. Client Environment You'll want to stay native with your NetWare client that is, use Novell's client, not Microsoft's. Microsoft's client doesn't support packet signing neither advisory (Level 2) nor mandatory (Level 3). The NetWare client defaults to the same thing that the server does Level 1: "Perform packet signatures only if the other side requires it." So, if you're using the latest version of the NetWare client, you won't have a problem setting the server to a mandatory packet-signature level. Still, if you're serious about requiring packet signing, you'll want to set your clients to Level 3. Again, make sure to test any parameter changes in your environment before rolling them out. As advisories come out, you might find yourself changing a large number of client workstations at a time. ZenWorks or other desktop management can make this easier and quicker. Windows: The Weakest Link Without getting into operating system holy wars here, let's just say that you need to pay special attention to Windows workstations where administrative users log in. The PWL files (in Windows 9x) and the SAM (of Windows NT/2K workstations) are very easily cracked. This is fine if you only log in at workstations that have tight physical security. But what about when administrators need to log in from the field? If you must do this, consider using some sort of encrypted remote control, rather than using the desktop of the workstation that you are working on (for example, Citrix, PCAnywhere, and so on). The last thing you want to do is leave your administrative NDS password and username as a dropping on the user's highly insecure workstation. Also, check out Chapter 18, "Trojans," for information on protecting your workstations from programs that can hijack login information. Because it's likely that you're in a NetWare environment, you might want to use ZENWorks to assign policies that lock down your client workstations. Finally, if you have public terminals, or a Citrix remote login system, you will definitely want to disable the "Advanced" function of the client. The browse functions of the Advanced tab provide more information to an intruder than you want to disseminate. (If you do this, you'll want to enable "context-less" login, unless you want your users typing .myname.mydepartment.mylocation.myorg as their username.) Novell Directory Services (NDS) Environment Any directory service (DS) needs to be maintained from birth and throughout its life. Neglect and oversight are the main reasons a DS fails whether in the security space, or simply from the functionality perspective. A Good Start: Intruder Detection Intruder detection is a way of making NDS count the number of failed login attempts within a certain time frame and lock the account for a certain amount of time if the number of failed logins exceeds a certain limit. Let's look at an example. An intruder writes a program to do a dictionary or brute-force attack on a given user's login, say, user name "JOE," using the authentication calls that are available via the NetWare API. If there is no intruder detection, the intruder can cycle through thousands of possible passwords in a relatively short time. If the admin has enabled Detect intruders, as shown in Figure 21.4, the following happens: Because the intruder is trying more than seven passwords in a 30-minute period, the account is locked for 15 minutes. All of a sudden, rather than being able to cycle through thousands of passwords, the intruder can only cycle through seven before the account gets locked. This is an extremely good protection against systematic, online, real-time password cracking. Figure 21.4. You'll want to use NWAdmin to enable intruder detection on each organizational unit in your tree. 
The bad news is intruder detection is not enabled by default. You'll need to go into NWAdmin and enable it per OU (organizational Unit) as part of your "new tree SOP (Standard Operating Procedure)." User Names: Admin Admin is the first user created in a new NDS tree. The first thing a lot of folks do after installing a new NDS tree is to rename the Admin user to something nonobvious and put Admin into a nonobvious container (like .GSmith.abc.myorg.) This container should be stored separately from that of regular users. This is a good measure, as far as attacks from outside your organization go, but it's not foolproof. As we've discussed elsewhere, lots of security problems come from the inside. A temp worker intern, air conditioning repair person, or receptionist might see an administrative user log in (like, um, YOU while you log in to solve a problem for this person) and thus gain information about an administrative user's login name. Perhaps it's not THE Admin user, but it's an Admin user which is all potential crackers are looking for. So, move the Admin user if you want, but know that this is not a cure-all. Naturally, you'll want to make sure that all administrative users have very good passwords. Use NWAdmin to make sure that administrative users have policies in place to require a password of sufficient length. Guest and Other No-Password Users Unless you have a need for a Guest account and most organizations do not delete the Guest user. (NetWare 5, happily, does not supply a Guest user by default when you install a new NDS tree.) If you're administrating an existing NDS tree, you will want to check for users with no passwords on a fairly regular basis (or, use NDS auditing software, discussed later in the chapter). Even if these accounts have NO special privileges, they will allow an attacker to browse the tree and gather an intruder's best friend, more information. If they belong to a container that's been given special authority (a bad idea see the section "Unintended Consequences of Container Rights" ), suddenly you've got a problem on your hands. How do these no-password accounts "show up?" There are tools (for example, backup, anti-virus, print servers) that generate accounts so that the program can log in to the tree without operator intervention. You'll want to make sure that these accounts do NOT allow an interactive login at least, not without requiring a password. Try it; if the tool account allows you to log in, restrict the account to certain network addresses only the network addresses of the station that runs the program, such as the anti-virus console, the print server, and so on. (Some of these types of tools don't allow you to specify a password, so changing the password won't fly.) You and an intruder can find accounts with no passwords, if you have a bindery context set (see why a bindery context isn't a good thing?), with the freely-available CHKNULL program. A good NDS auditing tool will also find these. Note There is literature out there that implies that you can also use NLIST to find null password information. This is not the case. NLIST will show you what the policies are for users that is, if a null password is allowed, and what the minimum password length is. These are useful things to know (because you don't want a user to have too short of a password, or to be allowed to blank it), but be aware of the difference. Enforcing User Authentication Policies NetWare has a bunch of good password management built into NDS. Each site is different, but typically, enabling the password management can greatly increase your security. Using NWAdmin, you can set Whether a user can change his password Whether a password is required The minimum password length Whether periodic password changes are required, and how many days are required between changes The number of times the user can procrastinate a required periodic password change before getting locked out (called grace logins) Whether unique passwords are required These policies are delegated per user, not as part of a group. You'll want to use NWAdmin's Details on Multiple Users feature (see Figure 21.5) if you want to change the policies of many users at once. Figure 21.5. If you are changing the password policies of a bunch of users at one time, use NWAdmin's Details on Multiple Users options. 
If your organization believes that passwords are too easily compromised (by users writing them down, sharing them, and so on), you can investigate alternative login methods, such as biometrics. The Novell Modular Authentication System (NMAS) supports third-party authentication such as fingerprinting, SecurID, and so on. You can read more about NMAS at http://www.novell.com/products/nmas/details.html Understanding and Applying NDS "Best Practices" The Novell Directory Service is the heart of your NetWare network. Servers, accounts, file systems, certificates everything relies on NDS being configured correctly. If you or your system administrators don't fully grok NDS, or take short cuts, you are likely to make mistakes that will leave you vulnerable to attack. Note There is a huge body of work about NDS most of it, naturally, written by Novell. If you are shaky on your NDS understanding, or want to make sure you fully understand it, a good place to start is the Novell Research AppNote, "Learning and Applying the Rules of NDS Security," found at http://developer.novell.com/research/appnotes/1997/august/02/index.htm. Unintended Consequences of Container Rights Container rights are one of the most convenient NDS features you apply rights to an organizational unit (OU), and the rights flow down so that children containers and their objects inherit these rights. Convenient yet dangerous. With many objects and subcontainers in a tree, it can be difficult to visualize just what the consequences of inherited rights can be. One common and bad practice that some IT shops have is to link administrative rights to an OU, for example, the "SysAdmins" OU. They figure, "Anybody in this OU is an administrator, so what's the harm?" The answer is, "It can be plenty of harm." For example, a recently discovered problem (http://Feldman.org/zen) with the ZenWorks workstation manager allowed any workstation objectto assume the rights of its container without a user being logged on. This made it easy for an untrusted user to get sneaky and run programs with those rights. In the case of a container that was assigned Admin rights, the workstation assumed the Admin rights because it was part of the container. All of a sudden, the intruder had admin rights, too. If the container had not been given special rights, the damage of this exploit would have been minimized. Lesson: Don't assign sensitive rights to a container, ever. What are sensitive rights? Some of them include Security equivalencies to administrative users Any rights to the root of any volume Any rights to SYS:\etc Any rights to SYS:\system Use groups instead of containers to assign these types of rights. This is a good administrative practice. Because a group is a central point of administration, the potential for admin error is decreased. There's nothing inherently wrong with grouping; the problem only has to do with inheritance and thus, containers. Although Novell (and other literature) will tell you that problems with inheritance can be handled with an IRF (Inherited Rights Filter), consider the previous problem. Would an IRF block rights to workstation objects in the same OU as the administrative users? No! An IRF "flows down" through the tree. Objects in the same container get the same rights as the user in the container. In a nutshell, inheritance can be a tricky beast. Be careful. NDS Auditing Tools NDS can be a big and complex beast the fact of the matter is that any good directory service is. Your best bet if you are serious about keeping an eye on NDS is to invest in third-party auditing software. NWAdmin enables you to do searches on various NDS attributes (for example, the "Security Equivalent to Me" search shown in Figure 21.6, which reveals all the users that other users are equivalent to). However, search on every single property from NWAdmin can be cumbersome and/or impossible. I do not recommend Novell's AUDITCON for anything but a very small organization. Figure 21.6. NWAdmin will enable you to do basic property searches, but isn't sufficient for hardcore auditing. 
It's beyond the scope of this chapter to review every auditing tool available, but the following are a sampling of what's available. AuditTrack Manufacturer: WebTrends URL: http://www.webtrends.com/products/adttrk/intro.htm AuditTrack allows auditing and reporting of server access and file manipulation activity. Includes predefined audit rule sets; additional audit instruction sets that define who and what to monitor can also be defined. Options allow for the auditing of files, workstations, users, or user groups. Alarms can be configured to notify the administrator if suspicious file activity is taking place, or if a security breach occurs. AuditTrack also has a custom reporting and graphing facility. AuditWare for NDS Manufacturer: Computer Associates URL: http://www.computerassociate.com/products/auditware_nds.htm A Windows-based advanced NDS reporting and security analysis tool. Generates comparison, analysis, security, and documentation reports. Can locate potentially hazardous stealth users that cannot be seen because the Browse privilege has been filtered out. Can also locate "dangerous" users those who have supervisor privileges but do not meet minimum password requirements. bv-Control for NDS Manufacturer: BindView URL: http://bindview.com/products/bv-Control/NDS/index.html A tool to automate the analysis and documentation of server and NDS configuration; it looks for improperly configured servers and out-of-date or conflicting executables (including EXEs, NLMs, services, and device drivers) that can cause your servers to perform poorly and crash. JRButils URL: http://www.jrbsoftware.com Command-line-based utilities for the rugged individualist who lives for the CLI. Users can use these utilities to perform operations on objects selected via wild cards, container, membership of a group, or via a list in a file. When displaying information, filters can be applied. Can be used for automation of operations such as mass user creation, customization, deletion and for performing security checks. Kane Security Analyst Manufacturer: Intrusion.com URL: http://www.intrusion.com/Products/analystnt.shtml An assessment tool that claims to provide centralized audit data of key Windows NT and Novell NetWare security features. It evaluates password strength, access control, user account restrictions, as well as having a data monitoring facility. Provides report card summaries and more verbose reports. LT Auditor+ Manufacturer: Blue Lance URL: http://www.bluelance.com/ltauditor/default.html A Windows-based intrusion detection/audit trail security software solution. LT Auditor+ supports NT and/or Novell networks. Alerts can be configured to respond to specific events either system-wide or at particular workstations; it also provides off-site paging and email alerts via an SNMP console. Commercial Secure Remote Control Products SecureConsole for NetWare Manufacturer: Protocom Development Systems URL: http://www.serversystems.com/frames/sc_cs.htm A native Win32 application, which provides single sign-on to a NetWare console. It does this by checking a user's current NDS credentials and looking them up in the SecureConsole database. Standard NDS security features such as secure password authentication, single sign-on and intruder lock out are supported. Generates SNMP alerts to one or more network management consoles when it detects attempted unauthorized access or other abnormal server conditions. Secure Remote Console Manufacturer: AdRem Software URL: http://www.adremsoft.com/arcon3/index.htm Offers 128-bit encrypted remote console operations. Access control is available that allows users and groups of users to be permitted specific console commands and server screens. Useful Freeware Most of the following is available from http://www.netwarefiles.com, a repository of a bunch of free or shareware utilities. BURGLAR.NLM A venerable tool, Bart Mellink's BURGLAR.NLM creates a supervisory user of your choice. You need access to the server console and about five free nanoseconds to do this reason #9,285 to secure your server consoles from unauthorized personnel. HOBJLOC.NLM Novell Consulting's answer to crackers who create "hidden" users, that is, users invisible even to administrative users. Finds them so that you can root them out. (Commercial auditing tools do this too, but this is free.) Pandora "The Leatherman" of NetWare cracking tools, written by Simple Nomad and friends. Runs under Linux as well as Win32. Includes offline NDS cracking tools so that you can audit your NDS passwords as well as online denial of service tools. You can find both Pandora and enough NetWare-related documentation to feed a family of four for a month at http://www.nmrc.org. As of this writing, the NMRC is probably your best bet for up-to-date information and code from the underground. REMOTE.EXE Written by TheRuiner, Instantly cracks even the longest of "encrypted" remote console passwords. Want to see some fun? Type "remote encrypt" at the server console, and enter the longest password you can. Then take the remotely encrypted string, and feed it to REMOTE.EXE. 985FF510136420112F1D366A207616903FBEEDEBCDCDDCCCCDCCBDB4CCBCCDCD4BCDBB03 is instantly decrypted to THEREISNOREMOTEPASSWORDSECURITY It's a small and useful demo tool that turns even the most doubting of Thomases into a true believer in REMOTE's lack of real encryption. SETPWD.NLM Developed at the University of Salford in the U.K., P.R. Lees'SETPWD.NLM allows you to set anybody's password from the server console. Is this reason #9,286? | 