jspωiki
EdirectoryLoginUpdate

Overview#

The Problem with eDirectory UpdateLoginAttributes:

Login update is becoming a major bottleneck at sites with large dibs, heavy LDAP authentication and many modifies being done to user objects on login by applications.

At Some Client, far example, without the lastLoginTime being populated one of their in-house applications is broken. However, if enabled, LDAP services become unresponsive. They are also very worried about accounts not getting locked after so many password tries.

We have been simply advising customers to turn it off since when disabled, performance is so much better. However, many customers are unable to disable it since this also disables populating intruder retries. Without this attribute they cannot lock an account after so many failed authentications.

Most agree there is a problem with UpdateLoginAttributes and a complete re-wite may be called for in the future. That said, NTS believes a complete rewrite of this should be, at least initially, persued in a latter version of edir rather than in a 873 support pack.

A compromise to all or nothing in populating the attributes might be to granularize the attributes that are populated. In this way a customer could turn off UpdateLoginAttributes for all attributes except for intruder retries. This would, in theory, give much of the performance enhancing qualities of disabling the function while allowing Banks for instance to still enforce account locking.

I understand the backend code to be modified would not be a big deal - it is more work in the interface. I suggest not spending any time trying to make it pretty. We could simply add up the values for the attributes to be enabled (like with the bindery mask) and input their hex sum into an attribute, say on the pseudo-server.

Comments


Comment #1 From Chuck Castleton 2006-12-18 09:44:17 MST reply ------- Private

Steve - Do you have another defect related to UpdateLoginAttrs? This is related. We'll discuss what to do with it.


Comment #2 From Build Automation 2007-05-14 04:40:20 MST reply ------- Private

Build Automation Message eDirectory Version: 873_SP9_ftf Build: 20070514_043307 Task/Rev: nds#168433


Comment #3 From Build Automation 2007-05-14 21:54:51 MST reply ------- Private

Build Automation Message eDirectory Version: 873_SP9_ftf Build: 20070514_211517 Task/Rev: nds#168778


Comment #4 From Hines Vaughan 2007-05-15 08:37:43 MST reply ------- Private

Ran some tests with and without the build given to me by Dave. It works beautifully with the exception of updating the revision attribute on a user after a successful login. Since no other attribute is getting updated there is no reason to do this. Working with Paul on another issue I mentioned this and he checked in a task to eliminate revision updates on success. Another build was to be made yd afternoon for chemckin to 8739FTF2.


Comment #5 From Dave Wilbur 2007-06-01 16:22:27 MST reply ------- Private

Fixes checked in with tasks 168433, 168769, 168774, 168778, 168779, 169163

These include the ability to disable the updating of login attributes, build fixes and the eliminating revision updates when no updates are taking place.


Comment #6 From Build Automation 2007-06-05 06:51:48 MST reply ------- Private

Build Automation Message eDirectory Version: 873_SP9_ftf Build: 20070605_060814 Task/Rev: nds#169163


Comment #7 From Hines Vaughan 2007-09-11 16:48:13 MST reply ------- Private

Scott has been working with St. John and found the FTF3 is still updating attributes on a successful login. Just tested Windows and it works. Scott will test on Linux and add a remark.


Comment #8 From Steve Eaton 2007-09-13 09:26:08 MST reply ------- Private

One thing I wanted to get clarification on from this defect. NMAS updates login attributes also. Are we sure that the client in question did not login via NMAS thus explaining why it works for us, and not for them ?


Comment #9 From Jim Schnitter 2007-09-24 10:28:35 MST reply ------- Private

Changed priority of every Sprint 7 defect to 100.


Comment #10 From Hines Vaughan 2007-09-26 13:38:28 MST reply ------- Private

I am marking this fixed. NMAS was indeed the culprit. Further, Hal gave me the undocumented ability to provide the same functionality even with NMAS enabled until they can use the same thread.


Comment #11 From Baha Masoud 2007-12-18 15:42:02 MST reply ------- Private

Closing this bug since the eDir 8.7.3 part has been fixed and verified. The other part of this bug is in the NMAS product.

WARNING: This bug is visible to non-employees. Please be respectful and do not include sensitive information in your comments.

Jim Willeke to Craig Winberg: We ran into some confusion here. If we look at TID 3479868

It implies this was fixed in: "Novell eDirectory 8.7.3 SP9 FTF2 for All Platforms Novell eDirectory 8.8 SP2 for All Platforms"

Are we missing something ?

1/16/2008 11:11:19 AM Craig Winberg - The TID was a work-around created by a WSS engineer who went down to Australia on a large bank roll out. He bypassed the root issue. We fixed the root problem. The section of code we are playing in has always been messy. Several developers have looked at it over the years, but it was so twitchy, they always avoided it. While working the issue, we also identified many other bottlenecks that slow ldap response.

The TID author was my original contact for this problem way back last December. I pissed him off to the point that he would not respond..kinda funny actually. Paula Gephart, Steve Eaton and my self duplicated US Banks tree in the Provo Superlabs, then created perl scripts that duplicate the bank ldap traffic. We went through 24 debug builds of NDS before Steve had a handle on what was taking place. He found many choke points in this section of code. The "updateloginattr" was just one of the issues slowing nds. There were also problems when a user enters bad password when the connection table is large. We handled things in a "serial" method.....very very slow. One process actually put a 200ms delay when the server was busy.....makes perfect sense....when you get busy, go to sleep for 200ms. Thats more like the logic used by my teenager. Steve thought this was an attempt to control memory use.

Steve split the update login attr process into a table that is cleared when the server is not busy. Before, it could block, or delay ldap binds for extended periods of time. He also made some of the code multi-threaded, so instead of setting a 200 ml delay, we start additional threads to aid.

We (Novell NDS Developer) went through 24 debug builds of NDS before he had a handle on what was taking place. He found many choke points in this section of code. The "updateloginattr" was just one of the issues slowing nds. There were also problems when a user enters bad password when the connection table is large. We handled things in a "serial" method.....very very slow. One process actually put a 200ms delay when the server was busy.....makes perfect sense....when you get busy, go to sleep for 200ms. Thats more like the logic used by my teenager. The developer thought this was an attempt to control memory use dating back to NLM and fixed memory days.

The developer split the update login attr process into a table that is cleared when the server is not busy. Before, the process could block, or delay ldap binds for extended periods of time. He also made some of the code multi-threaded, so instead of setting a 200 ml delay, we start additional threads to aid.

Category#

eDirectory

More Information#

There might be more information for this subject on one of the following: