Here at the office we have a group in charge of assigning and maintain user and group rights and permissions to our various systems.  It’s nice not having to worry about that aspect of server administration. 

But I have an urgent need to have some eDirectoy group rights assigned to a specific directory on every Netware server in our Enterprise.  The group that controls user access is saying that they can’t meet my timeframe for getting these rights assigned, so I had to come up with my own solution.

My solution was to use Wolfgang Schreiber’s  lrights.exe utility to script assigning the rights command line style.  The syntax is:

LRights <path> <rights> /name=<trustee>

For example, to assign read and file scan rights to the .mygroup.OU.O user:

lrights \\server\volume\directory R F /Name=.mygroup.OU.O

This utility was written to support long path/file names, unlike Novell’s rights.exe utility.

We’ve been experiencing issues with some of our Backup Exec 9 remote agents losing their connections to media server during backup.  The Backup Exec server job logs report the following generic error:

Final error: 0xa000fe30 – A communications failure has occurred.

To help troubleshoot this problem, I decided to enable debugging on the Backup Exec remote agent. To do this, on the Netware server that is running the Backup Exec remote agent:

1.  Make a backup copy of the sys:\system\bestart.ncf file

I performed a Groupwise 6.5 to 7.0.3 upgrade this weekend on the domain and post office servers, and wrote a quick script to backup the agent configuration files.  It’s not a pretty script, but I wrote it in about 10 minutes and it worked on all my Netware servers.  I call this script part I since it only deals with files affected by my upgrade, which are all located on the sys volume.  I upgrade the gateways in two weeks, so I’ll backup the configuration files in the domain directories then.

You need to set SERVERNAME, SERVERVOL, BKUPLOC and BKUPDIR. If I’ve missed any files, please let me know and I’ll add them to the list.

@echo off
REM script to backup Groupwise configuration files from Netware server
REM replace SERVERNAME with the name of your Netware/Groupwise server
SET SERVERNAME=\\grpwise4
SET SYSVOL=sys
REM replace SERVERVOL with the name of the volume to write the backup files to
SET SERVERVOL=vol1
REM SERVERPATH is combination of server and volume name in \\server\vol\ format
SET SERVERPATH=%SERVERNAME%\%SERVERVOL%
REM SYSVOLPATH is combination of server and volume name in \\server\sys\ format
SET SYSVOLPATH=%SERVERNAME%\%SYSVOL%
REM APACHEAPTH is sys:\apache2 Apache2 web server directory
SET APACHEPATH=%SERVERNAME%\%SYSVOL%\Apache2
REM NOVELLPATH is sys:\novell directory
SET NOVELLPATH=%SERVERNAME%\%SYSVOL%\Novell
REM TOMCATPATH is sys:\tomcat\4 directory
SET TOMCATPATH=%SERVERNAME%\%SYSVOL%\tomcat\4
REM BKUPLOC is the directory to save backup files to
REM this script has no error checking, so the directory's existance will probably matter
SET BKUPLOC=gw65bkup
REM BKUPDIR is the full path to the backup directory
SET BKUPDIR=%serverpath%\%bkuploc%
REM Create the backup directory
md %bkupdir%
REM copy sys:\system\ config files
md %bkupdir%\system
copy %sysvolpath%\system\*.mta %bkupdir%\system
copy %sysvolpath%\system\*.poa %bkupdir%\system
copy %sysvolpath%\system\*.waa %bkupdir%\system
copy %sysvolpath%\system\*.cfg %bkupdir%\system
copy %sysvolpath%\system\*.ncf %bkupdir%\system
copy %sysvolpath%\system\*.xml %bkupdir%\system
copy %sysvolpath%\system\*.bin %bkupdir%\system
copy %sysvolpath%\system\autoexec.ncf %bkupdir%\system
REM copy important Apache files
md %bkupdir%\apache2\conf
copy %apachepath%\conf\*.* %bkupdir%\apache2\conf
REM copy important Tomcat files
md %bkupdir%\tomcat\4\conf
copy %tomcatpath%\conf\*.* %bkupdir%\tomcat\4\conf
REM copy important Webaccess files
md %bkupdir%\novell\webaccess\conf
copy %novellpath%\webaccess\*.* %bkupdir%\novell\webaccess
REM copy important Groupwise NLMs from sys:\system
copy %sysvolpath%\system\dbcopy.nlm %bkupdir%\system
copy %sysvolpath%\system\ex*.nlm %bkupdir%\system
copy %sysvolpath%\system\gw*.nlm %bkupdir%\system
copy %sysvolpath%\system\ldap*.nlm %bkupdir%\system
copy %sysvolpath%\system\tsa*.nlm %bkupdir%\system
copy %sysvolpath%\system\scc*.nlm %bkupdir%\system
copy %sysvolpath%\system\vs*.nlm %bkupdir%\system
copy %sysvolpath%\system\wvc*.nlm %bkupdir%\system
copy %sysvolpath%\system\xg*.nlm %bkupdir%\system

Last Wednesday I updated one of my Netware 6.5.7 / Zenworks 7.0.1 servers, and rebooted it to make sure everything came us as expected.  Apache loaded fine, and when I went to http://serverIP, everything worked great.  But when I attempted to access iManager at  http://serverIP/nps/iManager.html, I received a 503 error from Apache.  The same results were observed when accessing the sites through https rather than http.

To fix this problem, I modified instructions posted by Baudizm.  You can find my comments enclosed in [ ]

On the server console I ran:

tc4stop   [stops Tomcat]

ap2webdn  [stops Apache]

java -exit  [stops Java]

pkidiag  [loads PKI diagnostic utility]

authenticate as admin equivalent user

[select pkidiag options] 4 – 5 – 6 – 0

tckeygen  [for LDAP]

tomcat4  [loads tomcat]

Ap2webup  [loads Apache web server]

After performing these steps, iManager loaded with no problem.

Additional Resources

TID 3377845 error 503 returned by applications that use Tomcat, is a good resource for fixing tomcat/tckeygen related problems.

TID 3640106, How to Use PKIDIAG to avoid issues while Installing Netware 6.5 goes into detail on how pkidiag works and how to troubleshoot vertificate problems.

TID 3234091 Tomcat4 does not load, talks about using Tckeygen to fix .keystore problems.

One of my educational clients is going to be implementing a fairly significantly sized wireless network this summer. The are an all Cisco shop – all Cisco data electronics, VoIP system, firewall, etc. The wireless access points will be Cisco, probably 1252s, which are wireless-G and support the draft specifications for wireless-N.

Their dilemma is this – Should they spend the money (~$9K per box) on the Cisco Secure Access Control Server Solution, or should they try to integrate FreeRadius into their Novell Netware 6.5 network and use the Novell client with Windows XP’s built-in 802.1x supplicant. They are balking at the cost of the Cisco Secure Access Control Server Solution because they don’t have the need (or desire) to implement any of it’s advanced functionality at this time – they just want the 802.1x authentication for the wireless clients.

I’m in the information gathering phase of this project right now, determining if the FreeRadius/Novell Client is a feasible option for their environment. I’m going to collect some information, and will post what I find out here in the upcoming weeks.

Links and Technical Reference Documents

Novell TID 3003857: Integrating FreeRADIUS and eDirectory

Novell TID 3009668: Setting up FreeRADIUS and eDirectory for 802.1X Authentication

Novell TID 3557425: Integrating FreeRADIUS authentication and eDirectory

Novell TID 10100693: 802.1x Authentication and the Novell Client for Windows

Novell TID 3218399: 802.1x Authentication and the Novell Client for Windows

Novell TID 3356920: Does the Novell Client support 802.1x?

Novell TID 3038019: Errors when logging in with 802.1x protocol

Novell TID 3777876: Registry settings related 802.1x support in the Novell Client 4.91 SP4

Novell TID 3950357: Unable to login using Cisco 802.1x implementation

Novell TID 3714126: FreeRADIUS, NMAS, and wireless (802.1x) Networks

Novell TID 10100993: Debugging FreeRADIUS with radtest

Novell TID 5008620: Novell Client 4.91 Post-SP4 802.1x Fixes (FTF)

Configuring FreeRADIUS on Open Enterprise Server for Linux by Eric Champagne

Enabling 802.1x in Client 4.91 SP4

Integrating Novell eDirectory with FreeRADIUS Quick Start Guide

Integrating Novell eDirectory with FreeRADIUS Administration Guide

Addendum to the FreeRADIUS Administration Guide

Configuring Novell eDirectory for 802.11 Wireless Authentication – Novell BrainShare 2005. Discusses using OES or SLES, FreeRADIUS or Cisco ACS with verification against eDirectory.

EDirectory integration with FreeRADIUS wiki on developer.novell.com

NTRadPing – free RADIUS testing utility

FreeRADIUS wiki

Client Updates

Microsoft KB 885453: XP SP2 PEAP authentication is not successful when you connect to a third-party RADIUS server (hotfix)

Microsoft KB 893357: The Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) update for Windows XP with Service Pack 2 is available

Microsoft KB 918997: Developers cannot create wireless client programs that manage wireless profiles and connections over the Wireless Zero Configuration service in Microsoft Windows XP Service Pack 2 (SP2)

Microsoft KB 931856: A Windows XP-based wired client computer will not obtain a valid IP address from a guest VLAN or from an “Authentication failed-VLAN”

Microsoft KB 917021: Description of the Wireless Client Update for Windows XP with Service Pack 2

Microsoft KB 923154: FIX: EAP reauthentication may not occur and the Wireless Zero Configuration service may not work correctly when you try to use a third-party application in Windows XP

Implementation Hints and Gotchas

• Verified that the Universal Password setup is correct on my test user with the Universal Password utility.
• An interesting discussion on 802.1x, EAP and LDAP configurations
• eDirectory and FreeRadius HowTo version 0

• If 802.1X authentication succeeds after the desktop is up and you are log in from the Red N but fails on the initial boot login, check to see if the Authenticate as computer when computer information is available check box on the Authentication tab of your Local Area Connection Properties dialog box is selected. This option must be selected for the initial login to succeed.

• Try toggling the “Use 802.1x authentication during subsequent eDir-only logins” setting
• Try changing supplicant mode to 3
• Configure a DA and scope in the client properties

• The Novell Client 4.91 SP4 for Windows XP/2003 includes an Extensible Authentication Protocol (EAP) plug-in to the Microsoft Windows XP supplicant, which lets users authenticate through RADIUS to wireless access points and wired switches for added network security. Using FreeRADIUS as the RADIUS server, users can authenticate to their local machines, to eDirectory, and to 802.1X with the same set of credentials for a single sign-on experience.

  When 802.1X authentication is enabled, the username and password entered in the Novell Login dialog box are first passed to the EAP plug-in module. An exchange of messages (PEAP/MSCHAPv2) between the Windows supplicant, the wireless access point/wired switch, and the RADIUS server allows network access if the correct credentials were entered. After the 802.1X authentication has succeeded, both the eDirectory and local logins take place just as they have in previous versions of the Novell Clients. If the 802.1X authentication fails, no access to the network is given, and the user will not be able to access the network.

  The 802.1x authentication feature supports both wired and wireless connections. Only password-based authentication is supported (the Novell Client 4.91 SP4 for Windows XP/2003 supports only PEAP with MSCHAPv2). Biometrics (non-password-based) authentication types are not supported with this release. If you want certificate support, the Microsoft EAP plug-ins are sufficient and no Novell-specific EAP support is required.

  The ability to browse for trees and servers in the Novell Login dialog box is not supported because the 802.1X port blocks all network access.

• If the authentication times out, check to see if the radius server is getting queried for the authentication. Also check to make sure the Validate server certificate check box on the Protected EAP Properties tab on the Local Area Connection Properties dialog box is not selected.
• If you think debug or trace logs will help, start Regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing and enable tracing for Noveap. This causes Windows to create a Noveap.log file in the windows\tracing directory.
• Utilities installed with many NIC cards can cause odd behavior. Make sure the user has only installed the drivers for the NIC card and none of the other utilities.

• If you still cannot get 802.1X to work, remove the Novell Client and try to get the Microsoft authentication working first. Pre-desktop authentication will not likely work in this case, but after the desktop is up, Microsoft uses the Windows username and password for 802.1X authentication.

  For this to work, the username and password for Windows must match the username and password in eDirectory.

  [updated 2008-11-17]
  Check out Jeremy’s cheat sheet, a good general reference for 802.1x.

