Novell NetworkAddress


How the NetworkAddress works#

Are you looking for how it works? Or how it's supposed to work?#

They are not the same and there have been many issues over the years and with different Client revisions.

NDS Connections#

Is Novell NetworkAddress attributes set when a user logs in from a Novell (NDS) connection?#

Yes. The actual setup of this is based on the concept of "monitoredconnections". When Client32 logs in, part of that is to call the "start monitored connection" NCP verb. This normally uses the Message Server, but can use any server that has a writable replica of the user object. This also populates the Network Address attribute on the user object.

The monitor server sets up a table internally of all of the connections that it is monitoring. This is kept on disk, so that if the server goes down, and comes back up, it will recheck all of the connections it was monitoring to see if they're still around.

When is the value changed or cleared when it is a NDS connection?#

Changed? Never.

Deleted - this is supposed to happen on logout. The logout code calls the "stop monitored connection" NCP verb, which tells the monitoring server to clear Network Address value "xx.xx.xx.xx" from the User object that is logging out.

This is assuming you have not changed the default behavior by modifying the SasUpdateLoginInfo values.

The "watchdog" should also clear the Network Address value for a user that has not logged out but that has turned their machine off. Watchdog checks the current monitored connection address to see if the machine is still up. If it's not able to ping the address, the address will be cleared. This does *not* check to see if it's the same user that logged in, though, so if some other user is now logged in and that address is available, watchdog will consider the connection still to be in use.

If the user reconnects from an address that is currently in the Network Address list, then when they log out from that address, it will be cleared from their user object.

LDAP Connections#

Is this attributes set when a user binds with LDAP (at least for 8.7 and 8.8)?#

Maybe. If the LDAP server has the user object locally, it *may* not populate Network Address. If the LDAP server does not have the user object in a local replica, it *does* populate the Network Address. This is done via the client code on the server that is used to log in against a remote replica to verify the user's password.

Also remember most LDAP applications do not leave the bind open so it is a bind/unbind within seconds.

When is the value changed or cleared when it is a LDAP connection?#

Assuming it was populated (see above), when the LDAP connection is unbound, the Network Address should be cleared.

Bugs and Other Issues#

Bugs exist in these processes, though. This is heavily version (eDir and Client32) dependent, and I have seen many bugs fixed in this area so far, but there are still at least three that I have seen.
  1. Client32 - logout events some times reference a network address value that is different from the one that is stored on the User object. The monitor server doesn't see the specified value, so it doesn't remove it. This leads to stuck Network Address values.
  2. Client32 - related to #1, but easier to cause. Client32 does not keep track of IP addresses. If you do something like put the machine to sleep, then bring it back up, and it picks a new IP address to use, you will try to "logout" from the "wrong" address. This can lead to stuck network Address values. You can also produce this effect using wireless networks and VPNs so that your user logs in from VPN1 / ip address xx.yy.zz.zz and then wanders over to VPN2 / ip address aa.bb.cc.dd..
  3. LDAP binds - if you have maximum concurrent connections, and multiple LDAP servers that do *not* have local replicas of your users, you can eventually stick all of the various LDAP server IP addresses on your user objects by simply bind/unbind in a loop. The only solution to this is to ensure that maximum concurrent connections is set to a value greater than the number of LDAP servers.
  4. There's one more bug that I know of, but it should be resolved by now. The newer (4.9 and newer) clients ship with NMAS. The NMAS login bypasses the traditional login code. This also bypassed the start monitored connection code, so no monitored connection was established and no Network Address attibute was created on the User object. As early as BrainShare 2004, the Client and NMAS guys knew about this, and were supposed to fix it. Since there have been a couple of Client revisions since then, I'm guessing that this has been fixed by now, but I have not actually confirmed this to be true.

Thanks #

Thanks to David Gersic(dgersic_@_niu.edu) and Others for their contribution on this work.

LDAP My Observations (2006-12)#

Observations show that on eDirectory (Linux and Netware) that the Novell NetworkAddress attribute is NOT populated unless there is no replica containing the user entry.

Even when the server does not contain a user replica for the user entry, the IP Address that is populated is the IP address of the server, not the LDAP client address.

Other people implied this is the same if the user is authenticated using CIFS.

Networkaddress Anomalies#

Some Networkaddress Anomalies


NOTE: NMAS connections apparently bypass this code.

If an application relies on the workstation being logged in, NWDSOpenMonitoredConn can be an effective API to use. It will fail if the workstation is not logged in and it will always return a connection to a server with a read/write replica to the logged in object. This will be a performance enhancement if the application is going to work with the logged in user object.

What is a monitored connection ?#

NWDSLogin creates a 'Monitored Connection' so DS can track such things as concurrent logins of the same user from multiple sessions or workstations, and login time restrictions, etc. This allows DS to let a user authenticate to as many servers as needed without breaching the concurrent login restrictions. Because NWDSLogins are relative to a NDSTree, the 'Monitored Connection' created is relative to the NDSTree. A workstation (user) therefore will have a 'Monitored Connection' for every tree it is currently logged into.

However, with the NMAS login methods, like Universal Password, this call is typically bypassed.

Some other infromation#

More Information#

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