Password Problems

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Kathy Ivens

password

Chapter 2 from Managing Windows NT Logons, published by O'Reilly & Associates, Inc.

You can get a running start on preventing password problems with preventive maintenance--designing and implementing password policies that eliminate (or at least reduce) logon distress syndrome.

There are plenty of philosophical musings published about the "proper" approach to passwords, but the truth is that not all companies have the same security needs. If a complicated password strategy isn't necessary, then give it up and relieve yourself of the burden of trying to implement that system. If your physical offices are secure enough that strangers aren't freely helping themselves to keyboards, and if none of your servers are exposed to the Internet or dial-in connections, you can take a less paranoid approach to passwords.

The NT logon process is an elegant approach to password-based security. The NT password model, when combined with intelligent password policies, works well to assure the security of both the local NT workstation and the network logon server.

Logon Process

The logon process begins with the Ctrl-Alt-Delete logon sequence, which hampers poseurs from gaining access. The Ctrl-Alt-Delete combination is called the Secure Attention Sequence (SAS), and it activates the Winlogon process. This key combination avoids conflicts with keystrokes used by applications. In addition, the combination can be implemented at a very low level of the operating system, which helps to protect password information from Trojan horse programs. (A Trojan horse program can present a fake logon function that steals the password and records it, then sends it back to the person who created the Trojan horse.)

After the user enters a username and password, Windows NT hashes the password and sends it to the local machine's Local Security Authority (LSA). The LSA, using the LsaLogonUser API, calls an authentication package. The default authentication package for Windows NT is the MSV1_0 Authentication Package, which uses the records stored in the Security Accounts Manager (SAM) database. The SAM stores two passwords for each user: a LAN Manager-compatible password (for logons from legacy computers) and a Windows NT password (for logons from Windows NT clients).

The MSV Authentication Package has two sections, called the top half and the bottom half. The top half runs on the local machine, and the bottom half runs on the machine that holds the user account information.

The clear text password from the user is passed to the top half of the MSV Authentication Package, which encrypts it and converts it to both a LAN Manager password and a Windows NT password. Then it passes the encrypted password on to either the local Netlogon service (for domain logons where the user enters a domain name in the logon dialog box) or the local lower half (for local machine logons).

For domain logons, the Netlogon service routes the request to the Netlogon service on the appropriate remote computer (an authenticating server). The server returns a 16-bit challenge response called a nonce, which is a randomly generated number. The nonce and the hashed password are merged and sent back to the server (this assures that the communication is from the same requestor). If the returned data is the expected data, the Netlogon service of the authenticating machine passes the request to the bottom half of its own MSV Authentication Package. The bottom half of the MSV Authentication Package queries the passwords in the SAM and compares them to make sure they're identical.

Both the LAN Manager-compatible password and the Windows NT password are stored doubly encrypted in the SAM. The first encryption is a one-way function (OWF) encryption of the clear text password, and that encryption is generally considered unbreakable. The second encryption is an encryption of the user's relative ID. To decrypt it, you would need to have access to the user's relative ID as well as the algorithm for the double-encrypted password. The second encryption is applied totally for the purpose of creating obfuscation. The SAM provides the LSA with the user's Security Identifier (SID), along with the SIDs for any group the user is a member of. The LSA creates the access token that is used for the session.

The OWF version of the LAN Manager password is created by encrypting a constant with the clear text password, using DES encryption. The clear text password is 14 bytes, and the encrypted password is 16 bytes. The first 7 bytes of the clear text password are used to compute the first 8 bytes of the OWF-encrypted password, and the second 7 bytes of the clear text password are used to compute the second 8 bytes of the OWF password.

The OWF version of the Windows NT password is derived using the RSA MD-4 encryption algorithm. RSA MD-4 computes a 16-byte summary (called a digest ) of the string of clear text password bytes.

If the security checks fail, the user is denied permission to log on.

Password Policies

The password policies you establish for your organization can either strengthen or compromise the security built into Windows NT password functions. Potent policies add more security but carry a higher risk of user error. Flimsy policies make life easier for users (and, by extension, for administrators) but may jeopardize the security of your company's data.

Every user account on your network should have a password, even though all the Microsoft client operating systems permit user logons with null passwords. Having determined the need for passwords, you have to decide on password policies.

Global Password Policies

Password policies for the domain are set by opening User Manager for Domains and choosing Policies ? Account from the menu bar. Most of the options in the Account Policy dialog box are self-explanatory. However, it may not be obvious that some policies are either mutually exclusive or mutually dependent:

If you permit password changes immediately, you should not select the option to keep password history.
If you permit blank passwords, you cannot set a minimum password length.
If you specify a number of passwords that must be used before a user can employ a previous password, you must also specify a number of days in the Minimum Password Age section of the dialog box.

Table 2-1 specifies the choices available for those policy options that provide ranges.

Table 2-1 Ranges Available for Entering Password Options

Option	Available Range
Maximum Password Age	1-999 days
Minimum Password Age	1-999 days
Minimum Password Length	1-14 characters
Remember Passwords	1-24 unique passwords
Bad Logon Attempts	1-999 attempts
Reset Count After	1-99,999 minutes
Lockout Duration	1-99,999 minutes

The mutually exclusive policies have a hidden agenda; one side is always easier to implement. The cost of that ease is, of course, the level of security. While it's tempting to say that it's perfectly all right to opt for easy implementation if the domain is physically secure and spies (government or industrial) don't find your data worth much, I can't say it. Too many administrators underestimate the risks of users within the company getting into computers that have secure data they shouldn't see (such as payroll data).

If you establish policies that require periodic password changes, minimum password lengths, bans on using previous passwords, and other similar requirements, you're going to spend some time dealing with user complaints and problems. However, I've found that once users learn that the company is serious about security and they have to live with the policies, they adjust nicely.

Your password policies should extend beyond the features and functions available in Windows NT by making password rules clear to all employees. Create and distribute a policy statement about the company rules for passwords. For example, what are the permitted methods for writing down passwords? You should explicitly state that if a user needs to make a note of a new password, the note cannot also contain the logon name, cannot be taped to the monitor, cannot be kept in the top drawer of the desk, and so on. You should have explicit rules about penalties for sharing passwords with other users. Be sure users are notified that administrators may be auditing logons.

Lockouts

The options you select regarding lockouts are a matter of your own judgment and preference. There is no happy ending for the saga of the user who continues to enter the wrong password innumerable times. It's a mysterious behavior pattern, but it happens often. You can either let the user amuse himself for hours in this manner, or lock him out after some specified number of bad attempts. Either way, eventually the user will call you for assistance, and the lockout option just makes it sooner rather than later. Having opted for lockouts, you have two choices for handling locked out users:

The lock is permanent, which means an administrator must specifically unlock the user.
The lock is removed and reset after a period of time that you specify, so the user can try again.

Most of the time, you'll find that configuring lockouts for a specific duration is a waste of time (this option is for optimistic administrators). The user is probably not going to remember his password just because some period of time has elapsed.

To unlock a user, open User Manager and double-click on the user's listing. In the User Properties dialog box, deselect the Account Locked Out check mark.

Because unlocking a user does nothing to improve his memory, the unlocking process usually includes entering a new password for the user. Enter and confirm a simple password and tell the user what it is. Then reset the user's configuration options so that he must create a new password on the next logon. The figure you specify in the lockout duration must be as large as, or larger than, the figure specified for Reset Count After.