I had a badly behaving Netware 6.5 SP7 server that absolutely would not allow clients to authenticate or connect. It ended up being a problem with a NIC driver gone wild, but I had to do some troubleshooting to determine that fact.

During the troubleshooting process I wanted to backup several directories before I altered their contents. I figured I’d just copy those folders to a safe location, but couldn’t remember how to do it from the server console. I had used the copy command from toolbox.nlm in the past, but of course toolbox wasn’t loaded on this server. I don’t use the BASH shell often enough to use it coherently, so I decided to look for an alternative shell.

I did a quick search and came across the Novell Script for Netware shell. To start the shell, from the server console type:

nsninit

and then

nsnshell

which should bring you to a screen with a prompt that looks like

SYS:\>

From that point I was able to use the copy command just like I would from a DOS command prompt, i.e.

copy sys:\system\dsr_dib sys:\system\dsr_dib2

To exit from the shell, just type exit

When the Groupwise GWIA gateway has problems sending or receiving mail, it’s often the result of a corrupt message clogging up a queue. The easiest way to troubleshoot the problem and restore mail flow is often to down the GWIA and rename the queue folders.

To accomplish this on a Netware server you can stop the GWIA and MTA by pressing F7. Once they have unloaded, browse to the domain\wpgate\gwia directory and rename the following directories:

• 000.PRC
• DEFER
• GWHOLD
• GWPROB
• RECEIVE
• RESULT
• SEND
• WPCSIN
• WPCSOUT

Restarting the GWIA and MTA will recreate these folders. If mail starting flowing again, you can bet that the cause of the problem was a bad message in one of the renamed folders. Move a few messages at a time from the renamed folders to their corresponding new folder. The message flow should continue until you find the corrupt message, which is often the oldest message.

Once the corrupt message is identified, delete it or move it to a different location. This should allow mail flow to resume as expected.

For additional details, see TID 10075205, TID 10054298 and TID 10008353.

In a worst case scenario you may need to delete and reinstall GWIA per TID 3674238. Don’t forget to apply any applicable patches.

I’m installing Zenworks 7SP1R2 today, and the customer did not provide the installation media.  I’m downloading the .iso’s from Novell as we speak, but don’t have access to any blank CDs to burn the image files.  I decided copying the .iso files to the server and acessing them directly would be the best solution.

TID 10095903 [via koolbeans] says starting with Netware 6.5 SP2, you can mount an .iso using nss:

nss /MountImageVolume=path_imagefilename

The above command will add and mount the specified CD or DVD image file as a read-only NSS volume.

nss /RemoveImageVolume=path_imagefilename

The above command will dismount and remove the specified CD or DVD image file as a read-only NSS volume.

The image file must reside on an NSS volume.

To mount an .iso on a Netware 6 server, see Alex’s cool solution tip:

1)  Copy your .ISO image to a directory on your volume.

2)  Load cdinst.nlm

3)  Type “cd image <volumes:Path to iso file\iso filename>”

4)  As the last step, type “cd mount <volume name>“
 

(When you don’t know the volume name of your image you can type “cd device list”   and check the volume name on the logger screen)

A task I was assigned today had to do with Novell eDirectory login scripts.  The only information the local admin reported that Windows 2000 users were getting login script errors when the script was trying to execute “c:\program files”.  He didn’t mention any more specifics about who was experiencing the problem, but he wanted the error(s) resolved.

The eDirectory tree is rather large at this site, and it contains many organizational units, each which have their own specific login script.  There are also some user login scripts, so finding this problem was going to be a fairly labor intensive (and monotonous) task, involving checking each login script for errors by hand.

I made it through reviewing about a dozen login scripts before I decided there had to be a better way to track down the root of the problem.  I did some quick searches and came across the NDS Login Script Editor 1.2.  It’s a free program written by Jeff Brusoe that can search or search & replace login scripts for users, organization containers, org units, templates, and profiles in NDS.

The installation was painless, and once I set my starting context I quickly searched for “program files” and came up with 9 hits almost instantaneously.  I could have had the program edit the scripts for me, but I chose to have the query results saved to a log file so I could manually change the scripts. 

I would guess this program saved me three or four hours worth of work.  If you need to make changes to login scripts, I would highly recommend using this Cool Tool.