(Fwd) [OpenAFS] WinNT/2000 with NetWare client, password problem

[Brent Putman]

Thanks for the suggestions.  I tried re-applying SP6a for NT 4, but that didn't
help.  Actually, all my previous testing had been with manually obtaining tokens
using the toolbar utility, I had not enabled the integrated logon option.  I
tried enabling that option and created an AFS user with the same userid and
password as is used for the NT/NetWare logon, but no luck: during the login
process I get a dialog with the error "Integrated login failed: password
incorrect".  This userid/password also doesn't work with manual logon.  This
account (indeed all AFS accounts) works just fine from Solaris and Linux
clients.

So you are using the commercial IBM/Transarc client, not the OpenAFS one?  Are
there any differences between the two, I wonder - system libraries, API calls
used, etc?

--Brent


"Cameron, Frank" wrote:

> We're using various versions of the Novell client (4.5 through 4.8) with the
> IBM AFS client 3.6 (patch1 and patch2) and have not seen this behavior.  Are
> you able to manually obtain tokens after logging in?  If you haven't tried
> (re)applying SP6a for NT or SP2 for 2000, try that.
>
> -frank
>
> > From: Brent Putman <putmanb@georgetown.edu>
> >
> > On a machine with the NetWare Client installed (vers. 4.7 and
> > 4.8), when
> > trying to obtain an AFS token, I'm getting an error:  "The AFS Client
> > was unable to obtain tokens as <userid>  in cell <my cell
> > name>.  Error
> > 62 (password was incorrect)."  No valid AFS userid/password
> > combo works.
> > (Yes, I have verified the correctness of the passwords being
> > used *many*
> > times....)  The client *does* seem to be communicating
> > properly with the
> > cell's kaserver.  For example, if an invalid userid is input as the
> > username, the following error is returned instead:  "Error 8 (user
> > doesn't exist)".  Also, the client is still able to map drives to
> > directories in the AFS file space which have the ACL
> > "system:anyuser rl"
> > set without first obtaining a token.
> >
> > If the NetWare client is removed, the OpenAFS client
> > functions properly
> > and valid accounts are able to obtain tokens without the
> > password error.
> >
> > I suspected it had something to do with the NWGINA.DLL used by the
> > NetWare client somehow screwing up the password that is used
> > to generate
> > the key for the Kerberos/AFS credentials.  However, replacing
> > NWGINA in
> > the Registry config with the MS standard MSGINA.DLL did not solve the
> > problem.
> >
> > Has anyone else seen this and know of a solution or workaround?  We're
> > actually contemplating a campus-wide replacement of all NetWare file
> > services with OpenAFS (on Solaris), and we might have a need for
> > coexistence of the 2 clients during the migration period.  Thanks for
> > any insight you can provide.