Unknown RADIUS client errors

Question

We are running Novell Netware 6.0 SP4 and eDirectory 8.6.2. We have set up
iChain 2.3 with the included NMAS and RADIUS services. iChain with NDS
password authentication works properly. Now we are trying to add token
authentication, and it is not working. The RADIUS screen keeps showing
"Access Request Dropped", "<ip address>, <user>, Unknown RADIUS client".
I have turned on debug mode, refreshed the cache, tried logging in again,
and checked the debug file. The error I am getting I have not seen
referenced in previous newsgroup posts. The important section shows this:
Context Lookup List set to:
[2004-08-05 09:42:21 AM] 1) DEN.RJL
[2004-08-05 09:42:21 AM] 2) RJL
[2004-08-05 09:42:21 AM] Number of contexts = 2
[2004-08-05 09:42:21 AM] tag extracted: 10.1.1.242, size: 11, tagLength: 22
[2004-08-05 09:42:21 AM] (->)NDSSetUpClientTable(DAS_RJL.RJL) failed, no
such entry (-601)
[2004-08-05 09:42:21 AM] Cache: Error from NDSSetUpClientTable: failed, no
such entry (-601)
[2004-08-05 09:42:21 AM] Cache: Successfully set up client table
It looks like it is not reading the client table properly, but I don't know
how to fix it. We have recreated the DAS object, removed and re-added the
client address in the DAS object, etc.
If anyone has any ideas on what else we can try, I would really appreciate
it. Thanks.

Answer 1

You should always administer NMAS from a Windows workstation, Unfortunately
you can't administer NMAS, and therefore NMAS RADIUS, on any other platform
right now. The NMAS ConsoleOne snapins make native calls to nmaswrap.dll,
and this module is only available on Windows.
You can map a drive to your server from a Windows box and run ConsoleOne
from the mapped drive to see if this works. However, for best results with
RADIUS, you will want to install ConsoleOne locally on a Windows box. When
run over a mapped drive, the RADIUS snapin can take a very long time (5-15
minutes in my experience) to load the RADIUS attribute file.
You mentioned that you've been running ConsoleOne from a workstation, so I
assume that you've tried setting the DAS client information from a Windows
box already. If you have not tried this yet, then please do so.
The -601 you're getting from NMAS_GetLoginConfig is interesting.
Unfortunately this method is implemented in NMAS.NLM, which is maintained by
a different team, so I'm not sure how much more help I can provide with
this. However, I do have a few ideas:
1) When RADIUS calls NMAS_GetLoginConfig, its asking NMAS to read encrypted
data that is stored in attributes on the DAS object. If I remember
correctly, NMAS.NLM cannot go off the box when it does this. Does your
RADIUS server have a local replica that contains the DAS object? If it does
not, then this might be your problem.
2) If putting the DAS in a local replica does not work, then a DS Trace with
the NMAS and Resolve Name options turned on may provide some insight. (I
can't remember if NMAS is a DS Trace option in eDir 8.6 - if you don't see
the NMAS option, then don't worry about it.) Start DSTrace while RADIUS is
running and issue a "radius refreshcache" command like you did before.
If neither of the above suggestions is helpful, then tell the support
engineer you're working with that the -601 error is coming from
NMAS_GetLoginConfig and which version of NMAS.NLM you have. Please also tell
the support engineer that you've been working with me (Scott Kiester) on
this, and that he/she may call me they have any questions.
>>> Stephen Taylor<[email protected]> 08/06/04 12:38 PM >>>
Hi Scott,
Thank you for the follow-up. Based on suggestions from some of your other
posts, I had already run ConsoleOne with the debug window, and I did not
see
any errors when I added a DAS client. I ran the SDIDiag utility and went
through the three recommended steps. There were no errors, and the tree key
looked the same on all our servers. I did not know about the NMAS log file.
I followed your directions, and this is all that the log file shows:
0: Screen and file output started at Fri Aug 6 10:49:53 2004
GetLoginConfig: -601
NMAS_GetLoginConfig: -601
Based on a couple of other posts, I decided to try deleting the DAS object
and recreating it using ConsoleOne from the NMAS server instead of from a
workstation. It asks me for the password when creating the object, then
immediately abends the serve and locks up ConsoleOne. This has happened
three times now, even after reloading the snap-ins. I don't know what to
try
next. We have run dsrepair and it runs cleanly.
"Scott Kiester" <[email protected]> wrote in message
news:_uOQc.4698$8%[email protected]...
> Hi Stephen,
>
> Based on the log snippet that you posted, it appears that an NMAS call is
> failing and returning the -601 error. NMAS RADIUS makes a call to NMAS to
> obtain the client shared secrets because NMAS will encrypt them before
> storing them in eDirectory. It looks like your server is able to read the
> client IP address off of the DAS object, but is unable to obtain the
> corresponding shared secret from NMAS.
>
> I can think of a couple of things that might cause this:
>
> 1) Perhaps ConsoleOne is not storing the shared secret. Unfortunately,
the
> ConsoleOne snapin will not report errors it encounters while storing
entries
> in the client table. ConsoleOne must make an NMAS call to store the
shared
> secret, and if this call fails it will not report the error. You can
usually
> tell if this call failed by closing the DAS "Properties" dialog and
> re-opening it after adding a new entry. If your new entry is not there
when
> the dialog is re-opened, then the call failed.
>
> To find out if this call is failing, please start ConsoleOne with the
> following command line: "consoleone -debug -windowout". This will make
> ConsoleOne display a debug window in the top-left portion of your screen.
If
> an error occurs when you add a DAS client, you will see an error code and
> stack dump in this window. If this happens, please post the error code
and
> stack dump.
>
> Problems with the tree key are the most common reason for this call to
fail.
> You can resolve tree key issues using the SDIDIAG utility, which is
> available from the support site.
>
> 2) It is unusual to get a -601 ("object not found" - this is _not_ the
same
> as "attribute not found") error when RADIUS attempts to make this NMAS
call.
> RADIUS must set up and log in a new DS context before it calls NMAS here.
> It's possible that this is where the failure is, but I think it's
unlikely.
> The -601 error is probably coming from the NMAS call. If you determine
that
> ConsoleOne is storing this data properly using the instructions in step
1,
> then it would be helpful to see a log file from NMAS when this call is
made.
> To get this log file, please do the following:
>
> A) Load RADIUS and provide the DAS name and password
> B) At the server console, type "nmasmon * sys:\etc\nmasmon.log"
> C) At the server console, type "radius refreshcache"
> D) At the server console, type "unload nmasmon"
>
> This will cause NMAS log information to be written to
sys:\etc\nmasmon.log.
> Please post this file here, or send it to me at [email protected].
>