ntLogon

8/3/2019 ntLogon

http://slidepdf.com/reader/full/ntlogon 1/38

Managing Windows NT

Logons

By Kathy Ivens1st Edition January 20001-56592-637-4, Order Number: 6374236 pages, $29.95

Chapter 2

Password Problems

You can get a running start on preventing passwordproblems with preventive maintenance--designing andimplementing password policies that eliminate (or at leastreduce) logon distress syndrome. There are plenty of philosophical musings published aboutthe "proper" approach to passwords, but the truth is thatnot all companies have the same security needs. If acomplicated password strategy isn't necessary, then give itup and relieve yourself of the burden of trying toimplement that system. If your physical offices are secureenough that strangers aren't freely helping themselves tokeyboards, and if none of your servers are exposed to theInternet or dial-in connections, you can take a lessparanoid approach to passwords. The NT logon process is an elegant approach to password-based security. The NT password model, when combinedwith intelligent password policies, works well to assure thesecurity of both the local NT workstation and the networklogon server.

Logon Process

[ The logon process begins with the Ctrl-Alt-Deletelogon sequence, which hampers poseurs fromgaining access. The Ctrl-Alt-Delete combination iscalled the Secure Attention Sequence (SAS), and itactivates the Winlogon process. This key

8/3/2019 ntLogon


combination avoids conflicts with keystrokes usedby applications. In addition, the combination can beimplemented at a very low level of the operatingsystem, which helps to protect passwordinformation from Trojan horse programs. (A Trojan

horse program can present a fake logon functionthat steals the password and records it, then sendsit back to the person who created the Trojan horse.)]After the user enters a username and password, WindowsNT hashes the password and sends it to the localmachine's Local Security Authority (LSA). The LSA, usingthe LsaLogonUser API, calls an authentication package. Thedefault authentication package for Windows NT is theMSV1_0 Authentication Package, which uses the recordsstored in the Security Accounts Manager (SAM) database.

The SAM stores two passwords for each user: a LANManager-compatible password (for logons from legacycomputers) and a Windows NT password (for logons fromWindows NT clients). The MSV Authentication Package has two sections, calledthe top half and the bottom half. The top half runs on thelocal machine, and the bottom half runs on the machinethat holds the user account information. The clear text password from the user is passed to the tophalf of the MSV Authentication Package, which encrypts itand converts it to both a LAN Manager password and a

Windows NT password. Then it passes the encryptedpassword on to either the local Netlogon service (fordomain logons where the user enters a domain name inthe logon dialog box) or the local lower half (for localmachine logons).For domain logons, the Netlogon service routes the requestto the Netlogon service on the appropriate remotecomputer (an authenticating server). The server returns a16-bit challenge response called a nonce, which is arandomly generated number. The nonce and the hashedpassword are merged and sent back to the server (this

assures that the communication is from the samerequestor). If the returned data is the expected data, theNetlogon service of the authenticating machine passes therequest to the bottom half of its own MSV AuthenticationPackage. The bottom half of the MSV AuthenticationPackage queries the passwords in the SAM and comparesthem to make sure they're identical.

8/3/2019 ntLogon


Both the LAN Manager-compatible password and theWindows NT password are stored doubly encrypted in theSAM. The first encryption is a one-way function (OWF)encryption of the clear text password, and that encryptionis generally considered unbreakable. The second

encryption is an encryption of the user's relative ID. Todecrypt it, you would need to have access to the user'srelative ID as well as the algorithm for the double-encrypted password. The second encryption is appliedtotally for the purpose of creating obfuscation. The SAMprovides 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 thesession. The OWF version of the LAN Manager password is createdby 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 bytesof the clear text password are used to compute the first 8bytes of the OWF-encrypted password, and the second 7bytes of the clear text password are used to compute thesecond 8 bytes of the OWF password. The OWF version of the Windows NT password is derivedusing the RSA MD-4 encryption algorithm. RSA MD-4computes a 16-byte summary (called a digest ) of thestring 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 organizationcan either strengthen or compromise the security built intoWindows NT password functions. Potent policies add moresecurity but carry a higher risk of user error. Flimsy policiesmake life easier for users (and, by extension, foradministrators) but may jeopardize the security of yourcompany's data.Every user account on your network should have apassword, even though all the Microsoft client operatingsystems permit user logons with null passwords. Havingdetermined the need for passwords, you have to decide onpassword policies.

Global Password Policies

8/3/2019 ntLogon


Password policies for the domain are set by opening UserManager for Domains and choosing Policies ➝ Accountfrom the menu bar. Most of the options in the AccountPolicy dialog box are self-explanatory. However, it may notbe obvious that some policies are either mutually exclusive

or mutually dependent:

• If you permit password changes immediately, you shouldnot 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 alsospecify a number of days in the Minimum Password Age section of the dialog box.

Table 2-1 specifies the choices available for those policyoptions 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 minutesLockout Duration 1-99,999 minutes

The mutually exclusive policies have a hidden agenda; oneside is always easier to implement. The cost of that ease is,of course, the level of security. While it's tempting to saythat it's perfectly all right to opt for easy implementation if the domain is physically secure and spies (government orindustrial) don't find your data worth much, I can't say it. Too many administrators underestimate the risks of userswithin the company getting into computers that havesecure data they shouldn't see (such as payroll data).If you establish policies that require periodic passwordchanges, minimum password lengths, bans on usingprevious passwords, and other similar requirements, you'regoing to spend some time dealing with user complaintsand problems. However, I've found that once users learnthat the company is serious about security and they haveto live with the policies, they adjust nicely.

http://www.oreilly.com/catalog/ntlogon/chapter/ch02.html#50384

http://www.oreilly.com/catalog/ntlogon/chapter/ch02.html#50384

8/3/2019 ntLogon


Your password policies should extend beyond the featuresand functions available in Windows NT by makingpassword rules clear to all employees. Create anddistribute a policy statement about the company rules forpasswords. For example, what are the permitted methods

for writing down passwords? You should explicitly statethat if a user needs to make a note of a new password, thenote cannot also contain the logon name, cannot be tapedto the monitor, cannot be kept in the top drawer of thedesk, and so on. You should have explicit rules aboutpenalties for sharing passwords with other users. Be sureusers are notified that administrators may be auditinglogons.

