dittrich@milton.u.washington.edu (Dave Dittrich) (05/03/91)
Thanks for all those who responded to my post regarding restoration of the SUPERVISOR password on a 2.15c NetWare LAN. It is suprisingly simple to take care of the problem of a lost SUPERVISOR password. The fix involves exploitation of the behavior of NetWare v2.x regarding the bindery files (NET$BIND.SYS and NET$BVAL.SYS, which are hidden system files in the SYS:SYSTEM directory), and the use of sector editor (such as Norton's Utilities) and the NetWare utilities SHOWFILE and BINDREST. The behavior that is exploited is that of creation of bindery files on initial bootup of a freshly installed server. On such a system, the files NET$BIND.SYS and NET$BVAL.SYS do not exist. If NetWare boots and does not find these files it will create them with account information for two accounts: GUEST and SUPERVISOR. Neither of these new accounts has a password, which is what lets you get back in to the SUPERVISOR account. The steps are amazingly simple and painless to perform, which brings up a very important (and blatantly obvious) issue for those who have their servers in locations accessible to general users: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Anyone who can boot your server to DOS and operate the computer through the keyboard can get control of the SUPERVISOR account, and thus the system! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The system I maintain is located in the same laboratory with student workstations. The console keyboard lock VAP is ineffective in protecting the server in this situation, so the AT keyboard lock key is used instead. The best situation would be to have the server locked into a closet or other secure room, but if space is at a premium the keyboard lock is adequate. As I said, the steps are very easy and painless. After reading to descriptions of the steps involved to understand them thoroughly, it took me less than five minutes to have the password reset. The first description is found in the book "NetWare Supervisor's Guide" (McCann, John T. et al, M&T Books, Redwood City CA, ISBN 1-55851-111-3, pp. 393-396). This method uses an undocumented NetWare utility DISKED, which is created by the NETGEN utility Network Generation Options, Configure File Server Utilities sub-option. This method assumes that you created the utilities prior to having your little password problem, and that you created working diskettes and have access to them. In my situation I inherited a working LAN from someone, and not knowing any better I never performed these two steps myself. Learn, as I did, from my mistake. The second method was recently distributed to the NOVELL list on NOVELL@SUVM by H.C. Eng GBODSO1@NUSVM.BITNET. The method described by Mr. Eng's does not suffer the same problems as just mentioned above, nor is it nearly as complex or possibly error prone as the first method. Pre-requisites for the procedure are a DOS boot disk and Norton's Utilities (or similar sector editor capable of absolute sector read/write to use on the non-DOS NetWare drive partition--NU is very nice for this task!). The steps are as follows: o Shutdown the server and boot with DOS. o Run NU and read the first 100 sectors of the NetWare boot disk (usually C:) in absolute mode. o Do a test search for "NET$B". This will allow you to locate the files NET$BIND.SYS and NET$BVAL.SYS. o Edit the sector(s) to change the names to NET$BIND.OLD and NET$BVAL.OLD. (These are the names expected by the utility BINDREST.) o Write the modified sectors back to disk. (If you use a primitive sector editor like DISKED, make sure you write the sectors back to the same place they came from!) o Reboot the server to NetWare. Ignore the mirrored directory error message by answering "N" to the "abandon mount?" question. o Login as SUPERVISOR. There is no password at this point so you will be logged in immediately. o CD to SYS:SYSTEM. Issue the commands, "SHOWFILE NET$BIND.OLD" and "SHOWFILE NET$BVAL.OLD". Now issue the command "BINDREST". The old bindery information has now been restored. o BE SURE TO CHANGE THE SUPERVISOR PASSWORD BEFORE YOU LOGOUT! Thanks again to everyone that replied to my post. -- Dave Dittrich dittrich@u.washington.edu ...!uw-beaver!u.washington.edu!dittrich
jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) (05/04/91)
In article <1991May2.232728.25767@milton.u.washington.edu> dittrich@milton.u.washington.edu (Dave Dittrich) writes: > >It is suprisingly simple to take care of the problem of a lost SUPERVISOR >password. The fix involves exploitation of the behavior of NetWare v2.x >regarding the bindery files (NET$BIND.SYS and NET$BVAL.SYS, which are hidden >system files in the SYS:SYSTEM directory), and the use of sector editor (such >as Norton's Utilities) and the NetWare utilities SHOWFILE and BINDREST. > >The steps are amazingly simple and painless to perform, which brings up a >very important (and blatantly obvious) issue for those who have their servers >in locations accessible to general users: > The task of restoring a supervisor's password is not as simple as outlined here. No mention of the type and technology of hard drive was given. If you have a non MFM hard drive such as a SCSI, ESDI, or are using a DCB for your fileserver, the likelyhood of being able to use ANY disk editor is very slim. DOS on it's own doesn't like drives other than MFM unless your controller card is designed to work with DOS. Suppose you have an MFM drive in your server. When you boot DOS, the drive will be recognized but you can't access it because there is no DOS partition. As the original poster says you will be able to edit it with any ordinary disk editor that reads non-DOS partitions. Now suppose you have a Novell DCB in your server and you boot DOS. Will DOS recognize your hard drive? I just tried it with one of my servers and it didn't work. DOS didn't even know it existed. A DCB is not a normal disk controller. As far as I know, it doesn't work with DOS unless you have a special driver to access it. That is why Novell made the DISKED program. When you NETGEN your Novell software, it links DISKED to the driver for your particular hard drive, whether it be MFM, SCSI, ESDI, or a DCB. ESDI works under DOS because it's got firmware on the board to initialize the drive when DOS goes looking. I'm not sure if SCSI does. I've got SCSI drives and controllers from Storage Dimensions. They use specialized interface cards and drivers specifically designed to work with Novell. DOS won't understand that you have a hard drive with these devices. So what does this all mean? It means that if you use non DOS compatible hardware, ie DCB's and specialized SCSI devices, you will not be able to change the binderies unless you have DISKED linked with the correct drivers. SO KEEP THOSE DISKS LOCKED UP! and you'll slow those netware thieves down considerably. jeffd@csd4.csd.uwm.edu >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >Anyone who can boot your server to DOS and operate the computer through the >keyboard can get control of the SUPERVISOR account, and thus the system! >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >Pre-requisites for the procedure are a DOS boot disk and Norton's Utilities >(or similar sector editor capable of absolute sector read/write to use on >the non-DOS NetWare drive partition--NU is very nice for this task!). > >o Run NU and read the first 100 sectors of the NetWare boot disk > (usually C:) in absolute mode. > >Dave Dittrich >dittrich@u.washington.edu ...!uw-beaver!u.washington.edu!dittrich
jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) (05/05/91)
> From ingea@ifi.uio.no Sat May 4 06:55:01 1991 > In article <11745@uwm.edu> you write: > >The task of restoring a supervisor's password is not as simple as outlined > >here. No mention of the type and technology of hard drive was given. If > >you have a non MFM hard drive such as a SCSI, ESDI, or are using a DCB > >for your fileserver, the likelyhood of being able to use ANY disk editor > >is very slim. DOS on it's own doesn't like drives other than MFM unless > >your controller card is designed to work with DOS. > > This is highly inaccurate. DOS does not access the drive HW directly. > BIOS contains all code needed to access the hard drive.. A standard AT BIOS > contains code support for the WD1002/1003/1006 controllers and compatible. > Most SCSI and ESDI controllers are not HW compatible with those cards, but > almost all these cards a supplied with a PROM containing code support. All > calls made from DOS to BIOS are trapped by the SW suplied on the card. This is a good restatement of what I was trying to say. If your drive card DOES contain a PROM to support the BIOS calls, then it will be able to be read from DOS. But if your card DOES NOT contain the neccessary PROM, you will not be able to access the drive without special software. What about Novell DCB's? How can these be accessed from DOS? I tried to with one of my servers but couldn't get DOS to recognize the drive. Here's another important question, how does Netware 3.11 work with a Novell DCB and how do you get the required DOS partition on the drive? > > I would say that 99% of all ESDI and SCSI controllers are supplied with > such firmware, and will work with most disk editors, including NU. I use Storage Dimensions SCSI drives for all my servers. I'm not sure if their cards (SDC-80X, SDC-160X) support DOS out of the box. They ship software to make it work with DOS and you have to install that before you can use the drive for Netware 3.X. I think the area of third party hard drive hardware needs to be looked at more closely to see exactly how accessable information stored on it is available to DOS. Thanks for the insight. Jeff jeffd@csd4.csd.uwm.edu > -- > Inge (BoB) { ingea@ifi.uio.no } > ========================================================================= > == Inge Arnesen, University of Oslo, Norway. ==