Cougie Absent Member.
Absent Member.
229 views

Do people have issues with NMAS in OES client?

I remember about 5 or 6 years ago I decided that whenever I install Novell/OES client for Windows, I would deselect NMAS during the installation.
That was because I had previously encountered dozens of DIFFERENT issues with NMAS and all these issues were seemingly resolved by uninstalling (or not including) NMAS.

OES client has since seemingly performed well for all of my clients and myself after all these years.

Today I decided to update OES client to the latest version (SP4 IR12) on my PC.
So I thought: Heck let include NMAS and see what happens.

Lo and behold, after the reboot I couldn't type my password. The OES login screen did not accept any keyboard input.
I rebooted several times with not success.
I then did a remote desktop into this my PC from another PC, reinstalled the latest OES client without NMAS and it's immediately fixed.

Now I don't remember whether I've encountered this particular keyboard/login issue all those years ago. But I do remember it was a lot of different issues and scenarios.

This has reminded me why I hated NMAS so much all those years ago and I shall continue to not include it in future installations.
Labels (1)
Tags (1)
0 Likes
1 Reply
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Do people have issues with NMAS in OES client?

On 05/19/2019 09:34 PM, Cougie wrote:
>
> I remember about 5 or 6 years ago I decided that whenever I install
> Novell/OES client for Windows, I would deselect NMAS during the
> installation.
> That was because I had previously encountered dozens of DIFFERENT issues
> with NMAS and all these issues were seemingly resolved by uninstalling
> (or not including) NMAS.
>
> OES client has since seemingly performed well for all of my clients and
> myself after all these years.


I worked in the Support organization on the eDir/NMAS stuff for the better
part of a decade; in that time I had a lot of these types of issues
reported, and helped customers go either way, either remove the NMAS
client because they "hated it", or helped them add it back, because they
didn't want to need to manually disable and/or uninstall it. This was the
base way back in the Novell Client 4.9x days, and in every case whee the
customer wanted to put it in we found the problem that prevented it from
working in the first place, and it was almost always a configuration issue
or a really odd environment issue.

> Today I decided to update OES client to the latest version (SP4 IR12) on
> my PC.
> So I thought: Heck let include NMAS and see what happens.
>
> Lo and behold, after the reboot I couldn't type my password. The OES
> login screen did not accept any keyboard input.
> I rebooted several times with not success.
> I then did a remote desktop into this my PC from another PC, reinstalled
> the latest OES client without NMAS and it's immediately fixed.


I've never seen the presence of the NMAS client, on any version of the
Novell or OES client, prevent the keyboard from working; that's just not
what it does. I'm not saying it's not related or you're crazy, but there
is some other combination of things that is likely causing your symptom.

I have also never added the NMAS client during an upgrade as a way to
reintroduce it; Every time customers added it back it was just as its own
operation, so maybe that is worth trying. Better yet, make it a clean
install, maybe even on a clean windows box, to see how it can really work.

> Now I don't remember whether I've encountered this particular
> keyboard/login issue all those years ago. But I do remember it was a lot
> of different issues and scenarios.
>
> This has reminded me why I hated NMAS so much all those years ago and I
> shall continue to not include it in future installations.


I'd guess there is something else strange with your box/build. NMAS has
been a default, and in my experience a left-alone default, since at least
the 4.x clients, and it should be used as it provides better security
(case-sensitive passwords), and even if NMAS is not configured on the
server side the client can still fall back on the NDS password.

Most of the server-side issues I remember preventing logins in the pat
were something strange in how the NMAS login methods were configured per
user. NMAS, as its full name implies (modular authentication services),
can do a lot more than just standard passwords, and if the configured
method on the user somehow was set to something odd it would prevent the
client from being able to work with the server.

Client: "Hey server, here's a username/password to do a password-based login."
Server: "This user is required to use a smart card too."
Client: "I don't have one of those."
Server: "Tough cookies."

The client's doing what it is told, the server's doing what it is told,
and the connection fails, but without NMAS it works.

Client: "Send me this user's public key."
Server: "Here you go."
Client: "Here's the hashed/encrypted/whatever thing that results from that
key and the password."
Server: "Okay, you're in."

Another test you may want to try is verifying NMAS works generally without
the NMAS client built into the OES Client for windows. If your eDirectory
is even remotely current then every bind you do via LDAP likely uses NMAS
to do the password authentication. If you are using Universal Password
(UP) successfully (meaning the complexity requirements are enforced when
changing passwords) then that also uses NMAS as the underlying technology
for UP. In the case of anything LDAP-based, the NMAS client is actually
on the server itself (as part of the LDAP interface and eDirectory). If
any of that works, NMAS isn't the problem, but something about the windows
system likely is. In your case, with such an odd symptom, I'd probably
guess "definitely is" is more likely.

You can verify this use of NMAS using ndstrace, perhaps using the
following steps:


ndstrace
set dstrace=nodebug
dstrace +time +tags +nmas +ldap
dstrace file on
set dstrace=*r

#perform login via LDAP

dstrace file off
quit


By default the /var/opt/novell/eDirectory/log/ndstrace.log file should
have anything captured. If you ass lines with 'NMAS:' in them, those
should be your login (or other logins happening at the same time). This
same method can be used to capture NMAS-related things from the OES
Client, but the trick there is getting your client to point to this
server, and in some environments the client may just want to talk to
another server, so you may need to run this on multiple servers
simultaneously to capture wherever the client connects.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.