The account lockout policy works only for standard logons. If a user is trying to gain access from a workstation that was locked by pressing Ctrl-Alt-Delete | Lock Workstation, or is trying to get past a password-protected screen saver, bad password entries will not cause a lockout.

Forcing logons to change passwords

The option to force users to log on in order to change a password is deselected by default. If you turn it on, a user must enter her current password in order to create a new one. This provides an additional level of security, but it can create extra work for administrators. If a user logs on after her password has expired, she's unable to create a new password because she can't log on. You'll have to create the password for her.

User Password Policies

There are some password options you can specify on a user-by-user basis. Most of the time, you configure these options when you're creating the user. You can change existing user password options by double-clicking the user's listing in User Manager to open the User Properties dialog box.

Tip Unfortunately, Windows NT 4.0 does not permit you to set user password options on a group-by-group basis. This would be very productive because password policies are (or should be) related to the level of access.

Forcing a new password at next logon

The option forcing the user to change the password at the next logon is selected by default when you create a user. After the user logs on and completes the password change, the check mark disappears from the checkbox. If you re-enter the password in the user's Properties dialog box (because the user forgot his password or because you had some other reason to change the password in User Manager), the check mark reappears in the checkbox. You can leave the check mark or deselect it, depending on the circumstances. You cannot use this option if you've configured account policies so that a user is forced to log on in order to change the password. It's possible for an administrator to generate passwords for users, but it's not advisable unless you automate the process by using a software application--it's just too much work. Windows NT 4 doesn't provide any generated password features, but there are third-party applications that create password files.

Prohibiting password changes

The option specifying that the user cannot change the password is designed for accounts that are shared by multiple users. Many companies have workstations at which any user who knows the password can log on, perhaps in the accounting department where anyone who works on accounts payable can use the computer that has the checks printer attached. If you specify that a user cannot change the password, you cannot enable the mutually exclusive option to have the user change the password at the next logon. It's also a good idea to apply this option to the Guest account.

Eliminating password changes

The option to let the password live forever (Password Never Expires) carries a great deal of potential danger. Its purpose is to make it easy for you to create special accounts (print management, backup, and so on), but if you're trying to maintain a secure system, those account types aren't a good idea anyway. The only set of circumstances in which I've ever agreed to let an administrator use this option is within a domain site that has no incoming trust relationships from other sites in the organization. Small, physically secure sites (such as small branch offices) might reap some benefit from this password policy because it's free of potential password problems and requires less administration.

Disabling accounts

Disabling an account makes it inactive; it can't be used to log on and any attempt to do so will produce the error message "Your account has been disabled. Please see your system administrator."

Disabling an account is useful for several account types:

The Guest account, if you don't want guest logons
Template accounts
Users who are away from the office for an extended period

Remember that the disabled account is checked only at the logon target. For example, if you disable an account on the workstation, but the logon process is targeted for the domain, the disabled workstation account is ignored and the user logs on to the domain without error.

Good Passwords

Most of us let users create their own passwords, and it's a good idea to distribute guidelines for this task. You can present your definition of a good password, along with some suggested rules (you could call them real rules, but some are difficult to enforce).

The best password is one that's unassociated with the user because a clever intruder who knows the user could possibly crack such a password. On the other hand, a password that has no association for the user may be eminently forgettable. Users solve this problem in a number of amusing ways, ranging from writing their passwords on post-its that they affix to their monitors to leaving notes in an unlocked desk drawer.

A good password contains alphabet characters, numbers, and special characters (, . ; : * % & !), or at least two of those three. If users have difficulty remembering such an involved password, another suggestion is to merge unrelated adjectives and nouns, such as funnyclock or smartbottle. It's even more effective to use that scheme if you place a number or special character between the words.

NT passwords are case-sensitive, and while this fact can bring some additional complexity to a password, it's another one of those little touches that users have a problem remembering.

The longer the password, the harder it is to guess, so you might want to require a six- or seven-character minimum length (set the minimum in the Account Policy dialog box of User Manager for Domains). If you choose to permit null passwords, you cannot set a minimum password length.

Tip Intruders sometimes use software that helps them crack passwords. Get yourself a copy of one of these programs and test your passwords (run surprise quizzes at various workstations). If any password is cracked within a few seconds or a minute, tell the user to create a new, more complicated password.

Changing Passwords

NT 4 has a password expiration policy available in the Account Policy dialog box, and you can use it to force users to change passwords at an interval you feel comfortable with. In addition, you can mandate how many password changes must be made before a user can reuse a previous password (the maximum is 24). Incidentally, if you use this option, it's a good idea to configure your password policies so that immediate changes are not permitted (deselect Allow Changes Immediately).

It's not always necessary to change passwords at regular intervals, but there's a rule of thumb that says the higher the level of access, the more frequently passwords should change. Unfortunately, NT 4 doesn't permit password expiration policies to be set for groups, so you have to find a duration that keeps your system safe without driving all your users crazy.

Regardless of whether or not you opt to configure your system for mandated password changes, there are situations in which you should change passwords immediately. For instance, when a user leaves the company or transfers to another site, change the password if the user account remains in the system for some reason.

NT begins notifying users 14 days before the date of the password expiration. You can change that interval in the registry at HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. Create a REG_DWORD data item named PasswordExpiryWarning. The data you enter in the item is the number of days before the password expiration date that the first reminder appears.

When the notification begins, users are given the opportunity to change the password immediately without waiting for the expiration date. The user must enter the old password and then the new password, following which a message displays to announce the password has been changed successfully. When a user logs on with an account whose password has expired, a dialog box appears to insist that the user change the password.

For some Windows 95 users, the procedure described in the previous paragraph is followed by an error message: "The Domain password you supplied is incorrect, or access to your logon server has been denied." Clicking OK redisplays the logon dialog box, and entering the new password works.

What is happening is that after the logon request is received by the Windows NT domain controller, and the password change has been written to the domain controller, a new logon request is issued. However, the original password is sent to the domain controller instead of the new one.

This is a bug in the version of the Windows 95 network provider DLL (MSNP32.DLL ) that shipped with the original retail versions of the operating system and the OEM versions through OSR2. The correct version of the file is MSNP32.DLL Version 4.00.951. The file has the date 8/20/96 and is 67,584 bytes. You may be able to find it on a Windows 95 computer with a very late version of an OEM installation. If not, you can call Microsoft support for information about obtaining the file. In the meantime, your Windows 95 users can probably live with the requirement to re-enter the logon after a password change. However, if you have a lockout policy that kicks in after one bad password entry, the problem becomes serious. Incidentally, the early version of MSNP32.DLL also causes problems with Strong Passwords (covered later in this chapter).

For Windows NT clients, there's a potential problem with the process of changing a password that you may encounter if you haven't installed SP3 or later. When the password expiration warning appears, including the option to change the password during the current logon, most users take advantage of the opportunity to change the password before it expires. If a user chooses Yes to change the password and then cancels the process before it's complete, the logon proceeds normally. The reminder will appear at the next logon. However, entering the password for a protected screen saver fails, as does the password used to open a workstation after it's locked via the Ctrl-Alt-Delete sequence. The workstation is totally locked down, and there's no remedy except to log on to the workstation with a different administrative account. Install SP3 or issue a reminder to users that they shouldn't cancel the change password process midstream.

Hiding the Last Logged-On User

You gain some additional security by removing the name of the last user who logged on to the computer from the logon dialog box. Anyone who tries to log on must know a valid username and its accompanying password. To accomplish this, make the following change to the registry:

For Windows NT, go to HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. Add a new data value entry of type REG_SZ to this subkey named DontDisplayLastUserName. Set the value to 1.
For Windows 9x, go to HKLM\Network\Logon. Add a new data value entry of type DWORD to the subkey named DontShowLastUser. Set the value to 1.

Tip Don't put the apostrophe in dont. Every time I get a call for help about this feature not working, there's an apostrophe in the registry entry.

Automating Logons

Sometimes there's an advantage to an automated logon process. The most obvious value is that a user who doesn't have to enter a password won't have a "forgotten password" problem. There's also a good argument for using automated logons on workstations that are always used by the same person and have no important information on the local drive. Workstations or servers that perform services (print server, RAS server, etc.) and aren't assigned to a user are also candidates for automatic logons.

When the logon process is automated, users just turn on the computer and wait for the desktop to appear. There's no need to use the Ctrl-Alt-Delete sequence to display the logon dialog box, and in fact, the logon dialog box never makes an appearance.

Automated logons are established for specific users, and before enabling autologon, you must make sure the user's configuration is appropriate for this feature. In User Manager for Domains, double-click the user's listing and make these changes:

Select Password Never Expires (deselect all other password options).
Enter and confirm a new password so you know the password (if you already know the user's password, you can skip this step).

Then log on to the computer of the user for whom you're enabling automatic logons, using that user's logon name.

For a computer running Windows NT, go to HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. When you select this subkey, you should see the data item DefaultUserName with the name of the user for whom you're creating the automatic logon. Add a new REG_SZ data item named AutoAdminLogon and give it a data value of 1. Add another REG_SZ data item named DefaultPassword and enter the user's password as the data.

For a computer running Windows 9x, use the same steps for the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Winlogon.

A password is required for automated logons. If you make the registry changes for a user with a null password, the first automated logon works, but after that the process fails (the logon dialog box appears). The absence of a password causes the operating system to change the Boolean data for AutoAdminLogon from 1 to 0 after the first logon.

You cannot use automated logons if you've enabled Legal Notice captions and/or text during logon. This feature requires the user to click OK, and there is no method of automating that step. You also cannot enable automated logons if you've implemented the feature to hide the name of the last logged on user. These registry entries are mutually exclusive.

To bypass the Autologon feature, hold down the Shift key during the boot process.

Strong Password Functions

NT 4 Service Pack 2 (and later) includes a feature that lets you force users to create passwords that are designed to enhance password security. Commonly referred to as "strong passwords," this feature enforces rules when users create passwords. With strong passwords enabled, password-guessing is more difficult and "dictionary attacks" are less likely to succeed.

Enabling the Strong Passwords Feature

During installation of the service pack, the file passfilt.dll is installed in the %SystemRoot%\System32 directory. (Sometimes the file doesn't make it to the directory, so you may have to find it in the SP files and copy it.)

To enable a strong password policy, you must make a registry change that references this file. On the PDC, go to HKLM\System\CurrentControlSet\Control\Lsa and create a new subkey named Notification Packages (the new key is a REG_MULTI_SZ type). Open the key and add the data value PASSFILT. Reboot the server.

If you find a Notification Packages subkey already in the registry, it may have a data value of FPNWCLNT, the service that manages password synchronization with Novell NetWare servers for File and Print Services for NetWare. Add the PASSFILT data item below it, don't replace it.

Tip Because changes to user accounts are handled by the PDC, it's not necessary to make the registry change on any BDC in the domain. However, I've had to promote BDCs to PDCs on a number of occasions, so I advise you to enable strong passwords on the BDCs also, just in case.

When you enable strong passwords via passfilt.dll, the following rules apply when users create passwords:

Passwords must contain at least six characters, and the character string must contain at least three of these four character types:
- Uppercase letters
- Lowercase letters
- Numerals
- Nonalphanumeric characters (, . ; : * % & !)
Passwords may not contain the user (logon) name.
Passwords cannot contain any portion of the user's full name.

These rules are specific to the code in Microsoft's passfilt.dll file. Nothing is configurable; you must live with the rules that are hardcoded in the file. However, you can write your own rules and save them to passfilt.dll or to another DLL file. If you use a different DLL file, you must copy it to the %SystemRoot%\System32 directory and change the registry entry to point to it. If you'd already added passfilt to the registry, replace the registry data with the new filename (you cannot have both entries). You can find information on the strong password feature, including sample code, in the Microsoft Win32 SDK Version 4.0.

Working with Strong Passwords

Change the Windows NT password policies for your domain so they work in concert with strong passwords. For example, specify a minimum length of 6 characters, which automatically meets the requirements built into passfilt.dll and also subverts the ability to have null passwords.

Additionally, you should give some consideration to the settings for password uniqueness. Users seem to find it difficult to invent strong passwords, and some administrators have found it helpful to let a user repeat a password after one or two changed passwords. The rationale is that because the passwords are difficult to hack, it doesn't harm security efforts to allow users the right to use an old password quickly. On the other hand, administrators who enable the strong password feature do so because they want to apply the maximum password security features available. Forbidding repeated passwords until a large number of intervening passwords are used certainly tightens security. I think there's merit to both arguments, and my advice is to go for the strongest security measures at first. If you run into problems because users are having difficulty coming up with a series of strong passwords, you can lower the specified number of remembered passwords or lengthen the interval between forced password changes.

Strong password rules are only enforced when a user creates a password over the network. The passfilt.dll filter isn't active when an administrator is writing directly to the SAM, so you can open User Manager for Domains and enter a user password that does not qualify as a strong password (let's call it a weak password). This gives you the ability to enforce strong password rules on a user-by-user basis. If security is of enough concern to warrant the implementation of strong passwords, use this bypass sparingly, applying it only to users with secure workstations and/or low access rights.

If you enter a weak password for a user in User Manager for Domains, the ability to use a weak password disappears when the specified time for password changes has elapsed. When the user is required to enter a new password, the strong password rules are in effect. The only way to let the user continue to use an assigned weak password is to prevent password changes by selecting Password Never Expires in the user's Properties dialog box.

When a user creates a new password that fails to meet the requirements for your strong password policy, the error message may be confusing. The most common specious error is "You do not have permission to change your password." After you check the User Properties dialog box to make sure you haven't prevented the user from changing passwords, it's safe to assume this is a strong password issue. When the user enters a new password that matches the strong password rules, the procedure works.

If you decide to disable strong passwords, just remove the registry entry you created (removing the data entry is sufficient; you don't have to remove the key).

Dial-in Users

If users log on to your server via a dial-in connection, you need to configure the security and authentication procedures. The security consideration is whether you permit callers to access only the server or to use the server to get to the entire network. The authentication choices are wider.

To set the configuration options, open the Network applet in Control Panel and go to the Services tab. Select Remote Access Service and click Properties to open the Remote Access Setup dialog box. Click Network to display the Network Configuration dialog box.

Server-Only Access Versus LAN Access

In the Server Settings section of the dialog box, choose the protocols dial-in users can employ. The choices are NetBEUI, TCP/IP, and IPX, and the choices are not mutually exclusive. Click the Configure button for each protocol you permit, and either limit the dial-in user to the resources on the RAS server, or let the server act as a bridge to the network.

Dial-in Encryption Settings

The Encryption settings section of the dialog box lists the available password encryption options, which are mutually exclusive.

Clear text

The first encryption choice is "Allow any authentication including clear text." This is the option that supports Password Authentication Protocol (PAP), which uses unencrypted clear text password authentication. Microsoft supports this option to provide interoperability with third-party PPP clients. It's the least onerous, but also least secure, option.

CHAP

The choice named Require Encrypted Authentication permits a connection to use any authentication requested by the client (except PAP). Essentially, this is Challenge-Handshake Authentication protocol (CHAP).

NT supports several encryption algorithms for CHAP authentication:

RSA MD4 (which is really MS-CHAP, discussed next).
DES, which is used by RAS clients using Windows for Workgroups and is supported to provide backward compatibility.
SPAP, which is Shiva's Password Authentication Protocol. It's used to support dial-in logons by Shiva clients. Even though the name includes PAP, this is CHAP, not a clear text password authentication scheme.

RSA

RSA is an encryption and authentication system that uses an algorithm developed in the 70s by people named Rivest, Shamir, and Adleman. Their web site, https://www.rsa.com/ , is a good place to visit if you have any interest in learning more about security via encryption.

The RSA encryption is accomplished by multiplying two large prime numbers and then using the resulting data to derive a set of two numbers: one number is the public key and the other is the private key. (After those keys are determined, the original prime numbers are no longer needed and are discarded.)

Both the public key and the private key are needed for encryption/decryption of data, but the private key is never sent across the communication channel. The sender gets the public key from a central administrator and encrypts data using that public key. On the receiving end, the data is decrypted using the private key.

For password authentication under RSA, the client sends a public key, then uses its private key to encrypt a digital certificate. The receiver uses the public key to decrypt and authenticate the certificate.

MS-CHAP

The choice named Require Microsoft Encrypted Authentication is MS-CHAP, Microsoft's rendition of the RSA MD4 standard. It provides the most secure encryption algorithm that NT supports. Both Windows NT and Windows 98 clients can use it to connect to an NT RAS server.

If all your dial-in users are dialing from an NT computer, you can take advantage of the additional security available with data encryption. Click the Require Data Encryption checkbox to encrypt all the data coming over the wires.

MD5-CHAP

SP3 added the ability to support dial-in clients that request PPP MD5-CHAP authentication (the motivation for the change was to support non-Microsoft dial-in clients). Support is enabled by a registry change and is specific to the RAS server on which the registry is changed. The information about the MD5 account is stored only in the local registry and cannot be integrated into the account database you access through User Manager.

To create support for MD5 clients, open a registry editor and go to HKLM\System\CurrentControlSet\Services\RasMan\PPP\CHAP. Add a new key below the CHAP key named username. Add a subkey under that named pw, and enter the user's password as the data for that key (REG_SZ). Repeat this for every MD5 user and password that is served by this server. You are, of course, adding a clear text password to the registry so it's important to secure the registry against prying. See "Securing the Registry" in Chapter 6, Controlling User Activity.

DES

The Data Encryption Standard is a popular data encryption procedure that uses a private key so difficult to break that the U.S. government has ruled that it cannot be exported to other countries. There are more than 72 quadrillion possible encryption keys that can be used for DES. With DES, both the sender and the receiver must know and use the private key.

Microsoft expects to provide full MD5-CHAP support in the near future, so all this work for rather limited support won't be necessary.

The Windows NT RAS client supports MD5-CHAP encryption so that Windows NT PPP clients can connect to third-party PPP Servers that use MD5.

NetWare Connections

Many corporate networks mix Novell NetWare servers within a Windows NT network. In some cases, companies maintain NetWare servers for a period of time as they complete the migration from NetWare to NT. Other companies retain NetWare servers permanently for file and print services. In this mixed environment, Windows clients can connect to a NetWare server through an NT gateway or access the servers directly.

Gateway Service for NetWare

The Gateway Service for NetWare (GSNW) links every workstation connected to an NT server to all the NetWare drives connected to that server. GSNW is commonly used for occasional (rather than full-time) connections to a NetWare server.

The Awful Truth About GSNW

The reason GSNW isn't a useful full-time connection is that its performance level is just awful. It provides a single highway lane to the NetWare resource and then permits a whole lot of vehicles to use that lane. The traffic moves at the pace you'd expect, or even slower than you'd expect. This is the quintessential definition of the phrase "bandwidth problem."

You can configure GSNW for unlimited users (there's actually a limit, but it's in the billions so there's little chance you're going to bump into it). If those users need to spend any time performing tasks on the NetWare share, they're going to be extremely unhappy.

Adding to the problem is the fact that GSNW must act as a translator between two operating systems that use different and incompatible protocols to communicate with clients. NT uses the Server Message Block (SMB) protocol and NetWare uses NetWare Core Protocol (NCP). On the way out (from the NT server to the NetWare server), GSNW translates SMB calls to NCP calls. On the way back, it reverses the process. The translation procedures are time-consuming.

Use GSNW for quick and easy tasks, perhaps fetching a copy of a file, looking at a document, or sending a document to a printer.

The single advantage of GSNW is that Microsoft clients don't need any other client network software (such as a redirector or NWLink). They merely need the protocol necessary to connect with the NT server. In fact, to avoid conflicts, you should remove redirectors from the clients that use the gateway.

GSNW overview

The NetWare server sees only the NT server, which it sees as a NetWare client. Microsoft clients see the NetWare server as a resource on the NT server.

The NT server handles client logon validation and passes users through to the NetWare server. All users who gain access to the NetWare server through the gateway have identical rights to that server; there is no opportunity to create individual permission levels for clients.

During the first logon to the NT server after installing GSNW, you're asked to choose a preferred NetWare server for the gateway. This is the first step in configuring your GSNW services. When you enter the name of the NetWare server, GSNW attempts to log you on, using the account and password you used to log onto the NT server. If that account name and password don't exist on the NetWare server, the logon fails.

If you logged on to the NT server as Administrator (a common scenario), you cannot successfully log on to the NetWare server, because there is no account named Administrator. On NetWare 2.x and 3.x servers, the equivalent administrative account is named Supervisor. (On a NetWare 4.x server running bindery emulation, there's a virtual Supervisor account.)

On NetWare 4.x, the supervisory account is named Admin. Many NT administrators who are using GSNW to access a NetWare 4.x server create an account on the NT server named Admin and use the password for the Admin account on NetWare. (Apparently it's easy to remember to type Admin if you're used to typing Administrator.)

Configuring GSNW

You should set up the accounts, passwords, and rights you need before configuring GSNW.

You need to set up two user accounts on the NetWare server. The first is an account with full administrative rights. You use this to accomplish setup and configuration options for the gateway. Create the account and password so that it matches your logon for the NT server (such as the Admin account mentioned previously).

The second user account is the account gateway clients use. Using the first (administrative) account, establish this account with the following steps. (For NetWare 2.x and 3.x, use SYSCON to create the account. For NetWare 4.x, use NETADMIN.)

Create a username that reflects the role of this account, such as GWUSER or GWADMIN.
Create a home directory, or use an existing one.
Create a password.
Remove any account restrictions that may exist by default.
Be sure the account is enabled by default.
Ensure there are no time restrictions for logging in.
Set the rights to the NetWare filesystems you need for the gateway.
Set the Allow User To Change Password option to No. (This isn't a required step; I just think it's a good idea.)

Tip NetWare does not support spaces in account names. If you want to use GW USER, you must enter it as GW_USER.

You need a group on the NetWare server named NTGATEWAY. Don't invent a name you like better, this is the only name you can use--it's hardcoded into GSNW. This group needs rights adequate to access the resources the gateway clients need. Follow these steps:

Create the group.
Add the user you created in the previous steps to the group (GWUSER, for example).
Give the group sufficient rights to the appropriate NetWare directories.

You do not need user accounts for the clients who use the gateway, because they never log in to the NetWare server. NetWare sees only the NT server.

Now you can configure GSNW. To accomplish this, log on to the GSNW NT server as an administrator and open the GSNW icon in the Control Panel. In the Gateway Service for NetWare dialog box, click Gateway to bring up the Configure Gateway dialog box. Enable the gateway, then configure the NetWare share as follows:

In the Gateway Account box, use the NetWare username you created on the NetWare server (the account that's a member of the NTGATEWAY group).
In the Password box, enter the password you created on the NetWare server.

The NT server automatically uses this account to access the NetWare server. The rest of the options on this dialog box aren't related to authentication issues, so I won't discuss them in detail (they're self-explanatory anyway). However, here are some guidelines:

If you have DOS or Windows 3.x clients, you must use the 8.3 naming convention for shares.
You can set a user limit for the gateway or let an unlimited number of users through. The common reason for limiting users is load balancing, which assumes you have other NT servers running GSNW.
The Use Drive drop-down list lets you map a drive to the share. Because mapped drives can be reconnected on startup, this is the way to automate the connection to the NetWare share when this NT server boots. That automation means, of course, that clients have access to the share as long as the computer is up and running--it doesn't require a user logon to activate the share.

GSNW uses the last available drive letter to map the share, so drive Z: is assigned to the first NetWare share you create. The mapping is local to this NT server and has no effect on the clients who use the server to get to the share. Clients see the share as a UNC (for instance, \\Ivens\Sys), and users can create their own mapped drives if they wish.

You can create as many shares as you need. Then you must set permissions for each share. Select the sharename you want to work with and click the Permissions button. The current permissions display in the Access Through Shares Permissions dialog box, and you should see that the Windows NT group Everyone has Full Control permissions (this is the default). If you haven't enabled the gateway service, the Permissions button is grayed out.

You can reduce the permissions to match your security policies. The available permissions are No Access, Read, Change, and Full Control. Don't downgrade the permissions if the change will compromise the clients' ability to get work done.

The permission level you set applies to every client that accesses this share through this gateway. If you want a mix of permissions for clients, you must create a different share for each set of permissions and assign NT groups to the share.

It's important to understand the pecking order for permissions:

The trustee rights settings you configured on the NetWare server are primary.
If the share permissions conflict with the trustee rights, the trustee rights win.

That means if you set directory rights of Read and File Scan on the NetWare server, clients will not be able to modify, create, or delete files even though you set Full Control permissions in the GSNW dialog box.

The processes of installing GSNW, enabling the gateway, configuring the NetWare share(s), and mapping drives to the shares completes the installation of all the files you need. Even the NetWare redirector files are copied to your NT server's drive. All the installed services are set for Automatic Startup, so restart the server to give your Windows users access to NetWare servers. When they take advantage of the gateway, their usernames, passwords, and permissions are those you established during configuration.

If you covered all the bases and established a well-thought-out configuration, the amount of time you have to spend on password errors should be negligible. However, there are some possible authentication problems you need to be aware of.

Problems in NetWare Startup.ncf

If a user on a computer running NT connects to a NetWare server with the net use command and sees the error message "System Error 86 - the specified network password is not correct," the problem lies with the Startup.ncf file on the NetWare server.

When you configure a NetWare server that's participating in a mixed environment with NT, you must make sure that NetWare does not use checksums to examine the incoming IPX packets from the NT client. Startup.ncf contains a line that configures the use (or non-use) of checksums, to wit:

SET ENABLE IPX CHECKSUMS=X

where X is:

0 Checksums are disabled.

1 Checksums are used if enabled at the client.

2 Checksums are required.

Windows NT does not use the checksum field in an IPX header, so when NetWare parses the header it won't find what it's looking for. As a result, NetWare rejects the packet. Be sure the checksums line has a value of 0 or 1.

File and Print Services for NetWare

In a way, FPNW is the opposite of GSNW. You add FPNW to an NT server to let NetWare clients access that NT server as if it were a NetWare server. FPNW is an add-on available from both Novell and Microsoft. The Microsoft version is bundled with Directory Service Manager for NetWare (DSMN).

FPNW is useful during migration from NetWare to Windows NT and is equally useful if you plan to operate a mixed-platform environment for a long time.

Tip There is a known memory leak connected to FPNW, and you should configure a Performance Monitor to keep an eye on PrivateBytes for Nwssvc.exe. If you find the counter increasing rapidly, you'll probably see an Out Of Virtual Memory error message eventually. The problem arises when there is an error response to the call BindLibGetInfo. Upon an error return, the memory block is not released. Microsoft is working on a fix, but at the time of this writing, it was not released. As with all memory leaks, rebooting solves the problem.

The authentication issues with FPNW aren't complicated, because there's not an enormous change from the NetWare features you're used to. However, because FPNW runs on Windows NT, there are some "gotchas" as a result of the way non-identical functions and features are translated between the operating systems.

FPNW configuration

When you install FPNW, a service account is created automatically. The account is a member of the Administrators group. There are three important caveats connected to this account:

You cannot delete or disable the account.
You cannot change permissions or privilege levels for the account (by this, I mean you cannot downgrade the levels).
You cannot change the Log On As specification in the FPNW services (in the Services applet of the Control Panel) to any other account.

If you install FPNW on any additional domain controllers in the same domain, you must use the same password for the service account.

In addition, there's a Supervisor account installed during FPNW configuration, which you'll use to administer FPNW. The account policies in effect on the NT server control the password you enter for this account.

Configuring users

When you install FPNW on an NT server, users who run NetWare client software can access the files and printers installed on that server. These clients are considered NetWare-enabled user accounts by the NT server, and you create and manage them with User Manager for Domains.

From the NetWare client's point of view, logging on is performed in the same manner as if a connection to a NetWare server were being made. The client sees the server as a NetWare server, and a successful logon means the user is authenticated for both NetWare and Windows NT. A Windows client sees the server as an NT server.

When you're working with NetWare-enabled accounts, you're also working with NT rights and privileges via NT groups. NetWare and NT both have categories for administrative accounts that provide a high level of rights, but the implementation differs between operating systems.

NetWare has system-defined user types, and if you want to give users the rights and privileges built into a system-defined type, you use an equivalence function. For example, you can give a user the rights of a Supervisor by making him a "Supervisor Equivalent" user. NetWare system-defined rights can't be altered.

Windows NT has system-defined groups, and adding a user to the group grants the group's privileges to the user. Group rights and user rights can be altered.

Configuring NetWare-enabled accounts

I'm assuming you already know how to create and maintain an NT user account in User Manager for Domains, so I'll discuss the FPNW-specific issues for account management in this section.

With FPNW installed, the User Properties dialog box contains two additional elements:

A checkbox option named Maintain NetWare Compatible Logon
An icon named NW Compat

The NW Compat icon is grayed out until you select the Maintain NetWare Compatible Logon option to enable NetWare-compatible functions for the current user.

Click the NW Compat icon to open the NetWare Compatible Properties dialog box, which handles NetWare issues. Then use the options described here to complete the user's configuration:

NetWare Compatible Password Expired

Select this option to force the user to change her password at the next login from a NetWare client.

Warning: If you force a user to change the password at the next login, be sure your account policies do not require the user to be logged in to change the password. Deselect that option on the Account Policy dialog box in User Manager for Domains if you'd opted to use it.

Grace Logins

Selected by default, the Unlimited Grace Logins option allows the user to log in forever with an expired password. You can tighten up the password policy by choosing the Limit Grace Logins option instead and specifying a number in the Grace Logins to Allow field. The user cannot continue to log in with an expired password after that number is reached. The Remaining Grace Logins text box keeps a countdown on the number of "logins to go." However, having said that, I'll warn you that after the user changes the password, NT does not reset the password grace logon count. You must perform this task manually until Microsoft announces a fix for this problem (at the time of writing, Microsoft had acknowledged the problem but not yet released a fix).

Concurrent Connections

By default, the user can have an unlimited number of simultaneous connections. You can limit the number of concurrent connections by selecting Allow and specifying a number.

Edit Login Script

Don't use this feature. Clicking this icon opens the Edit Login Script dialog box. The login script in question is the user login script (FPNW supports the NetWare feature of permitting both a system login script and user login scripts). Instead, use a text editor (or Notepad) to open and edit the user login script. There are lots of problems reported by administrators who used the dialog box to make changes to the script. You can find the user login script, named NET$LOG.DAT, in the \Sysvol\Public directory.

The other icons on the User Properties dialog box work the way they do for NT users, but, once again, the installation of FPNW adds elements to some of the dialog boxes attached to the icons. Other icons include:

Profile icon

The User Environment Profile dialog box has a text box for the NetWare Compatible Home Directory Relative Path. The account can have both a NetWare Login script and a Windows NT Logon script. The data you enter in the User Profiles section and the Home Directory section apply when this user logs on from a Windows client.

Hours icon

The Logon Hours dialog box offers settings in half-hour increments, which is the NetWare standard (Windows NT uses hourly increments).

Logon To icon

The Logon Workstations dialog box has NetWare-specific options at the bottom. The option User May Log On To All NetWare Compatible Workstations is selected by default. You can limit logons to specific workstations by deselecting that option and adding specific NetWare client workstations to the list.

Account icon

FPNW makes no changes to the Account Information dialog box.

Dialin icon

FPNW makes no changes to the Dialin Information dialog box.

Managing passwords with FPNW

When you install FPNW on an NT server, the Security Accounts Manager (SAM) database is modified so it can store the FPNW password. When a user logs on using a domain account, FPNW queries the domain controller to validate the FPNW password. If the domain controller's SAM database has not been updated, the user is denied access. You can remedy this by installing FPNW on all the domain controllers in the domain. You do not have to activate the service; it's the installation process that modifies the SAM.

You can alternatively install Microsoft's FPNWAUTH program on every domain controller to modify the SAM.

When you're creating a new account under FPNW, the password you assign for NetWare is also automatically assigned to NT logons. If you configure an existing account for NetWare, the existing NT password is automatically assigned as the FPNW password. If you change the account password in User Manager for Domains, both passwords are changed. This synchronization is terrific because it doesn't matter whether the user logs in from an NT client or a NetWare client, entering his or her password works every time.

However, users change passwords, either because they want to or because there's an expiration date approaching. This can destroy the automatic password synchronization. The results of a password change differ by client platform, as follows:

Windows NT 4.0 and 3.51 clients

If a user is logging in as an NT client, he can use the Ctrl-Alt-Delete combination to display the Windows NT Security dialog box, which has a Change Password option. This password change is accepted by both the NT server and FPNW, so the password remains synchronized.

Other Windows clients

If the user is running Windows 9x, 3.x, NT 3.5, or DOS, using the appropriate password change function (which varies by platform) changes only the NT server password. The passwords are out of sync unless the user also invokes the Setpass.exe or Chgpass.exe utility to change the FPNW password.

NetWare clients

If a user logs on as a NetWare client, using the Setpass.exe or Chgpass.exe utility usually changes both passwords.

When a user has the same account name, but different passwords, for Windows NT and NetWare, you may experience some annoying workstation behavior. After the NT logon, Windows NT tries to log the user on to the NetWare server using the same password. This, of course, doesn't work, and eventually the user is prompted to enter a NetWare password. If the user cancels the NetWare logon (perhaps he or she isn't planning to work with the software installed on the NetWare server), Windows NT tries the NT password again. Unfortunately, Windows NT doesn't give up, and a tenacious effort begins for which there is no end. The user, meanwhile, sees an hourglass on the monitor and can't accomplish anything. There are two ways to avoid this problem:

Make sure the Windows NT and NetWare usernames and passwords match.
If the passwords don't match, instruct users to continue the logon to the NetWare server even if they aren't planning to work on the NetWare server.

Obviously, the first option is preferable, and it's also the only one you can enforce.

Using Setpass and Chgpass

During the installation of FPNW, the files Setpass.exe and Chgpass.exe are copied to the \Sysvol\Public directory of the NT server. Invoking these files provides the same services as the Novell NetWare utilities of the same name. When users enter the commands, they're calling a Microsoft program, not a Novell program (but that's transparent to the user). Either command works to create a password.

Setpass.exe and Chgpass.exe (as well as Login.exe), require RPC support files. Rpc16c1.rpc, Rpc16c6.rpc, and Security.rpc are installed automatically in the directory \Sysvol\Public. If users copy the password utility programs to their local hard drives, the .RPC files must reside in a directory in the search path.

Setpass and Chgpass always change the FPNW password, and, if the conditions are right, the NT password is changed simultaneously. The right conditions are the following:

The PDC of the domain where the user's account information is located must be running Gateway Service for NetWare in addition to FPNW.
The user's client computer must have the ability to connect to the PDC with the IPX/SPX protocol.

This is not an either-or list; both statements must be true.

If client computers are running redirectors for both a Microsoft Client Server Message Block (SMB) network and NetWare, the Setpass.exe program changes only the SMB network password. The solution is to run Setpass.exe with the -N switch when the FPNW password is the target of the action. (Setpass -S specifically targets the SMB password.)

When you use Microsoft's Chgpass.exe or Setpass.exe utility, you're asked to confirm the new password by entering it again. If the confirmation is typed incorrectly, the error message "New password not retyped correctly" appears. There is no prompt offering a chance to re-enter the password. Users are frequently disconcerted by this, but the solution is to start anew. Enter the command (either chgpass or setpass) again.

Maintaining FPNW

To manage and maintain FPNW, use the File and Print Services for NetWare on the server_name dialog box, which is the control room for all the functions and components of the service. You can reach this dialog box through the Control Panel (open the FPNW applet), or from Server Manager (FPNW ? Properties). The dialog box displays a wide range of information about the current status of your FPNW server, and also provides options and icons for making changes.

The option Allow New Users To Login is selected by default, and deselecting this option does exactly what it implies--it stops any additional logins. Use this feature when you're working on the FPNW server. If the work you're performing on the FPNW server requires rebooting the machine, the checkbox is selected again automatically after the computer is up and running, and users can log in. Otherwise, take care of this manually.

Click the Users icon to display the list of users. There's a Disconnect button you can use for a selected user or all the users. There's also a Send Message button you should take advantage of before your mouse pointer heads for the Disconnect button.

Troubleshooting FPNW password problems

There's a problem involving new users (users added to User Manager after you've installed FPNW). The NetWare Compatible Login is checked, everything seems fine, but the user is unable to log on to any FPNW server in the domain. The error message "The password or username you specified is not valid for this resource" appears (in some cases the error message is "User has not been granted the requested logon type at this machine"). Remarkably, if you deselect the NetWare Compatible Login option, the user is able to connect.

The solution to the problem (or the avoidance of the problem) is in the User Manager for Domains dialog box. Choose Policies, User Rights, and make the following change in the User Rights Policy dialog box:

In the Right box, choose Access this computer from the network.
In the Grant to box, make sure Everyone appears (if not, add it).

Microsoft has confirmed the problem, but as of this writing there is no fix.

Another problem that's sometimes difficult to unravel starts with an error message that includes the phrase "Incorrect password or unknown user name" during logon. If you know the username and password are correct, you should look at the number of current connections on the server. Novell distributes and prices NetWare according to the number of connections. When the number of concurrent connections is reached, the operating system does not accept additional connections. The references to username and password in the error message are specious. Wait until a current user logs off, or force a user off if he or she is not active.

Directory Service Manager for NetWare

I love the name of this Microsoft add-on; it's a marketing marvel. Windows NT 4 doesn't provide real directory services, although Novell does. DSMN is a management tool that synchronizes account information among NT and NetWare servers in a domain, and it's a welcome utility to administrators who manage mixed environments.

When you use DSMN to add a NetWare server to a domain for management, the NetWare accounts (user and group) are propagated to the domain, and NT accounts on the domain can access the NetWare servers. Each user has a single password for servers running either NetWare or Windows NT, and DSMN synchronizes the passwords for all servers.

DSMN does not operate across domains. A user can be propagated only to NetWare servers that have been added to the domain that contains the user's account.

Overview of DSMN

After you've used DSMN to add NetWare servers and accounts to your NT domain, User Manager for Domains is your central administration point for all users. Here's a quick overview of the important guidelines:

Add all new accounts in the domain through User Manager; don't use the NetWare utilities on NetWare servers.
Accounts that require access to NetWare servers must be enabled for NetWare (select the Maintain NetWare Compatible Login checkbox in the user account properties dialog box).
DSMN provides its own version of Chgpass.exe, so make sure that centrally administered NetWare users change their passwords with this version (it synchronizes the password change for all servers in the domain).
When a NetWare server has been added to a domain for management, you cannot add it to another domain (unless you remove it from the first domain).
Performance suffers noticeably if more than 32 NetWare servers are added to a domain.

After you add a NetWare server to a domain, you can continue to use NetWare administrative tools to manage functions other than user account management (such as file permissions, accounting, and printing).

Understanding propagation

DSMN takes accounts from both NT and NetWare, massages them so they can be administered in one place, with one set of properties, and then propagates the accounts back to the servers of both operating systems. Some complications arise due to the fact that Windows NT and NetWare do not handle accounts in exactly the same manner. There are, for example, some differences in the methods used for restricting accounts.

When DSMN collects information about a NetWare account, some compromises are seen in the resulting user account properties. For instance, some of the NetWare user restrictions can't be translated to NT because NT uses groups to restrict accounts. The same is true of NT accounts, where the NT-specific properties can't be propagated to the NetWare server(s) in their original form.

Because you want to maintain and manage accounts on an NT server (a sine qua non for purchasing DSMN), NT wins. User restrictions are handled via groups in DSMN.

Understanding synchronization

When you add NetWare servers to your domain with DSMN, an account synchronization database is created on the PDC. The information in the database is propagated back to the NetWare servers. The database also tracks its work by maintaining the following information:

The specific accounts being propagated to each NetWare server in the domain
The current update status of all accounts on each NetWare server

The current update status of an account includes which modifications made to the account have been copied to the individual NetWare server(s). If the account is copied to more than one sever, the status may be different for each server.

Warning: Do not propagate to NetWare servers without backing up the binderies first. I've heard about too many occasions in which some glitch occurred so that propagation didn't work properly (or at all) and the binderies were attacked and destroyed. If you suffer this fate, backing up means you can restore the binderies, correct the problem with DSMN, and begin again.

When you work in User Manager for Domains, DSMN detects any changes you make and updates the account synchronized database. Then the changes are sent to all the NetWare servers to which this account should be propagated. If any target NetWare server is not running, the effort is repeated later. The account synchronization database keeps track of the account updates that are still needed for each NetWare server. When accounts are updated, only the changed information is sent in order to minimize network traffic.

Verifying synchronization

The DSMN CD-ROM contains a program named Dsmchk.exe, which is a utility that tests password synchronization. The software examines one or more NetWare servers in the domain and compares the user's password on each NetWare server to the user's password on the primary domain controller.

The syntax for Dsmchk.exe is:

dsmchk -d domain -u username [-n Nwserver] [-r retries:interval]

where:

-d domain

is the domain for which you're verifying synchronization.

-u username

is the user account you're checking.

-n Nwserver

is the name of a NetWare server with which to verify synchronization. If you omit this, all NetWare servers in the domain are verified.

-r retries:interval

specifies a number of retries and the interval between retries (in seconds).

Dsmchk.exe returns information about the user's password condition with the following error levels:

0 The password is synchronized across the NetWare server(s) you checked and the PDC.

1 The password is not synchronized.

2 The NetWare server is unknown to DSMN.

3 The domain name is unknown.

4 The user account name is unknown to DSMN.

5 The user account name is not administered between the PDC and the specified NetWare server(s).

Complete instructions for installing Dsmchk.exe are on the CD-ROM.

Recovering from NetWare user errors

As I mentioned earlier in this section, DSMN installs its own version of Chgpass.exe to ensure that any NetWare-enabled user's password changes are communicated to the central management database.

If a user invokes the Setpass.exe utility on the NetWare server, the next synchronization effort fails for that user. The error is written to the Application Log of Event Viewer:

Event ID: 8020
Description: The sync agent service failed to modify account account
name on the NetWare server servername due to error 53.

What has happened, of course, is that DSMN tried to synchronize with the NetWare server, but the password was changed without going through the central management point in Windows NT. The change wasn't propagated back from the NetWare server to DSMN, so the account cannot be synchronized by DSMN.

Here's how to recover:

On the NetWare server, change the password back to the original password.
Use the DSMN Synchronization Manager to select that NetWare server, and select Synchronize Selected Server.
After the synchronization has finished, change the password on Windows NT.
Remove the user account on the NetWare server.
During normal synchronization, DSMN will re-create the account with the new password.

It's a good idea to keep an eye on Event Viewer.

Client Services for NetWare

Microsoft provides a NetWare-compatible redirector for workstations in the form of Client Services for NetWare (CSNW). The services are similar to those provided in GSNW, except they're running on a single computer. Novell also provides client software, and it's theoretically more robust. However, many administrators report numerous problems in their efforts to maintain clients using the Novell services. There's a great debate about whether the problem is inherent in the Novell solution or in the way Windows NT handles the software.

Password synchronization between the local NT computer and the NetWare server is automatic when the user presses the Ctrl-Alt-Delete sequence and chooses Change Password from the dialog box. There are, however, some other glitches regarding authentication.

CSNW does not disconnect properly

After a CSNW user logs off a NetWare server, an attempt to log on again may result in an error message, "NetWare Authentication Failure." The full text of the error message includes the information that the number of concurrent connections for the user account has been reached.

Windows NT does not disconnect the NetWare server, so the error message is quite correct--a logged on user cannot log on again because the default number of concurrent connections for all users is 1. Microsoft provided a fix for this bug in SP4, but if you didn't install that service pack (and don't plan to), your only recourse is to set the number of concurrent connections for users employing CSNW to a number greater than 1. Of course, this can compromise the security of your NetWare server.

WHOAMI command fails

If a CSNW user does not log onto his or her workstation with administrator rights, the WHOAMI tool fails with an "access denied" error message. This is because invoking WHOAMI opens a handle directly to the NetWare redirector device, an action that requires administrative permissions. This bug has not yet been fixed.

Unix Connections

NT-Unix integration is rather prevalent and there are many administrators who run this combination of operating systems. The two common solutions in use are Microsoft's Windows NT Services for Unix and third-party SMB servers.

NT Services for Unix

Microsoft's NT Services for Unix is a collection of tools that's available as an add-on to Windows NT. The tools provide several important features:

Korn shell and common Unix commands. This means you can run shell scripts and use Unix commands on a Windows NT server, making administration of the mixed environment far easier.
Telnet administration of both Unix and Windows NT Servers. This is true remote administration, providing access to all servers from a client workstation.
Password synchronization between Windows NT Server and Unix servers. This is a one-way synchronization device, from NT to Unix.

NT-to-Unix passwords can be sent either as clear text or encrypted text.

At the core of the NT Services for Unix add-on is the Network File System (NFS). This service provides the mechanism for sharing files and printers. Windows NT users can access files on Unix machines, and Unix users can access files on Windows NT Server.

Authentication is handled by the NFS client on the NT machine, which authenticates the information in the logon window against the Unix accounts database. When the user is authenticated, preconfigured Unix resources are mounted. The configuration is user-based, and you can compare it to the "reconnect at logon" feature for mapping drives in Windows. If the user wishes to add a resource during the session, the original logon password is used to authenticate access to the new resource. The original configuration of the Unix resources, including permissions, is performed by an administrator.

SMB Server Software

Windows NT has built-in support for Server Message Block (SMB) authentication. SMB is sometimes called the Common Internet File System (CIFS) file-sharing protocol. There are a number of software vendors providing SMB server functions, but the one I consistently encounter in NT-Unix shops is Samba, so you'll see references to that software in this section. This is not an endorsement of Samba over any other package, it's strictly a recognition of its popularity (which increases the odds that administrators who read this are familiar with it).

Samba is freeware (it was developed in the halls of academe, which may account for its distribution method). It's been around for a long time and is robust and well-documented, and it supports just about every flavor of Unix. Information about Samba is available at https://us1.samba.org/samba/samba.html .

If you're the NT administrator and there's a different administrator for the Unix side of your shop, you have nothing to do. Samba is installed and configured on Unix. This is true for most Unix SMB servers interoperating with NT because the client side is built in to NT.

Service Pack 3 for Windows NT 4 created a serious problem for administrators using SMB servers. Starting with SP3, the SMB redirector will no longer send an unencrypted password to an SMB server. Unfortunately, many SMB servers support only unencrypted password exchanges during authentication. (Before SP3, the SMB client automatically negotiated down to plain-text authentication if the server requested that.) There are two possible solutions for this dilemma:

Contact the SMB server vendor to see if an update is available.
Change the registry to allow plain text passwords.

Enough time has passed since the release of SP3 to make it reasonable to ask your SMB server vendor for a mechanism to authenticate with encrypted passwords. (Samba version 2.0 supports encrypted passwords.)

To enable unencrypted passwords for SMB clients with SP3 (or later) installed, you can change the registry. Go to HKLM\System\CurrentControlSet\Services\Rdr\Parameters and add the REG_DWORD value EnablePlainTextPassword. Enter a data value of 1.

There are, of course, some serious security ramifications to making this registry change. You're disabling the protection offered by encryption when you authenticate users to any SMB host. On most Unix systems you can use pam_smb to perform all authentication on an NT PDC, which takes care of password synchronization issues. (Using the NT box for this task means you don't have to be a Unix expert to do account management.)

Auditing Security Events

An important ingredient in your recipe for a secure environment is an audit trail. You can select the events you want to audit and the specific information you want to track for each of those events. The audit record is written to the Security Log of the Event Viewer.

Enabling Security Auditing

To enable security auditing, open User Manager for Domains and choose Policies, Audit and select the Audit These Events radio button. The following events are the most significant:

Logon and Logoff Failure

Checks every connection and disconnection to the network

User and Group Management Failure

Checks creation, deletion, and modification of users, groups, and passwords

Security Policy Changes Success and Failure

Checks changes to policies for user rights, audits, or trust relationships

Logon failures for dial-in clients are not audited.

Some administrators also log successes for User and Group Management, and even for Logons and Logoffs. Usually this zealousness is motivated by some evidence of a problem (or some knowledge that makes the administrator suspicious that undesirable activity is occurring).

Unless you've installed SP4 or later, there's a bug that causes a problem when you audit successful logons and logoffs. When you shut down the computer, you may experience a hang during the shutdown process, followed by the dreaded blue screen and the error message "STOP 0xC0000244 An attempt to generate a security audit failed." This occurs because, during shutdown, NT shuts down the event log (and other services) before your actual logoff (which is part of the shutdown process). Then NT tries to report a logoff audit event, but the event log is not available.

Another bug fixed by SP4 affects the audit of certain User and Group Management events. The following events are incorrectly logged as Event ID 642: User Account Changed:

Event ID 625: User Account Type Change
Event ID 626: User Account Enabled
Event ID 628: User Account Password Set
Event ID 629: User Account Disabled
Event ID 640: General Account Database Change

The big problem with auditing, especially if you're logging successes, is the eventual size of the log. If you're having a security problem, or think you may be, you don't want to overwrite events you haven't yet examined. You can use the configuration options on the Event Viewer to set the overwrite options and to increase the size of the log.

You can also clear the log manually, but save the contents first (File ? Save As, and choose Text as the file type). If you configure the log for a large size, you can move it to another partition if that provides more disk space. To accomplish this, you must change the registry as follows:

Go to HKLM\System\CurrentControlSet\Services\EventLog.
Select the subkey for the log file you want to move (in this case, Security).
Double-click the value File and change the path to reflect the new location.

The path you enter must exist, and you must include the filename assigned to the log. The following filenames are used for Event Logs:

Security: Secevent.evt
Application: Appevent.evt
System: Sysevent.evt

Restart the computer to put the change into effect.

The security of your computer, domain, and enterprise is tightly integrated with your approach to and administration of passwords. Regardless of the password policies you decree, you're going to spend time solving logon problems that are related to passwords (especially forgotten passwords and users with sloppy typing habits). There's no escape; it comes with the territory when the title Administrator appears on your door.

About The Author

Kathy Ivens has been a computer consultant since 1984, and several years ago she began writing books. She has authored, coauthored, contributed to, and ghostwritten more than three dozen volumes on computer subjects. She is a frequent contributor to national magazines on computer topics, writing reviews and articles, and has a monthly column in Windows NT Magazine.

Before becoming a computer nerd, Ms. Ivens spent many years as a television producer, where she had fun producing sports, news, and entertainment programs.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Click to order