Lockouts

The options you select regarding lockouts are a matter of your own judgment and preference. There is no happyending for the saga of the user who continues to enter thewrong password innumerable times. It's a mysteriousbehavior pattern, but it happens often. You can either letthe user amuse himself for hours in this manner, or lockhim 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 thanlater. Having opted for lockouts, you have two choices forhandling locked out users:

• The lock is permanent, which means an administrator mustspecifically unlock the user.• The lock is removed and reset after a period of time thatyou specify, so the user can try again.

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

To unlock a user, open User Manager and double-click onthe user's listing. In the User Properties dialog box,deselect the Account Locked Out check mark.Because unlocking a user does nothing to improve hismemory, the unlocking process usually includes entering anew password for the user. Enter and confirm a simplepassword and tell the user what it is. Then reset the user'sconfiguration options so that he must create a new

8/3/2019 ntLogon


password on the next logon. The figure you specify in thelockout duration must be as large as, or larger than, thefigure 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 apassword is deselected by default. If you turn it on, a usermust enter her current password in order to create a newone. This provides an additional level of security, but it cancreate extra work for administrators. If a user logs on after

her password has expired, she's unable to create a newpassword because she can't log on. You'll have to createthe password for her.

User Password Policies

There are some password options you can specify on auser-by-user basis. Most of the time, you configure theseoptions when you're creating the user. You can changeexisting user password options by double-clicking theuser's listing in User Manager to open the User Properties

dialog box.

TIP: Unfortunately, Windows NT 4.0 does not permit youto set user password options on a group-by-group basis.This would be very productive because password policiesare (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 thenext 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 hadsome other reason to change the password in UserManager), the check mark reappears in the checkbox. Youcan leave the check mark or deselect it, depending on thecircumstances. You cannot use this option if you've

8/3/2019 ntLogon


configured account policies so that a user is forced to logon in order to change the password. It's possible for anadministrator to generate passwords for users, but it's notadvisable unless you automate the process by using asoftware application--it's just too much work. Windows NT

4 doesn't provide any generated password features, butthere are third-party applications that create passwordfiles.

Prohibiting password changes

The option specifying that the user cannot change thepassword is designed for accounts that are shared bymultiple users. Many companies have workstations atwhich 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 hasthe checks printer attached. If you specify that a usercannot change the password, you cannot enable themutually exclusive option to have the user change thepassword at the next logon. It's also a good idea to applythis option to the Guest account.

Eliminating password changes

The option to let the password live forever (PasswordNever Expires) carries a great deal of potential danger. Its

purpose is to make it easy for you to create specialaccounts (print management, backup, and so on), but if you're trying to maintain a secure system, those accounttypes aren't a good idea anyway. The only set of circumstances in which I've ever agreed to let anadministrator use this option is within a domain site thathas no incoming trust relationships from other sites in theorganization. Small, physically secure sites (such as smallbranch offices) might reap some benefit from thispassword policy because it's free of potential passwordproblems and requires less administration.

Disabling accounts

Disabling an account makes it inactive; it can't be used tolog on and any attempt to do so will produce the errormessage "Your account has been disabled. Please see yoursystem administrator."Disabling an account is useful for several account types:

8/3/2019 ntLogon


• 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 onthe workstation, but the logon process is targeted for thedomain, the disabled workstation account is ignored andthe user logs on to the domain without error.

Good Passwords

Most of us let users create their own passwords, and it's agood idea to distribute guidelines for this task. You canpresent your definition of a good password, along withsome suggested rules (you could call them real rules, but

some are difficult to enforce). The best password is one that's unassociated with the userbecause a clever intruder who knows the user couldpossibly crack such a password. On the other hand, apassword that has no association for the user may beeminently forgettable. Users solve this problem in anumber of amusing ways, ranging from writing theirpasswords on post-its that they affix to their monitors toleaving 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 aninvolved password, another suggestion is to mergeunrelated adjectives and nouns, such as funnyclock orsmartbottle. It's even more effective to use that scheme if you place a number or special character between thewords.NT passwords are case-sensitive, and while this fact canbring some additional complexity to a password, it'sanother one of those little touches that users have aproblem remembering. The longer the password, the harder it is to guess, so you

might want to require a six- or seven-character minimumlength (set the minimum in the Account Policy dialog boxof User Manager for Domains). If you choose to permit nullpasswords, you cannot set a minimum password length.

TIP: Intruders sometimes use software that helps themcrack passwords. Get yourself a copy of one of these programs and test your passwords (run surprise quizzes at

8/3/2019 ntLogon


various workstations). If any password is cracked within afew seconds or a minute, tell the user to create a new, morecomplicated password.

Changing Passwords

NT 4 has a password expiration policy available in theAccount Policy dialog box, and you can use it to force usersto change passwords at an interval you feel comfortablewith. In addition, you can mandate how many passwordchanges must be made before a user can reuse a previouspassword (the maximum is 24). Incidentally, if you use thisoption, it's a good idea to configure your password policiesso that immediate changes are not permitted (deselectAllow Changes Immediately).It's not always necessary to change passwords at regular

intervals, but there's a rule of thumb that says the higherthe level of access, the more frequently passwords shouldchange. Unfortunately, NT 4 doesn't permit passwordexpiration policies to be set for groups, so you have to finda duration that keeps your system safe without driving allyour users crazy.Regardless of whether or not you opt to configure yoursystem for mandated password changes, there aresituations in which you should change passwordsimmediately. For instance, when a user leaves thecompany 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 thepassword expiration. You can change that interval in theregistry atHKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. Create a REG_DWORD data item namedPasswordExpiryWarning. The data you enter in the item isthe number of days before the password expiration datethat the first reminder appears.When the notification begins, users are given theopportunity to change the password immediately without

waiting for the expiration date. The user must enter the oldpassword and then the new password, following which amessage displays to announce the password has beenchanged successfully. When a user logs on with an accountwhose password has expired, a dialog box appears to insistthat the user change the password.For some Windows 95 users, the procedure described inthe previous paragraph is followed by an error message:

8/3/2019 ntLogon


"The Domain password you supplied is incorrect, or accessto your logon server has been denied." Clicking OK redisplays the logon dialog box, and entering the newpassword works.What is happening is that after the logon request is

received by the Windows NT domain controller, and thepassword change has been written to the domaincontroller, a new logon request is issued. However, theoriginal password is sent to the domain controller insteadof the new one. This is a bug in the version of the Windows 95 networkprovider DLL (MSNP32.DLL ) that shipped with the originalretail versions of the operating system and the OEMversions through OSR2. The correct version of the file isMSNP32.DLL Version 4.00.951. The file has the date8/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 OEMinstallation. If not, you can call Microsoft support forinformation about obtaining the file. In the meantime, yourWindows 95 users can probably live with the requirementto re-enter the logon after a password change. However, if you have a lockout policy that kicks in after one badpassword entry, the problem becomes serious. Incidentally,the early version of MSNP32.DLL also causes problems withStrong Passwords (covered later in this chapter).For Windows NT clients, there's a potential problem withthe process of changing a password that you may

encounter if you haven't installed SP3 or later. When thepassword expiration warning appears, including the optionto change the password during the current logon, mostusers take advantage of the opportunity to change thepassword before it expires. If a user chooses Yes to changethe password and then cancels the process before it'scomplete, the logon proceeds normally. The reminder willappear at the next logon. However, entering the passwordfor a protected screen saver fails, as does the passwordused 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 workstationwith a different administrative account. Install SP3 or issuea reminder to users that they shouldn't cancel the changepassword process midstream.

Hiding the Last Logged-On User

8/3/2019 ntLogon


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

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

TIP: Don't put the apostrophe in dont. Every time Iget 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 logonprocess. The most obvious value is that a user who doesn'thave to enter a password won't have a "forgottenpassword" problem. There's also a good argument forusing automated logons on workstations that are alwaysused by the same person and have no importantinformation on the local drive. Workstations or servers that

perform services (print server, RAS server, etc.) and aren'tassigned to a user are also candidates for automaticlogons.When the logon process is automated, users just turn onthe computer and wait for the desktop to appear. There'sno need to use the Ctrl-Alt-Delete sequence to display thelogon dialog box, and in fact, the logon dialog box nevermakes an appearance.Automated logons are established for specific users, andbefore enabling autologon, you must make sure the user'sconfiguration is appropriate for this feature. In User

Manager for Domains, double-click the user's listing andmake these changes:

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

8/3/2019 ntLogon


Then log on to the computer of the user for whom you'reenabling automatic logons, using that user's logon name.For a computer running Windows NT, go toHKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon. When you select this subkey, you should see the data

item DefaultUserName with the name of the user for whomyou're creating the automatic logon. Add a new REG_SZdata item named AutoAdminLogon and give it a data valueof 1. Add another REG_SZ data item namedDefaultPassword and enter the user's password as thedata.For a computer running Windows 9x, use the same stepsfor the registry keyHKLM\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, thefirst automated logon works, but after that the process fails(the logon dialog box appears). The absence of a password causesthe operating system to change the Boolean data for AutoAdminLogonfrom 1 to 0 after the first logon. You cannot use automated logons if you've enabled Legal Noticecaptions and/or text during logon. This feature requires the user toclick OK, and there is no method of automating that step. You alsocannot enable automated logons if you've implemented the feature tohide the name of the last logged on user. These registry entries aremutually exclusive. To bypass the Autologon feature, hold down the Shift key during theboot process.

Strong Password Functions

NT 4 Service Pack 2 (and later) includes a feature that lets you forceusers to create passwords that are designed to enhance passwordsecurity. Commonly referred to as "strong passwords," this featureenforces rules when users create passwords. With strong passwordsenabled, 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 inthe %SystemRoot%\System32 directory. (Sometimes the file doesn'tmake it to the directory, so you may have to find it in the SP files andcopy it.) To enable a strong password policy, you must make a registry changethat references this file. On the PDC, go toHKLM\System\CurrentControlSet\Control\Lsa and create a new subkeynamed Notification Packages (the new key is a REG_MULTI_SZ type).Open the key and add the data value PASSFILT. Reboot the server.

8/3/2019 ntLogon


If you find a Notification Packages subkey already in the registry, itmay have a data value of FPNWCLNT, the service that managespassword synchronization with Novell NetWare servers for File andPrint Services for NetWare. Add the PASSFILT data item below it, don'treplace it.

Because changes to user accounts are handled by the PDC, it's notnecessary 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 BDCsalso, just in case.

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

• Passwords must contain at least six characters, and the character stringmust 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 arehardcoded in the file. However, you can write your own rules and savethem to passfilt.dll or to another DLL file. If you use a different DLL file,you must copy it to the %SystemRoot%\System32 directory andchange 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 strongpassword feature, including sample code, in the MicrosoftWin32 SDK Version 4.0.

Working with Strong Passwords

Change the Windows NT password policies for your domainso they work in concert with strong passwords. Forexample, specify a minimum length of 6 characters, whichautomatically meets the requirements built into passfilt.dlland also subverts the ability to have null passwords.

Additionally, you should give some consideration to thesettings for password uniqueness. Users seem to find itdifficult to invent strong passwords, and someadministrators have found it helpful to let a user repeat apassword after one or two changed passwords. Therationale is that because the passwords are difficult tohack, it doesn't harm security efforts to allow users theright to use an old password quickly. On the other hand,

8/3/2019 ntLogon


administrators who enable the strong password feature doso because they want to apply the maximum passwordsecurity features available. Forbidding repeated passwordsuntil a large number of intervening passwords are usedcertainly tightens security. I think there's merit to both

arguments, and my advice is to go for the strongestsecurity measures at first. If you run into problems becauseusers are having difficulty coming up with a series of strong passwords, you can lower the specified number of remembered passwords or lengthen the interval betweenforced password changes.Strong password rules are only enforced when a usercreates a password over the network. The passfilt.dll filterisn't active when an administrator is writing directly to theSAM, so you can open User Manager for Domains and entera user password that does not qualify as a strong password

(let's call it a weak password). This gives you the ability toenforce strong password rules on a user-by-user basis. If security is of enough concern to warrant theimplementation of strong passwords, use this bypasssparingly, applying it only to users with secureworkstations and/or low access rights.If you enter a weak password for a user in User Managerfor Domains, the ability to use a weak password disappearswhen the specified time for password changes has elapsed.When the user is required to enter a new password, thestrong password rules are in effect. The only way to let the

user continue to use an assigned weak password is toprevent password changes by selecting Password NeverExpires in the user's Properties dialog box.When a user creates a new password that fails to meet therequirements for your strong password policy, the errormessage may be confusing. The most common speciouserror is "You do not have permission to change yourpassword." After you check the User Properties dialog boxto make sure you haven't prevented the user fromchanging passwords, it's safe to assume this is a strongpassword 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 theregistry entry you created (removing the data entry issufficient; you don't have to remove the key).

Dial-in Users

8/3/2019 ntLogon


If users log on to your server via a dial-in connection, youneed to configure the security and authenticationprocedures. The security consideration is whether youpermit callers to access only the server or to use the serverto get to the entire network. The authentication choices

are wider. To set the configuration options, open the Network appletin Control Panel and go to the Services tab. Select RemoteAccess Service and click Properties to open the RemoteAccess Setup dialog box. Click Network to display theNetwork Configuration dialog box.

Server-Only Access Versus LAN Access

In the Server Settings section of the dialog box, choose theprotocols dial-in users can employ. The choices are

NetBEUI, TCP/IP, and IPX, and the choices are not mutuallyexclusive. Click the Configure button for each protocol youpermit, and either limit the dial-in user to the resources onthe RAS server, or let the server act as a bridge to thenetwork.

Dial-in Encryption Settings

The Encryption settings section of the dialog box lists theavailable password encryption options, which are mutuallyexclusive.

Clear text

The first encryption choice is "Allow any authenticationincluding clear text." This is the option that supportsPassword Authentication Protocol (PAP), which usesunencrypted clear text password authentication. Microsoftsupports this option to provide interoperability with third-party PPP clients. It's the least onerous, but also leastsecure, option.

CHAP

The choice named Require Encrypted Authenticationpermits a connection to use any authentication requestedby the client (except PAP). Essentially, this is Challenge-Handshake Authentication protocol (CHAP).NT supports several encryption algorithms for CHAPauthentication:

8/3/2019 ntLogon


• 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 passwordauthentication scheme.

RSA

RSA is an encryption and authentication system that usesan algorithm developed in the 70s by people namedRivest, Shamir, and Adleman. Their web site,http://www.rsa.com/, is a good place to visit if you haveany interest in learning more about security viaencryption.

The RSA encryption is accomplished by multiplying twolarge prime numbers and then using the resulting data toderive a set of two numbers: one number is the publickey and the other is the private key. (After those keys aredetermined, the original prime numbers are no longerneeded and are discarded.)Both the public key and the private key are needed forencryption/decryption of data, but the private key isnever sent across the communication channel. Thesender gets the public key from a central administratorand 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 sendsa public key, then uses its private key to encrypt a digitalcertificate. The receiver uses the public key to decryptand authenticate the certificate.

MS-CHAP

The choice named Require Microsoft EncryptedAuthentication is MS-CHAP, Microsoft's rendition of the RSAMD4 standard. It provides the most secure encryptionalgorithm that NT supports. Both Windows NT and Windows98 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 availablewith data encryption. Click the Require Data Encryptioncheckbox to encrypt all the data coming over the wires.

http://www.rsa.com/

http://www.rsa.com/

8/3/2019 ntLogon


MD5-CHAP

SP3 added the ability to support dial-in clients that requestPPP MD5-CHAP authentication (the motivation for thechange was to support non-Microsoft dial-in clients).

Support is enabled by a registry change and is specific tothe RAS server on which the registry is changed. Theinformation about the MD5 account is stored only in thelocal registry and cannot be integrated into the accountdatabase you access through User Manager. To create support for MD5 clients, open a registry editorand go toHKLM\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'spassword 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 theregistry so it's important to secure the registry againstprying. See "Securing the Registry" in Chapter 6,Controlling User Activity .

DES

The Data Encryption Standard is a popular dataencryption procedure that uses a private key so difficultto break that the U.S. government has ruled that it cannotbe exported to other countries. There are more than 72

quadrillion possible encryption keys that can be used forDES. With DES, both the sender and the receiver mustknow and use the private key.

Microsoft expects to provide full MD5-CHAP support in thenear future, so all this work for rather limited support won'tbe necessary. The Windows NT RAS client supports MD5-CHAP encryptionso that Windows NT PPP clients can connect to third-partyPPP Servers that use MD5.

NetWare ConnectionsMany corporate networks mix Novell NetWare serverswithin a Windows NT network. In some cases, companiesmaintain NetWare servers for a period of time as theycomplete the migration from NetWare to NT. Othercompanies retain NetWare servers permanently for file andprint services. In this mixed environment, Windows clients

8/3/2019 ntLogon


can connect to a NetWare server through an NT gateway oraccess the servers directly.

Gateway Service for NetWare

The Gateway Service for NetWare (GSNW) links everyworkstation connected to an NT server to all the NetWaredrives connected to that server. GSNW is commonly usedfor occasional (rather than full-time) connections to aNetWare server.

The Awful Truth About GSNW

The reason GSNW isn't a useful full-time connection isthat its performance level is just awful. It provides asingle highway lane to the NetWare resource and thenpermits a whole lot of vehicles to use that lane. The trafficmoves at the pace you'd expect, or even slower thanyou'd expect. This is the quintessential definition of thephrase "bandwidth problem." You can configure GSNW for unlimited users (there'sactually a limit, but it's in the billions so there's littlechance you're going to bump into it). If those users needto spend any time performing tasks on the NetWareshare, they're going to be extremely unhappy.Adding to the problem is the fact that GSNW must act asa translator between two operating systems that usedifferent and incompatible protocols to communicate withclients. NT uses the Server Message Block (SMB) protocoland NetWare uses NetWare Core Protocol (NCP). On theway 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 aretime-consuming.Use GSNW for quick and easy tasks, perhaps fetching acopy of a file, looking at a document, or sending adocument to a printer. The single advantage of GSNW is that Microsoft clientsdon't need any other client network software (such as aredirector or NWLink). They merely need the protocolnecessary to connect with the NT server. In fact, to avoidconflicts, you should remove redirectors from the clientsthat use the gateway.

GSNW overview

8/3/2019 ntLogon


The NetWare server sees only the NT server, which it seesas a NetWare client. Microsoft clients see the NetWareserver as a resource on the NT server. The NT server handles client logon validation and passesusers through to the NetWare server. All users who gain

access to the NetWare server through the gateway haveidentical rights to that server; there is no opportunity tocreate individual permission levels for clients.During the first logon to the NT server after installingGSNW, you're asked to choose a preferred NetWare serverfor the gateway. This is the first step in configuring yourGSNW services. When you enter the name of the NetWareserver, GSNW attempts to log you on, using the accountand password you used to log onto the NT server. If thataccount name and password don't exist on the NetWareserver, the logon fails.

If you logged on to the NT server as Administrator (acommon scenario), you cannot successfully log on to theNetWare server, because there is no account namedAdministrator. On NetWare 2.x and 3.x servers, theequivalent 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 aNetWare 4.x server create an account on the NT servernamed Admin and use the password for the Admin account

on NetWare. (Apparently it's easy to remember to typeAdmin if you're used to typing Administrator.)

Configuring GSNW

You should set up the accounts, passwords, and rights youneed before configuring GSNW. You need to set up two user accounts on the NetWareserver. The first is an account with full administrativerights. You use this to accomplish setup and configurationoptions for the gateway. Create the account and password

so that it matches your logon for the NT server (such asthe Admin account mentioned previously). The second user account is the account gateway clientsuse. Using the first (administrative) account, establish thisaccount with the following steps. (For NetWare 2.x and 3.x,use SYSCON to create the account. For NetWare 4.x, useNETADMIN.)

8/3/2019 ntLogon


1. Create a username that reflects the role of this account,such as GWUSER or GWADMIN.2. Create a home directory, or use an existing one.3. Create a password.4. Remove any account restrictions that may exist by default.

5. Be sure the account is enabled by default.6. Ensure there are no time restrictions for logging in.7. Set the rights to the NetWare filesystems you need for thegateway.8. 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 accountnames. If you want to use GW USER, you must enterit as GW_USER.

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

1. Create the group.2. Add the user you created in the previous steps to the group(GWUSER, for example).3. Give the group sufficient rights to the appropriate NetWaredirectories.

You do not need user accounts for the clients who use thegateway, 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 tothe GSNW NT server as an administrator and open theGSNW icon in the Control Panel. In the Gateway Service forNetWare dialog box, click Gateway to bring up theConfigure Gateway dialog box. Enable the gateway, thenconfigure the NetWare share as follows:

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

The NT server automatically uses this account to accessthe NetWare server. The rest of the options on this dialog

8/3/2019 ntLogon


box aren't related to authentication issues, so I won'tdiscuss 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 unlimitednumber of users through. The common reason for limiting users isload balancing, which assumes you have other NT servers runningGSNW.• The Use Drive drop-down list lets you map a drive to theshare. Because mapped drives can be reconnected on startup, thisis the way to automate the connection to the NetWare share whenthis NT server boots. That automation means, of course, thatclients have access to the share as long as the computer is up andrunning--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 youcreate. The mapping is local to this NT server and has noeffect 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 youmust set permissions for each share. Select the sharenameyou 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 theWindows NT group Everyone has Full Control permissions(this is the default). If you haven't enabled the gatewayservice, the Permissions button is grayed out. You can reduce the permissions to match your securitypolicies. The available permissions are No Access, Read,Change, and Full Control. Don't downgrade the permissionsif the change will compromise the clients' ability to getwork done. The permission level you set applies to every client thataccesses this share through this gateway. If you want a

mix of permissions for clients, you must create a differentshare for each set of permissions and assign NT groups tothe share.It's important to understand the pecking order forpermissions:

• The trustee rights settings you configured on the NetWareserver are primary.

8/3/2019 ntLogon


• If the share permissions conflict with the trustee rights, thetrustee rights win.

That means if you set directory rights of Read and FileScan on the NetWare server, clients will not be able to

modify, create, or delete files even though you set FullControl permissions in the GSNW dialog box. The processes of installing GSNW, enabling the gateway,configuring the NetWare share(s), and mapping drives tothe shares completes the installation of all the files youneed. Even the NetWare redirector files are copied to yourNT server's drive. All the installed services are set forAutomatic Startup, so restart the server to give yourWindows users access to NetWare servers. When they takeadvantage 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 spendon password errors should be negligible. However, thereare some possible authentication problems you need to beaware of.

Problems in NetWare Startup.ncf

If a user on a computer running NT connects to a NetWareserver with the net use command and sees the error

message "System Error 86 - the specified networkpassword is not correct," the problem lies with theStartup.ncf file on the NetWare server.When you configure a NetWare server that's participatingin a mixed environment with NT, you must make sure thatNetWare does not use checksums to examine the incomingIPX packets from the NT client. Startup.ncf contains a linethat 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 IPXheader, so when NetWare parses the header it won't findwhat it's looking for. As a result, NetWare rejects thepacket. Be sure the checksums line has a value of 0 or 1.

File and Print Services for NetWare

8/3/2019 ntLogon


In a way, FPNW is the opposite of GSNW. You add FPNW toan NT server to let NetWare clients access that NT serveras if it were a NetWare server. FPNW is an add-on availablefrom both Novell and Microsoft. The Microsoft version isbundled with Directory Service Manager for NetWare

(DSMN).FPNW is useful during migration from NetWare to WindowsNT and is equally useful if you plan to operate a mixed-platform environment for a long time.

There is a known memory leak connected to FPNW, andyou should configure a Performance Monitor to keep aneye on PrivateBytes for Nwssvc.exe. If you find the counter increasing rapidly, you'll probably see an Out Of VirtualMemory error message eventually. The problem ariseswhen 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 thiswriting, 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 theNetWare features you're used to. However, because FPNWruns on Windows NT, there are some "gotchas" as a resultof the way non-identical functions and features aretranslated between the operating systems.

FPNW configuration

When you install FPNW, a service account is createdautomatically. The account is a member of theAdministrators group. There are three important caveatsconnected to this account:

• You cannot delete or disable the account.• You cannot change permissions or privilege levels for theaccount (by this, I mean you cannot downgrade the levels).•

You cannot change the Log On As specification in theFPNW services (in the Services applet of the Control Panel) to anyother account.

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

8/3/2019 ntLogon


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

Configuring users

When you install FPNW on an NT server, users who runNetWare client software can access the files and printersinstalled on that server. These clients are consideredNetWare-enabled user accounts by the NT server, and youcreate and manage them with User Manager for Domains.From the NetWare client's point of view, logging on isperformed in the same manner as if a connection to aNetWare server were being made. The client sees theserver as a NetWare server, and a successful logon means

the user is authenticated for both NetWare and WindowsNT. 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 NTgroups. NetWare and NT both have categories foradministrative 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 togive users the rights and privileges built into a system-defined type, you use an equivalence function. Forexample, you can give a user the rights of a Supervisor by

making him a "Supervisor Equivalent" user. NetWaresystem-defined rights can't be altered.Windows NT has system-defined groups, and adding a userto 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 andmaintain 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 boxcontains two additional elements:

• A checkbox option named Maintain NetWare CompatibleLogon• An icon named NW Compat

8/3/2019 ntLogon


The NW Compat icon is grayed out until you select theMaintain NetWare Compatible Logon option to enableNetWare-compatible functions for the current user.Click the NW Compat icon to open the NetWare CompatibleProperties dialog box, which handles NetWare issues. Then

use the options described here to complete the user'sconfiguration: NetWare Compatible Password ExpiredSelect this option to force the user to change her password at the nextlogin from a NetWare client.WARNING: If you force a user to change the password atthe next login, be sure your account policies do not requirethe user to be logged in to change the password. Deselectthat option on the Account Policy dialog box in UserManager for Domains if you'd opted to use it.Grace Logins

Selected by default, the Unlimited Grace Logins option allows the user tolog in forever with an expired password. You can tighten up the password policy by choosing the Limit Grace Logins option instead and specifying anumber in the Grace Logins to Allow field. The user cannot continue tolog in with an expired password after that number is reached. TheRemaining 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 ConnectionsBy default, the user can have an unlimited number of simultaneousconnections. You can limit the number of concurrent connections byselecting Allow and specifying a number.Edit Login ScriptDon't use this feature. Clicking this icon opens the Edit Login Scriptdialog box. The login script in question is the user login script (FPNWsupports the NetWare feature of permitting both a system login script anduser login scripts). Instead, use a text editor (or Notepad) to open and editthe user login script. There are lots of problems reported by administratorswho 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 theway they do for NT users, but, once again, the installationof FPNW adds elements to some of the dialog boxesattached to the icons. Other icons include:Profile iconThe User Environment Profile dialog box has a text box for the NetWareCompatible Home Directory Relative Path. The account can have both a

8/3/2019 ntLogon


NetWare Login script and a Windows NT Logon script. The data youenter in the User Profiles section and the Home Directory section applywhen this user logs on from a Windows client.Hours iconThe Logon Hours dialog box offers settings in half-hour increments,

which is the NetWare standard (Windows NT uses hourly increments).Logon To iconThe Logon Workstations dialog box has NetWare-specific options at the bottom. The option User May Log On To All NetWare CompatibleWorkstations is selected by default. You can limit logons to specificworkstations by deselecting that option and adding specific NetWareclient workstations to the list.Account iconFPNW makes no changes to the Account Information dialog box.Dialin iconFPNW makes no changes to the Dialin Information dialog box.

Managing passwords with FPNW

When you install FPNW on an NT server, the SecurityAccounts Manager (SAM) database is modified so it canstore the FPNW password. When a user logs on using adomain account, FPNW queries the domain controller tovalidate the FPNW password. If the domain controller'sSAM database has not been updated, the user is deniedaccess. You can remedy this by installing FPNW on all thedomain controllers in the domain. You do not have to

activate the service; it's the installation process thatmodifies the SAM. You can alternatively install Microsoft's FPNWAUTHprogram on every domain controller to modify the SAM. The software is available atftp://ftp.microsoft.com/bussys/winnt/fpnw-unsup-ed/utilities/fpnwauth.When you're creating a new account under FPNW, thepassword you assign for NetWare is also automaticallyassigned to NT logons. If you configure an existing accountfor NetWare, the existing NT password is automatically

assigned as the FPNW password. If you change the accountpassword in User Manager for Domains, both passwordsare changed. This synchronization is terrific because itdoesn't matter whether the user logs in from an NT clientor a NetWare client, entering his or her password worksevery time.However, users change passwords, either because theywant to or because there's an expiration date approaching.

ftp://ftp.microsoft.com/bussys/winnt/fpnw-unsup-ed/utilities/fpnwauth




8/3/2019 ntLogon


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 clientsIf 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 aChange Password option. This password change is accepted by both the NT server and FPNW, so the password remains synchronized.Other Windows clientsIf the user is running Windows 9x, 3.x, NT 3.5, or DOS, using theappropriate password change function (which varies by platform) changesonly the NT server password. The passwords are out of sync unless theuser also invokes the Setpass.exe or Chgpass.exe utility to change theFPNW password. NetWare clientsIf 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 differentpasswords, for Windows NT and NetWare, you mayexperience some annoying workstation behavior. After theNT logon, Windows NT tries to log the user on to theNetWare server using the same password. This, of course,doesn't work, and eventually the user is prompted to entera NetWare password. If the user cancels the NetWare logon(perhaps he or she isn't planning to work with the softwareinstalled on the NetWare server), Windows NT tries the NTpassword 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 monitorand can't accomplish anything. There are two ways toavoid this problem:

• Make sure the Windows NT and NetWare usernames and passwords match.• If the passwords don't match, instruct users to continue thelogon 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 theonly one you can enforce.

Using Setpass and Chgpass

During the installation of FPNW, the files Setpass.exe andChgpass.exe are copied to the \Sysvol\Public directory of the NT server. Invoking these files provides the same

8/3/2019 ntLogon


services as the Novell NetWare utilities of the same name.When users enter the commands, they're calling aMicrosoft program, not a Novell program (but that'stransparent to the user). Either command works to create apassword.

Setpass.exe and Chgpass.exe (as well as Login.exe),require RPC support files. Rpc16c1.rpc, Rpc16c6.rpc, andSecurity.rpc are installed automatically in the directory\Sysvol\Public. If users copy the password utility programsto their local hard drives, the .RPC files must reside in adirectory in the search path.Setpass and Chgpass always change the FPNW password,and, if the conditions are right, the NT password is changedsimultaneously. 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 connectto 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 aMicrosoft Client Server Message Block (SMB) network andNetWare, the Setpass.exe program changes only the SMBnetwork password. The solution is to run Setpass.exe withthe -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.exeutility, you're asked to confirm the new password byentering 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-enterthe 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 PrintServices for NetWare on the server_name dialog box,which is the control room for all the functions andcomponents of the service. You can reach this dialog boxthrough the Control Panel (open the FPNW applet), or fromServer Manager (FPNW ➝ Properties). The dialog boxdisplays a wide range of information about the current

