Version 3.28.15
(August 07, 2000)
DISCLAIMER: THIS PRODUCT IS SUPPLIED "AS IS". DREAMLAN DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THE WARRANTIES OF MERCHANTABILITY AND OF FITNESS FOR ANY PURPOSE. DREAMLAN ASSUMES NO LIABILITY FOR DAMAGES, DIRECT OR CONSEQUENTIAL, WHICH MAY RESULT FROM THE USE OF THIS PRODUCT. |
NDS Admin is a simple helpdesk-type utility that allows authorized users to perform the following tasks:
- Change NDS password for NDS users.
- Change password expiration dates.
- Reset grace login limits.
- Reset intruder detection lockouts.
- Disable and enable user accounts.
- Change number of concurrent logins.
Using NDS Admin, you're NOT required to grante any special NDS rights to the users to perform the above functions.
This is especially important in the case of changing passwords in the NetWare 4 environment -- the W NDS right to the ACL of the user object is required and can lead to unnecessary security issues. Although this shortcoming was addressed by Novell in NetWare 5 with the new Change Password attribute, but it doesn't give helpdesks the necessary rights to reset grace logins and so on. As a result, you're still required to make additional manual NDS rights assignments in order to set up a "full functional" helpdesk. NDS Admin saves you from having to do that.
A client/server model approach is used by NDS Admin. The server engine logs in with an userid that has the required NDS rights; the clients don't need any special NDS rights (just file system rights to a specific directory in order to pass "messages" back-and-forth with the server engine). This tool also provides the helpdesk personals with a "light weight" front end utility so that they don't need to access the more "bulkier" NETADMIN or NWAdmin programs just to change a password.
Unlike an earlier version of NDSAdmin, NDS Admin v2 and higher is implemented using a "client/server" model. The server portion (called the engine) will log into the NDS with the proper NDS rights to make password changes, to modify grace limits, to reset intruder lockouts and so on; the clients simply send the requests and receives replies to / from the engine and no special NDS rights are necessary.
(If for some reason you'd like NDS Admin v1, which is simply a "light weight" NETADMIN and users need to be granted the appropriate NDS rights, please contact us.)
To keep things simple, communication between the client and the engine is done through a set of command / response files stored in a common shared directory. The up-side of such a design is the independency of transport protocols being used on the network. As long as the client workstation can access a specific directory (and create the command files) on the NetWare file server, the engine can process the requests. The drawback is that the use of text files as communication "buffers" is not the most efficient nor is the most "sexy" technique available.
To ensure only one copy of the engine is accessing the work directory, the engine creates a "lock file" (called ADMENG3.SES) in the directory upon start up. If the engine detects an existing copy of the file, the engine will not start up (unless you override it in the CFG file). Similarly, the client software creates its own lock file (called xxxADMIN.SES, where xxx is a session number unique to the user). This is to prevent multiple copies (by the same user) is accessing the same work directory. The client software also checks to see if the engine lock file exists. If not, that means the engine is not running, and the client software will not start up.
The information flow between the engine and the client as follows:
- Client makes a request to the engine to lookup a username. The name can be a common name (without context information, e.g. name), an absolute NDS name (with a leading period and full path listed, e.g. .name.org_unit.org), or a partial name (a common name with a wildcard information, e.g. nam*) or a name with partial context information (e.g. name.org -- no leading period).
- The engine processes the name lookup as follows. If the name is just a common name, the engine will search the subtree for all username with that common name. A list is returned to the client. If the name is an absolute NDS name, the engine will lookup the name and returned some associated information to the client. If the name is a partial name, the first search context defined in the engine's CFG file will be appended to the name and then a search is performed on this "full" name. The following information are returned from a successful search:
Full name, telephone number, intruder lockout data, grace login data, min. password length, password needed flag, and account status flag (i.e. locked or not)
- If so desired, the client can then make requests to modify the password, change grace logins, reset intruder lockout, and so on. If the account is disabled, you can enable it, and vice versa.
- The engine processes the request and return a success or fail status to the client.
The NDS Admin v3 engine is available as an NLM (ADMENG3.NLM)--the (16-bit) DOS engine has been discountinued but you can request a copy via email if you really need it; it is not compatible with the new GUI client nor does it or will it support the newer features added, such as changing the number of concurrent logins. The NDS Admin v3 client is only available as a (32-bit) Windows executable (ADMUSER.EXE) which runs on Windows 9x and NT (we haven't tested it with Windows 2000 but don't expect any problems with it). No special installation steps or programs need to be used. However, there are some configurations you need to perform.
The files may be installed on any volume on your NetWare server. The following steps assume the files are being installed into SYS:NDSADMIN:
- Create a directory called NDSADMIN off the root of SYS: (i.e. SYS:NDSADMIN).
- Create a directory called WORK under NDSADMIN (i.e. SYS:NDSADMIN\WORK). [Optional] Flag this directory Purge (this is because a lot of temp. files are created and then deleted).
- Copy ADMENG3.NLM, ADMENG3.CFG, and ENCRYPT.EXE to SYS:NDSADMIN.
- Copy ADMUSER.EXE and ENG_APP.EXE to SYS:NDSADMIN\WORK. [Optional] Flag this file ReadOnly. You may copy ADMUSER3.EXE to the workstation if you wish. However, if you do so, ensure you have the appropriate unicode files (see below) and when the program is launched, the current work directory is set to the shared directory, SYS:NDSADMIN\WORK.
- Create a group called NDSADMIN in your NDS tree. It can reside anywhere in your tree as it is used to assign file system trustee rights.
- Assign the users that will use ADMUSER.EXE members of the NDSADMIN group. Depending on the license you have, the base license allows only the first 100 (helpdesk) users to access ADMUSER.
- Grant the NDSADMIN group all file system rights (except for Supervisory and Access Control) to SYS:NDSADMIN\WORK.
- Modify the supplied ADMENG3.CFG file to reflect your site's particular needs, and place the file in SYS:NDSADMIN. This file is read by ADMENG3.NLM upon loading. Make sure you have included the LoginUser and LoginPassword entries in the CFG file. Encrypt the password (LoginPassword) first using the DOS application, ENCRYPT.EXE, before entering it into the CFG file. (The LoginUser needs to have the proper rights to modify the User objects in the tree.)
NOTE
As a security measure, you should not use Admin as the LoginUser but create a separate User object that has Supervisor object rights to the branch(es) of your tree that are to be managed. If you wish, assign a Station Restriction to this LoginUser so it can only login from either the file server on which the NLM is loaded (use the Internal IPX address as the network number).
Upgrading from v2 to v3
The old client software is not compatible with the new engines, therefore, you need to ensure the correct files are used. By designed, the filenames are different, therefore, there should be no confusion.
You need to copy the old CFG file to a new name: ADMENG3.CFG. All the old settings (with the exception for the license key; you'll need to get a new key -- see Registation) will work, and some new ones are introduced. Perhaps before you rename the file, take a look at the new sample CFG file first.
You should rename the NDSADM2 group to NDSADMIN, although it is not necessary.
Upgrading from earlier versions of v3 to the GUI client
You can keep the same CFG file but need to use the new NLM that's included. The older version of NLM is not compatible with the GUI client.
Running the NDS Admin Engine
To use the NLM version of the NDS Admin engine (AdmENG), type the following command at the file server console or include it in your AUTOEXEC.NCF file:
LOAD SYS:NDSADMIN\ADMENG3
After the NLM logs in to NDS and ready, it will display a message similar to this:
NDSAdm3 engine is now ready!
If you encounter an error message similar to the following about fmod, ensure MATHLIB.NLM is loaded (it is not auto-loaded by the NLM):
Server-4.10-1586: Loader cannot find public symbol: fmod
The NLM engine has been tested to work on NetWare 4.10, 4.11, 4.11 SMP, 4.2, NetWare 5.0 and NetWare 5.1.
It has not been fully tested on SFT III servers.The GUI client has been tested extensively under Windows 9x and NT 4 Workstation but not on Windows 2000.
Shutting Down the NDSAdm Engine
Use the ENG_APP.EXE (DOS) program to shutdown the NDS Admin engine. Simply run the program and select the shutdown option. When prompted for the password, enter Down (note the uppercase D).
You can use the same application to restart the engine for new settings in the CFG to take effect. The password is Restart (again, note the uppercase R).
Although it is possible to UNLOAD the NLM but doing so may cause the server console to hang--it is always difficult in a multi-threaded environment to kill a process cleanly by hand. It is best to use the ENG_APP utility for an orderly shutdown. Also, UNLOADing may result in the OS reporting some resources not released.
Running the NDSAdm3 Client
The client software for NDS Admin v3 is called ADMUSER.EXE. It is a 32-bit Windows application. To run the application, perform the following steps:
- Change the current working directory to SYS:NDSADMIN\WORK. This is an important step as ADMUSER, by default, creates its lock file, command file, and expects the response file to be in the current working directory.
- Start the application by typing ADMUSER and press <Return>.
You can also create a shortcut on the Windows desktop. But you need to add one or more of the following command-line parameters to the shortcut properties:
- -P:path. Where path is the path to your "work" directory, e.g. g:\ndsadmin\work. You can use a UNC path here instead, e.g. \\servername\sys\ndsadmin\work.
- -O:DoAutoRetreive. Will automatically retrieve user information without having to click Retrieve Data; default is not to. (Can also be changed from within the GUI using the system menu.)
- -O:DoConfirmOnSubmit. Shows a confirmation dialog box when you submit changes; default is not to. (Can also be changed from within the GUI using the system menu.)
- -O:NoPromptOnExit. Do not prompt with a confirmation dialog box when exiting the GUI; default is to prompt. (Can also be changed from within the GUI using the system menu.) Does not work in Evaluation mode.
- -R:full_username. Allows you to pass a username (e.g., .peter.dreamlan) on the command-line so the lookup will be done right away. This was added to support a helpdesk application (HEAT from Goldmine/Bendata) so Admuser can be launched from its trouble ticket.
Use -? to get a list of supported parameters.
AdmUSER will create a .SES file for tracking purposes. The file is named xxxADMIN.SES where xxx ranges from 0 through 100 (or the max. number you defined in the CFG file using the END= keyword). If all the sessions are used up, AdmUSER will exit with an error message. This file is deleted when AdmUSER is existed normally. However, if the program was not terminated properly (say, it was terminated using Task Manager) the .SES file is not deleted. You can delete it and then restart ADMUSER.
Using the NDSAdm3 Client
The initial AdmUSER screen prompts for a user object name. You can specify either a common name, partial name, or full-pathed name. You can also use a wildcard ("*") as part of the name (for example, test* or *test); the question mark ("?"), however, is not a valid wildcard character in NDS.
You can also use Alias User objects.
When multiple hits are found, a pick list is displayed. Select the name by highlighting the entry and then press <Return>.
The engine will return user information which will be displayed on the screen. Although you can move the cursor back-and-forth (<Tab> or Shift-<Tab>) between editable fields, it is best to use the mouse. Once you are done with the desired changes, click Submit Changes.
The client will wait up to 60 seconds for a response from the engine. You can abort the wait by clicking Cancel changes (you can also cancel the data retrieval by clicking Cancel retrieve). If for some reason the client times out after 60s, you have the option of waiting for another 60s or abort.
It was noticed during testing that on very rare occassions (which we believe is now fixed), AdmUSER will report an access violation when attempting to rename the command file. This is caused by aborting the waiting just at the same time when the RENAME takes place. Check using MONITOR NLM and see if there is a .CMD file opened (by the server but not by the workstation). If this is the case, logout and login again should resolve the conflict.
Any time during the data input stage at the client, you can click Clear to cancel out of the current screen.
If you keep getting "user not found" errors when you know for a fact the user does exist, chances are good that your server's running low on memory and AdmENG can't allocate the necessary memory to process the reqeust. Sometimes stopping the engine (using APP_ENG) and reloading the NLM works. Otherwise, you may need to restart the server.
To disable an userid (this was implemented by request from one site as their Helpdesk may be called upon after hours to disable user ids), click Disable Current User. You must have first called up this particular user's information before you can disable it.
To ensable an userid (this was implemented by request from another site as their user accounts are initially disabled and users--students--have to call in to have them enabled), click Enable Current User. Again, you must have first called up this particular user's information before you can Enable it.
To change expiration date for password, click on the date field and a calendar pops up. To exercise this option, the engine's CFG file must have SupportPasswordExpire set to 1. See Configuration for more information. Also see bullet #7 in Limitations.
To exit the program, click Exit.
As a security measure, the passwords used in the change password requests from the client to the engine are encrypted.
The following is a copy of the supplied NDSADM3.CFG file:
# NDSADM3.CFG # ----------- # Version 1.0 -- Mar 15, 1997. # Version 1.1 -- Apr 11, 1997. # Version 1.2 -- Apr 26, 1997. # Version 1.3 -- Apr 28, 1997. # Version 2.3 -- Jun 06, 1997. Released. # Version 2.4 -- Oct 28, 1997. Released. Increased limit # of ExcludeUser from 10 to 100 # (NLM engine only) # Version 3.0 -- Jul 31, 1998. # Version 3.2 -- Jun 20, 2000. Updated to include new options. # Version 3.3 -- Aug 07, 2000. Updated to reflect change in search context. # # Configuration file used by the NDSAdm3 Engine program # # Caution: # ------- # If there are multiple entries of the same keyword, # the last entry will be used. #-------------------------------------------------------- # Note: # ---- # Make sure each line is terminated by a CR/LF. If not, # the line may be ignored. # # The beta and eval/demo version of NDSAdm3 does not require the # following two (2) keywords. #LicenseKey = #LicensedTo = # Every time when the engine starts up, it checks for a session file # (ADM3ENG.SES) just in case another copy of the engine is using the # same directory for data. However, this is sometimes "painful" for # the NLM engine -- if the server abends or the NLM was manually # unloaded, the SES file is not deleted, and will prevent the NLM # engine to "auto-load" on the next server restart. Therefore, we have # added the OverwriteSession flag. Set it to one (1) to not check for # conflicts, else set it to zero (0) for checking. The default is zero. # This keyword is not used by the EXE engine as you can easily delete # the offending SES file. # - In v2.5 and higher, OverwriteSession=1 will also delete # any .DAT and .CMD in the "Home directory" that may be # left over from the last unload. OverwriteSession = 1 # NDS context(s) from which the search of the name will start from. # Up to 20 different contexts are supported. Ensure that you do not # list subordinate contexts, such as: # SearchContext = DreamLAN # SearchContext = NW4Develop.DreamLAN # This will cause duplicate hits on the same username. The default # NDS context is [Root]. Please ensure *no* leading period is included. # Otherwise, you will encounter an error from DSSetContext. # The following SearchContext represents the following NDS structure: # # [Root] # | # +---------------+-----------------+ # | | # o=dreamlan o=north_america # | # + cn=admin # | # ou=toronto # #SearchContext = [Root] SearchContext = dreamlan SearchContext = north_america # Time interval the engine will pause between processing intervals. # You may wish to increase this setting if the engine poses too much # CPU utilization (NLM version). # Range is 5 seconds < DelayTimer < 60 seconds. Default is 5. DelayTimer = 5 # Home directory in which the work files are to be found. # Default is SYS:NDSADMIN. Do not include server name. HomeDir = SYS:NDSADMIN #HomeDir = SYS:helpdesk # Name of log file. Default is [None], which means no log # is created. Log file will be appended to if exist. Must be just # a complete file name (including volume and directory path). # Do not include server name. #LogFile = [None] LogFile = sys:ndsadmin\logfile.dat # For use with the EXE engine. #LogFile = d:logfile.dat # LoginUser - no default. This user must have full file system rights # to the "home directory". Note that leading period *is* needed, and # the full NDS name path is used. LoginUser = .admin.org # LoginPassword - no default. This is an encrypted password. # Please encrypt the password using the supplied ENCRYPT.EXE and then # insert the encrypted password below. LoginPassword = encrypted_password_here # List up to 100 users to be excluded from access by NDSAdm3. # Syntax: ExcludeUser = abs_full_NDS_name # Note that leading periods *should* be included. ExcludeUser = .admin.dreamlan ExcludeUser = .test-admin.toronto.dreamlan # New options for v3.0 and higher: # SecureMode = x # where 0 = default (no security) # 1 = verify password on AdmUSER startup # 2 = verify password before every action # ContainerSecurity = x # where 0 = default (no security) # 1 = enable security # SupportPasswordExpire = x # where 0 = default (no support) # 1 = enable support # End = x # where x is a number from 2 to 100 (or your max. # user-license count). Let's say if you only # have 20 users for NDS Admin, set this to 20 # so the engine will not waste time scanning # for other command files. # # New options for v3.27 and higher: # SupportConcurrentLogin = x # where 0 = default (no support) # 1 = allow changing concurrent login count # SupportUserStatus = x # where 0 = default (no support) # 1 = allow disabling/enabling of user account # SecureMode = 0 ContainerSercurity = 0 SupportPasswordExpire = 0 SupportConcurrentLogin = 0 SupportUserStatus = 0 End = 100To provide some measure of security, the password used by the login user for the NLM is encrypted before placing in the CFG file. Please use the supplied ENCRYPT.EXE (DOS) program to generate the encrypted password.
It is strongly recommended that you at least include the Admin user and the user that the NLM is logging in as in the exclusion list in the CFG file. This prevents the engine from changing Admin's and its won passwords. Since the software also supports the use of Aliases, include any Admin aliases in the exclusion list.
ContainerSercurity Mode
The use for the ContainerSecurity mode setting requires some explanation.In most cases, you would leave it at the default setting of 0 (i.e. disabled). This is really an "enterprise helpdesk" option.
By default, the NDS Admin user can manage any user objects within the tree, as determined by the search context settings. However, there may be times you only want those users to only manage other users that are in the same context or below. For example, you may only want user .HELPDESK1.EAST.COMPANY manage users in container .EAST.COMPANY and below and not to manage users in container .WEST.COMPANY and below. This is where the ContainerSecurity mode comes into play. Consider the following sample NDS tree:
[Root] | O=Company | +----------+----------+ OU=West OU=East | | ALLOW_NDSADMIN + + HELPDESK1 + | users + + | +-----+-----+ OU=A OU=B | | users + + usersIf the engine's search context setting is ".OU=East.O=Company, .OU=West.O=Company", user HELPDESK1 can manage users in both contexts. However, if ContainerSecurity is enabled, HELPDESK1 can only manage users in OU=East and below; will have no control over user objects in OU=West. This is useful when you have a distributed helpdesk configuration.
There are times, however, when ContainerSecurity mode is enabled, a user needs to manage more than one context. For example, HELPDESK1 needs to manage users in both OU=East and OU=West. This can be done by creating an ALLOW_NDSADMIN group OU=West (since the HELPDESK1's context is OU=East) and making HELPDESK1 a member of that group. Now, HELPDESK1 can manage both contexts. There is no limit on how many ALLOW_NDSADMIN groups you can use.
Log File
The log file will keep track of the following information, stored as ASCII text, one event per line:
- Engine startup time
- The engine's NDS search context(s)
- Engine shutdown time
- Who changed whose passowrd
- Who changed whose password expiration date
- Who changed whose grace login to what value
- Who reset whose intruder lockout
- Who disabled which user account
- Who enabled which user account
- Who changed whose concurrent login limits
If a user's password *and* intruder lockout are changed (for example), this is counted as two separate events, and two records will be entered into the log file. The format of the record is:
dd-mmm-yyyy hh:mm:ss text
where the time is given in 24-hour format.
- Current (base) version allows for up to 100 (or more, depending on your license) users to access AdmUSER. The Evalation version allows only 2 users.
- AdmENG supports up to twenty (20) search contextes. They are searched in the order listed in the CFG file. Non-existant context could result in user not found error.
- The exclusion list is currently (arbitrarily) limited to 100 user names; we're considering adding an exclusion group list as well.
- AdmENG will only respond with up to 10 names when there are multiple name hits.
- The full user object name (i.e. including context) is limited to 50 (or so) characters (due to screen width for display).
- If you see "Small Allocation Memory" not released when the NLM unloads (through the use of the down command), check the CFG file to make sure the SearchContext entries have specified *valid* contexts. (Fixed in v1.3.; however, it seems to have returned in v2.5; and is gone again in v3.)
- When NetWare changes a user's password, if the user is required to change password periodically, the password is automatically expired (i.e. the expiration date is set to Jan 01, 1992). You *can change the password* and its expiration date at the same time using the user interface -- change the password then enter a new expiration date in AdmUSER. If you leave the displayed expiration date as is, the expiration date will be that of NetWare's default! Note that if the Password Expiration field is displayed as "n/a", that means the user password has no expiration date, and you cannot set one. And you cannot use NDS Admin to remove an existing password expiration date. If the Password Expiration Date is longer than the Days Between Password Change, and if you examined the user's password properties using any of the Novell-supplied tools (such as NETADMIN), the Password Expiration Date will be changed. For example, if today's date is Jan 01, 1998, a user's Password Expiration Date was set to be May 01, 1998 using AdmUSER while the Days Between Password Change is 10, after you looked at this user's password restrictions using NETADMIN, the Password Expiration Date will be changed to Jan 11, 1998 by NETADMIN....
The evaluation version (when a valid license key is not present) does not implement the full range of features. For example, you can't disable or enable users. All unsupported features will be reported back as Error #13 on the console and "Not Supported" within the client software. In essence, the unregistered version allows the changing of passwords and very little else.
The full version of NDS Admin is available by registering on-line through the following Web sites:
The NDS tree name is required as it is used to generate the license key. The registration cost (for the 100-user base license) is $99 US. Canadian registration is $135 CDN plus GST. All other countries, please remit in US funds. If you need more than a 100-user license (a user here means a user that needs to access AdmUSER, the client software, not a user on your network), please contact us for pricing.
To upgrade from v2 to the latest version, the cost is $49 US or $70 CDN plus GST. To upgrade from a previous 3.x version to the current version that has GUI support, the cost is free but you need to send us an email to request the update. At this time, the upgrade can only be ordered directly from DreamLAN. Please send an email to upgrade@dreamlan.com for more information.
You can also FAX a company Purchase Order to +1 (905) 887-3836. Please make sure you either include your tree name information on the FAX or send a follow up email.
Special site agreements for multiple trees and service providers are available. Although the license does not grant you the right to resell the program (for a profit; but you can charge the customer a service charge for your time). If you are a service provider, you can register copies on behave of your customers (by providing your customer's mailing information -- this is used only for tracking purposes). At the same time, we ask you to send us a separate email indicating that you are registering on behave of your customer and inciate in this email if further software upgrade (free or for a charge) be send to you or the customer directly, and an email address for that purpose.
NDSAdmin is written in C using Microsoft Visual C++ optimizing compiler and Watcom C 32-bit compiler and Novell Developer Kit.
Inclusion of this utility on CD-ROMs (except for backup purposes) without permission from DreamLAN Network Consulting Ltd. is expressly prohibited.