Overview#The EDirectory NetworkAddress has an OID of 2.16.840.1.1137184.108.40.206.1.55 and is one of the Login Attributes For eDirectory NMAS logins.
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.
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.
- 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.
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 exist in these processes, though. This is heavily version (EDirectory 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.
- Client32 - Logout Process events sometimes 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.
- 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 backup, 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..
- 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.
- 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 attribute 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.
- define _RPC_NONE 0
- define _RPC_NETPATH 1
- define _RPC_VISIBLE 2
- define _RPC_CIRCUIT_V 3
- define _RPC_DATAGRAM_V 4
- define _RPC_CIRCUIT_N 5
- define _RPC_DATAGRAM 7
- define _RPC_UDP 8
- define _RPC_SPX 9
- define _RPC_IPX 10
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 8.8.1 (Linux and Netware) that the 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 NWDSOpenMonitoredConn. Ldapsearch for Networkaddress.
Some other infromation#
- Populating and Clearing Network Addresses
- Network Address Schema Documentation
- Network Address Syntax Documentation
- Network Address Types
More Information#There might be more information for this subject on one of the following:
- Ldapsearch Networkaddress
- Login Attributes For eDirectory NMAS logins