8/3/2019 ntLogon


status of your FPNW server, and also provides options andicons for making changes. The option Allow New Users To Login is selected by default,and deselecting this option does exactly what it implies--itstops any additional logins. Use this feature when you're

working on the FPNW server. If the work you're performingon the FPNW server requires rebooting the machine, thecheckbox is selected again automatically after thecomputer 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 aDisconnect button you can use for a selected user or all theusers. There's also a Send Message button you should takeadvantage of before your mouse pointer heads for theDisconnect button.

Troubleshooting FPNW password problems

There's a problem involving new users (users added toUser Manager after you've installed FPNW). The NetWareCompatible Login is checked, everything seems fine, butthe user is unable to log on to any FPNW server in thedomain. The error message "The password or usernameyou specified is not valid for this resource" appears (insome cases the error message is "User has not beengranted 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 theproblem) is in the User Manager for Domains dialog box.Choose Policies, User Rights, and make the followingchange in the User Rights Policy dialog box:

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

Microsoft has confirmed the problem, but as of this writingthere is no fix.Another problem that's sometimes difficult to unravelstarts 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, youshould look at the number of current connections on theserver. Novell distributes and prices NetWare according to

8/3/2019 ntLogon


the number of connections. When the number of concurrent connections is reached, the operating systemdoes not accept additional connections. The references tousername and password in the error message arespecious. 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 marketingmarvel. Windows NT 4 doesn't provide real directoryservices, although Novell does. DSMN is a managementtool that synchronizes account information among NT andNetWare servers in a domain, and it's a welcome utility toadministrators 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 thedomain can access the NetWare servers. Each user has asingle password for servers running either NetWare orWindows NT, and DSMN synchronizes the passwords for allservers.DSMN does not operate across domains. A user can bepropagated only to NetWare servers that have been addedto the domain that contains the user's account.

Overview of DSMN

After you've used DSMN to add NetWare servers andaccounts to your NT domain, User Manager for Domains isyour central administration point for all users. Here's aquick 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 beenabled for NetWare (select the Maintain NetWare CompatibleLogin checkbox in the user account properties dialog box).

• DSMN provides its own version of Chgpass.exe, so makesure that centrally administered NetWare users change their passwords with this version (it synchronizes the password changefor 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 youremove it from the first domain).

8/3/2019 ntLogon


• Performance suffers noticeably if more than 32 NetWareservers are added to a domain.

After you add a NetWare server to a domain, you cancontinue to use NetWare administrative tools to manage

functions other than user account management (such asfile 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 theaccounts back to the servers of both operating systems.Some complications arise due to the fact that Windows NTand NetWare do not handle accounts in exactly the same

manner. There are, for example, some differences in themethods used for restricting accounts.When DSMN collects information about a NetWare account,some compromises are seen in the resulting user accountproperties. For instance, some of the NetWare userrestrictions can't be translated to NT because NT usesgroups to restrict accounts. The same is true of NTaccounts, where the NT-specific properties can't bepropagated to the NetWare server(s) in their original form.Because you want to maintain and manage accounts on anNT 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 thePDC. The information in the database is propagated backto the NetWare servers. The database also tracks its workby 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 NetWareserver

The current update status of an account includes whichmodifications made to the account have been copied to theindividual NetWare server(s). If the account is copied to

8/3/2019 ntLogon


more than one sever, the status may be different for eachserver.

Do not propagate to NetWare servers without backing upthe 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 anddestroyed. If you suffer this fate, backing up means you canrestore the binderies, correct the problem with DSMN, and begin again.

When you work in User Manager for Domains, DSMNdetects any changes you make and updates the accountsynchronized database. Then the changes are sent to allthe NetWare servers to which this account should bepropagated. If any target NetWare server is not running,

the effort is repeated later. The account synchronizationdatabase keeps track of the account updates that are stillneeded for each NetWare server. When accounts areupdated, only the changed information is sent in order tominimize network traffic.

Verifying synchronization

The DSMN CD-ROM contains a program namedDsmchk.exe, which is a utility that tests passwordsynchronization. The software examines one or more

NetWare servers in the domain and compares the user'spassword on each NetWare server to the user's passwordon 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 passwordcondition with the following error levels:0 The password is synchronized across the NetWare server(s) you checkedand the PDC.

8/3/2019 ntLogon


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 theCD-ROM.

Recovering from NetWare user errors

As I mentioned earlier in this section, DSMN installs its ownversion of Chgpass.exe to ensure that any NetWare-enabled user's password changes are communicated to thecentral 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: 8020Description: 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 tosynchronize with the NetWare server, but the passwordwas changed without going through the centralmanagement point in Windows NT. The change wasn'tpropagated back from the NetWare server to DSMN, so theaccount cannot be synchronized by DSMN.Here's how to recover:

1. On the NetWare server, change the password back to theoriginal password.2. Use the DSMN Synchronization Manager to select that NetWare server, and select Synchronize Selected Server.3. After the synchronization has finished, change the password on Windows NT.4. Remove the user account on the NetWare server.5. During normal synchronization, DSMN will re-create theaccount 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 forworkstations in the form of Client Services for NetWare(CSNW). The services are similar to those provided in

8/3/2019 ntLogon


GSNW, except they're running on a single computer. Novellalso provides client software, and it's theoretically morerobust. However, many administrators report numerousproblems in their efforts to maintain clients using theNovell services. There's a great debate about whether the

problem is inherent in the Novell solution or in the wayWindows NT handles the software.Password synchronization between the local NT computerand the NetWare server is automatic when the userpresses the Ctrl-Alt-Delete sequence and chooses ChangePassword from the dialog box. There are, however, someother 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, "NetWareAuthentication Failure." The full text of the error messageincludes the information that the number of concurrentconnections for the user account has been reached.Windows NT does not disconnect the NetWare server, sothe error message is quite correct--a logged on user cannotlog on again because the default number of concurrentconnections for all users is 1. Microsoft provided a fix forthis bug in SP4, but if you didn't install that service pack(and don't plan to), your only recourse is to set the numberof concurrent connections for users employing CSNW to a

number greater than 1. Of course, this can compromise thesecurity of your NetWare server.

WHOAMI command fails

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

Unix Connections

NT-Unix integration is rather prevalent and there are manyadministrators who run this combination of operatingsystems. The two common solutions in use are Microsoft'sWindows NT Services for Unix and third-party SMB servers.

8/3/2019 ntLogon


NT Services for Unix

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

• Korn shell and common Unix commands. This means youcan run shell scripts and use Unix commands on a Windows NTserver, making administration of the mixed environment far easier.• Telnet administration of both Unix and Windows NTServers. This is true remote administration, providing access to allservers 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 orencrypted text.At the core of the NT Services for Unix add-on is theNetwork File System (NFS). This service provides themechanism for sharing files and printers. Windows NTusers can access files on Unix machines, and Unix userscan access files on Windows NT Server.Authentication is handled by the NFS client on the NTmachine, which authenticates the information in the logonwindow against the Unix accounts database. When theuser is authenticated, preconfigured Unix resources are

mounted. The configuration is user-based, and you cancompare it to the "reconnect at logon" feature for mappingdrives in Windows. If the user wishes to add a resourceduring the session, the original logon password is used toauthenticate access to the new resource. The originalconfiguration 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 theCommon Internet File System (CIFS) file-sharing protocol. There are a number of software vendors providing SMBserver functions, but the one I consistently encounter inNT-Unix shops is Samba, so you'll see references to thatsoftware in this section. This is not an endorsement of Samba over any other package, it's strictly a recognition of

8/3/2019 ntLogon


its popularity (which increases the odds that administratorswho 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 athttp://us1.samba.org/samba/samba.html.If you're the NT administrator and there's a differentadministrator for the Unix side of your shop, you havenothing to do. Samba is installed and configured on Unix. This is true for most Unix SMB servers interoperating withNT because the client side is built in to NT.Service Pack 3 for Windows NT 4 created a serious problemfor administrators using SMB servers. Starting with SP3,the SMB redirector will no longer send an unencrypted

password to an SMB server. Unfortunately, many SMBservers support only unencrypted password exchangesduring authentication. (Before SP3, the SMB clientautomatically negotiated down to plain-text authenticationif the server requested that.) There are two possiblesolutions for this dilemma:

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

Enough time has passed since the release of SP3 to makeit reasonable to ask your SMB server vendor for amechanism 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 toHKLM\System\CurrentControlSet\Services\Rdr\Parametersand add the REG_DWORD value EnablePlainTextPassword.Enter a data value of 1. There are, of course, some serious security ramifications tomaking this registry change. You're disabling the

protection offered by encryption when you authenticateusers 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 bea Unix expert to do account management.)

http://us1.samba.org/samba/samba.html

http://us1.samba.org/samba/samba.html

8/3/2019 ntLogon


Auditing Security Events

An important ingredient in your recipe for a secureenvironment is an audit trail. You can select the events youwant to audit and the specific information you want to

track for each of those events. The audit record is writtento the Security Log of the Event Viewer.

Enabling Security Auditing

To enable security auditing, open User Manager forDomains and choose Policies, Audit and select the Audit These Events radio button. The following events are themost significant:Logon and Logoff FailureChecks every connection and disconnection to the network User and Group Management FailureChecks creation, deletion, and modification of users, groups, and passwordsSecurity Policy Changes Success and FailureChecks changes to policies for user rights, audits, or trust relationshipsLogon failures for dial-in clients are not audited.Some administrators also log successes for User and GroupManagement, and even for Logons and Logoffs. Usuallythis zealousness is motivated by some evidence of aproblem (or some knowledge that makes the administratorsuspicious that undesirable activity is occurring).Unless you've installed SP4 or later, there's a bug thatcauses a problem when you audit successful logons andlogoffs. When you shut down the computer, you mayexperience a hang during the shutdown process, followedby the dreaded blue screen and the error message "STOP0xC0000244 An attempt to generate a security auditfailed." This occurs because, during shutdown, NT shutsdown the event log (and other services) before your actuallogoff (which is part of the shutdown process). Then NTtries to report a logoff audit event, but the event log is notavailable.Another bug fixed by SP4 affects the audit of certain Userand Group Management events. The following events areincorrectly 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

8/3/2019 ntLogon


• Event ID 629: User Account Disabled• Event ID 640: General Account Database Change

The big problem with auditing, especially if you're loggingsuccesses, is the eventual size of the log. If you're having a

security problem, or think you may be, you don't want tooverwrite events you haven't yet examined. You can usethe configuration options on the Event Viewer to set theoverwrite options and to increase the size of the log. You can also clear the log manually, but save the contentsfirst (File ➝ Save As, and choose Text as the file type). If you configure the log for a large size, you can move it toanother partition if that provides more disk space. Toaccomplish this, you must change the registry as follows:

1. Go to

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

The path you enter must exist, and you must include thefilename assigned to the log. The following filenames areused 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 istightly integrated with your approach to and administrationof passwords. Regardless of the password policies youdecree, you're going to spend time solving logon problemsthat are related to passwords (especially forgottenpasswords and users with sloppy typing habits). There's noescape; it comes with the territory when the title

Administrator appears on your door.Back to: Managing Windows NT Logons

oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly ContactsInternational | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.

http://www.oreilly.com/catalog/ntlogon/noframes.html

http://www.oreilly.com/

http://www.oreilly.com/sales/bookstores


http://www.oreilly.com/order_new/


http://www.oreilly.com/oreilly/contact.html


http://www.oreilly.com/international/

http://www.oreilly.com/oreilly/about.html

http://www.oreilly.com/affiliates.html



http://www.oreilly.com/privacy_policy.html


http://www.oreilly.com/catalog/ntlogon/noframes.html

http://www.oreilly.com/





http://www.oreilly.com/international/

http://www.oreilly.com/oreilly/about.html



Documents

ntLogon