Update #2 on random eDirectory network login problems and weirdness


Last week I wrote about the random login weirdness that plagued users trying to login to our Netware/Windows/SLES eDirectory network. It seems that uninstalling/reboot/reinstalling NICI on the affected workstations sequence did not fix the problem for all users.

Today I found that if I go into the Novell Client 4.91 SP2 properties, select the advanced tab, and set NMAS authentication to off, I can login after rebooting, without uninstalling/reinstalling NICI. We don’t use NMAS right now anyway, so this isn’t too inconvenient, but I’d like to get to the bottom of this issue sooner or later.

9 Responses to “Update #2 on random eDirectory network login problems and weirdness”

  1. koolbeans Says:

    Hello.

    I had a similar problem a couple of years back with a NW6 SP3 network, as it turns out certificates were broken, had to run pkidiag to find which servers didn’t have access to which certificates.

    Maybe that helps, maybe not. Either way, thanks for keeping up such a good blog!

  2. Julie Says:

    My initial thought was that certificates were part of the problem, so pkidiag was what I tried first when troubleshooting this issue. I even tried the latest FTF version 2.78.02, but I received the same results. Updating to Security Services 2.0.4 didn’t fix the issue either.

    Thanks for the suggestion, I’ll let you know if I find the solution! Julie

  3. Michael Says:

    Hey Julie and other,

    We too are having this random issue pop up. I have experienced it before at my old job, but we just turned off NMAS on every workstation, wasn’t used. But here, we’re had the random problem where users could not log onto server 1, but could server 3. I remember this NMAS issue and did a test on one of the users having the problem. Sure enough it resolved it, but why? Later on I tried to replicate the issue and with NMAS on, they were able to log into server1. Think it might be a traffic bandwidth issue? Only becomes an issue when there is a lot of traffic?

    Let me know,
    Mike

  4. Julie Says:

    Mike,

    That’s an interesting theory. The particular network I experienced this issue with was fairly small and I wouldn’t think they had traffic issues, but I don’t have the data to back that up. Let me get ahold of the local admin and see if he can pull some stats from that problem time, and I’ll follow up if I make any headway.

    Incidentally, did you enable logging on the Novell client to see if it showed anything odd happening?

    Thanks

    Julie

  5. Julie Says:

    Mike – I followed up on your theory, and here’s what my friend Scot, a CNE at a large university had to say on the subject (slighly edited):
    ***********
    I actually saw this problem on a new tree that we use to support campus satellite sites.. and since the sites were t1 – we thought it was a bandwidth issue… turns out it wasn’t

    It was an slp issue– What I did was basically start from scratch with slp– make 2 of the servers DA’s and pointed the rest of the servers to the DA’s

    then on the client end we added the slp servers in the advanced properties (we can do that because we image)- and never saw the problem again

    For some reason–if I ever have login issues at all.. I suspect SLP. I have been known to look into this value

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWSLP\parameters]
    “Wild Card Last Level Only”=dword:00000001

    and change it from 1 to 0 — 1 is a lot faster login but often leads to problems like login failures — 0 is a slower login prompt- but makes sure the slp is connected

    My bigger questions is– under the login client properties– when you are logging in– do you use the server name or IP address.. does it ever fail with a server’s ip address?

    The reason I ask– if it never fails with server IP address then for sure you have an slp problem.
    ******************************

    Also see TID 10080035 for more details – Julie

  6. Michael Says:

    Hmm, well we hadn’t looked at SLP, we’ll look at that. We have contextual resolve working, so some of our users don’t put a server in at all, other do. When they do, they use the server name. I too thought of that and tried putting the IP address in. It was still a no go. Since the 18th we havn’t had this problem show up again.

    Interestingly we have a Zenwsimport issue where the import server will max out our NW6.5 Sp6 server’s utilization to 100%. I do a java -show and it’s the only thing using java. I look at the Busiest thread and java is the top. If I unload zen ws import by either doing a zfdstop or a java -exit or a java -killall it brings the server back to normal utilization. I can then start zen ws import again. It’ll work for a while then max out again.

    I had thought that this was a contributing factor to the other issues with the NMAS, but I can’t tie them together.

    Mike

  7. Mike Says:

    Well I installed the HotFix 6 for Zenworks and sure enough that resolved the issue. Even though the list of “Fixes” that Novell listed has nothing to do with this, it still resolved it. It must be the Novell Way…lol

    Mike

  8. Bob Says:

    NMAS Logins require the client/server to access the Security container which is held at the root of the tree.

    Maybe your root servers are overloaded with traffic or there is a timeout trying to connect to them.

    One possible fix is to partition and replicate the Security container out to the remote sites/servers.

    This was supposed to have been fixed in eDir 8.8 with the Security Container caching, but I think what the fix actually delivered doesn’t help after all.

  9. Lionel Says:

    The security caching stuff in SS205 and eDir 882 does not work due to External References not supporting ACLs. Therefore the dependency on cn=Security remains – no plans to address this.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: