WO2001014989A1

WO2001014989A1 - Architecture for a network management service which identifies and locates users and/or devices within an enterprise network

Info

Publication number: WO2001014989A1
Application number: PCT/US2000/022897
Authority: WO
Inventors: William Joseph Nelson; Mark Richard Roy
Original assignee: 3Com Corporation
Priority date: 1999-08-23
Filing date: 2000-08-18
Publication date: 2001-03-01
Also published as: AU6792300A

Abstract

A system and method for associating a user identity with a network address is disclosed, which includes a number of login listeners (10), a user tracker server (14), and a meta-directory (30). The login listeners each monitor one or more communication networks to detect login and/or logout events, including a login name, network address, and confidence index value associated with the session. Upon receipt of a login or logout notification from a login listener (10), the user tracker (14) stores the login information into a meta-directory (30). The meta-directory includes user entries which each associate MAC and IP addresses, as well as other login information (12), with fully distinguished user names. The meta-directory (30) may subsequently be used by a policy management system to obtain any one of the MAC address, IP address, or user name within a given user entry, by way of a request containing one of the other two associated elements. In this way the meta-directory (30) may be used to determine a specific user for a given IP or MAC address, or to determine a MAC or IP address associated with a particular user. As a result, user specific network management policies may conveniently and efficiently be supported.

Description

TITLE OF THE INVENTION

ARCHITECTURE FOR A NETWORK MANAGEMENT SERVICE WHICH

IDENTIFIES AND LOCATES USERS AND/OR DEVICES WITHIN AN

ENTERPRISE NETWORK

CROSS REFERENCE TO RELATED APPLICATIONS

N/A

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

N/A

BACKGROUND OF THE INVENTION The present invention relates generally to communication networks, and more specifically to a system and method for associating a user identity with a network address .

The complex maintenance, configuration and troubleshooting requirements of computer networks and communications systems are often the responsibility of a person known as the network manager. Various automated tools are available to assist network managers, and are referred to generally as network management systems. The guidelines followed by network managers with regard to allocation of network resources and services are referred to as network management policies. Network management policies, for example, define how devices are to be configured, and/or which users or devices are authorized to use which network resources, and the relative priorities of various users or devices.

A network manager frequently needs to map a particular network address, such as a Media Access Control (MAC) or Internet Protocol (IP) address, to a specific user in order to trouble-shoot network and/or security policy related problems. In existing network management systems, a network manager can associate different network addresses with each other, and thereby support network management policies based on such associations. Such existing systems do not, however, automatically provide information to the network manager regarding the identity of a particular person who is using an IP address. This prevents the network manager or network management system from conveniently supporting network management policies that are based on user identities. Moreover, many existing systems collect data regarding network addresses by periodically polling devices on the network. Accordingly, such collected data can be as old as the polling interval, and therefore reflect a less than current view of the network.

Thus it is apparent that these types of existing network management systems provide little support for a network manager trying to map a particular user to a network address. This fundamental problem is exacerbated by current trends. For example, dynamic IP address assignment via the Dynamic Host Configuration Protocol

(DHCP) and Remote Authentication Dial In User

Service (RADIUS) is becoming more commonplace, as are routers and firewalls which perform Network Address Translations (NAT) . Therefore, individual IP addresses are becoming more unlikely to be statically associated with specific users. These trends make it difficult for a network manager to identify a user given only an IP address .

MAC addresses are also becoming less likely to be statically mapped to a specific user. This arises from the fact that the number and kind of network access devices available to any given user is rapidly increasing. It is becoming more and more likely that a single user will use many different machines having network access during the normal course of his or her day-to-day activities. In addition, some devices have multiple network interface cards (NICs) and, accordingly, have multiple MAC addresses. Furthermore, some devices are set up in public locations such as libraries or visitor offices. In these cases, the MAC address of the device is not assigned to a single user, but rather is shared across multiple users. Additionally, workstations using the UNIX operating system are inherently multiuser, allowing different users to log on from remote systems. For these reasons, maintaining a static mapping of MAC addresses to individual users is problematic.

Some existing systems have attempted to address these issues by dynamically reconfiguring the IP address initially used by a particular user to a predetermined IP address associated with that user responsive to the user logging in to a particular server or set of servers within the network. As a result, the network management system becomes an active part of the process a user must follow to log into a particular network service. This solution introduces complexity, delay, and additional potential for failure into the login process. Moreover, such solutions only apply where the user logs into a specific, predetermined network service. Other existing systems have attempted to associate user names with dynamically served DHCP IP addresses through a set of modified DHCP servers. However, since a user may at times use statically assigned IP addresses, or may receive an IP address from a DHCP server that has not been appropriately modified, this is an incomplete solution at best.

Without a convenient mechanism for understanding the current relationship of users to network addresses, network management policies based on user identities cannot be efficiently supported. It is therefore desirable to have a network management system which provides a current mapping of network addresses to users and/or devices for a network manager. The system should operate in situations where users are connecting to various heterogeneous network servers, and not introduce delay and/or complexity into the process by which the user logs onto such servers.

BRIEF SUMMARY OF THE INVENTION

A system and method for associating a user identity with a network address is disclosed. The system involves a number of login listeners, a user tracker server, and a meta-directory. The login listeners each monitor one or more communication networks to detect login and/or logout events related to corresponding network services. A login event occurs when a user has been successfully authorized by a network server and accordingly granted access to the service or services it provides. Logon events can, for example, be monitored through notification features that are often provided in the Application Programming Interfaces (APIs) for security audit logs of many network services . Such security audit logs record login and/or logout events related to a corresponding network service, and may be configured to notify associated login listeners when such an event is logged.

Whenever a login or logout event is detected by a login listener for a network service, that login listener provides notification of the event to the user tracker server. The notification includes such information as the login name used to initiate the session, the type of service provided by the session, the date and time at which the session was initiated and/or terminated, a name of the network device which requested the service such as a TCP/IP host name or Windows NT™ computer name, as defined by the Windows NT operating system provided by Microsoft® Corporation, an internet protocol (IP) address associated with the service request, and a confidence index value associated with the session. The value of the confidence index reflects the relative strength of the authentication mechanism used on the server which is providing the network service. The confidence index value, therefore, reflects what level of confidence the system has that the requester of the network service is actually the person authorized to use the network service.

Upon receipt of a login or logout notification from a login listener, the user tracker checks a meta- directory to determine if the information in the notification has already been recorded. To do this, the user tracker obtains a media access control (MAC) layer address associated with the IP address in the notification. The user tracker then obtains a user entry within the meta-directory associated with the login name in the notification. The user tracker then checks the existing state of the user entry to determine if it includes a session entry which reflects the newly obtained MAC address, together with the IP address and login name from the login or logout notification. If no such session entry exists, then a session entry associating the MAC address and IP address to the user entry is added to the meta-directory.

The meta-directory may subsequently be used by a policy management system to obtain the MAC address, IP address, or other information in the user entry. The meta-directory may be used to determine a fully distinguished name for the user of a given IP or MAC address, or to determine a MAC or IP address associated with a particular user. The user identity may be a common name of a person, or a name of a network element.

Through the meta-directory, the policy management system can be used by "policy-enabled" devices or services, access to which is obtained through what are sometimes referred to as "policy-leases". The meta- directory enables leases to be granted on a user basis, rather than on an address basis. This permits implementation of user-based network management policies. In addition, the meta-directory may be used by other network management applications to display and report network events and configurations with reference to users, rather than addresses. Moreover, the confidence index associated with login/logout notifications enables management policies to take into consideration the level of confidence the data within the system provides with regard to user identification and authorization.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

The invention will be more fully understood by reference to the following detailed description of the invention in conjunction with the drawings, of which: Fig. 1 is a block diagram showing an illustrative embodiment of the disclosed system;

Fig. 2 is a flow chart showing steps performed by a login listener system;

Fig. 3 is a flow chart showing steps performed by a user tracker server;

Fig. 4 is a flow chart showing steps performed by a meta-directory;

Fig. 5 is a tree structure used to organize entries in a meta-directory and to obtain a fully distinguished name;

Fig. 6 is a flow chart showing steps performed to determine a MAC layer address from a target IP layer address;

Fig. 7 is a flow chart showing steps performed to determine a last internetworking device along a route to a target remote device; and

Fig. 8 is a block diagram of an illustrative network configuration used to describe the operation of the disclosed system. DETAILED DESCRIPTION OF THE INVENTION

As shown in Fig. 1, in an illustrative embodiment, the disclosed system includes a number of login listeners 10, which operate to detect login and/or logout events related to corresponding services provided by the server systems 16. Each one of the login listeners 10 monitors a communication network to which a corresponding one of the server systems 16 is attached. In response to detection of a login or logout event, a login listener provides login information 12, over one of the connections 13 to a user tracker 14. The login and/or logout events represent successful logins 18 or logouts by users 22. The login and/or logout events also include operations 20 performed by network devices 24 to "login" or "logout" with regard to the network itself. The user events 18 and device events 20 may be associated with and/or trigger user-based or device-based network management policies, respectively. In the illustrative embodiment, the login listener A

10a monitors and detects successful user logins to a Windows NT Domain Controller service, shown as server 16a. The login listener 10b monitors and detects logins to a Novell NDS™ server 16b, and the login listener C 10c monitors and detects device logins to a RADIUS (Remote Authentication Dial In User Service) server 16c.

Further, for purposes of illustration, the login listener lOd listens for SNMP (Simple Network Management Protocol) Trap messages sent to an Open Management Platform server 16d, which reflect cold start traps performed by the network devices 24, while login listener lOe listens for LDAP (Lightweight Directory Access Protocol) logins to a network management policy server 16e, which reflect LDAP Bind operations performed by the network devices 24.

Other illustrative login listeners which monitor login and/or logout events related to the user logins 18 include login listeners for detecting logins to UNIX NIS (Network Information Service) servers, as well as login listeners to detect logins to Windows servers. Other illustrative login listeners for detecting device logins 20 include a login listener to detect logins to a COPS

(Common Open Policy Service) server. Many other types of login listeners are possible for technologies which enable the automatic detection of new devices and servers within the network. Examples include login listeners for the Jini™ connection technology of Sun Microsystems, Inc., as well as for the Plug and Play™ technology of Microsoft Corporation.

Login or logout events associated with the server systems 16 are detected by the login listeners 10, for example using notification provisions of security audit log APIs associated with corresponding services provided by the server systems 16. In an alternative embodiment, login or logout events are detected in the login listeners 10 by listening on one or more network interfaces for packets, cells or messages indicating that a successful login or logout has occurred for a specific service. Other login listeners may use other techniques for detecting when users and/or devices login or logout.

During operation of the system shown in Fig. 1, the user tracker server 14 processes login information received from the various login listeners 10. The user tracker server 14 maintains a "white pages" -like directory of network users, shown as the meta-directory 30, based on the login information it receives. The meta-directory 30 provides an interface to other application programs that permits such applications to map a MAC or an IP address to a fully distinguished name which uniquely identifies a person or network device that is currently logged onto one or more network services and using that address. In addition, the fully distinguished name may reflect geographic information regarding users that enables an application to determine a user's likely location within the network. The disclosed system provides the basis for network management policies that are user or device based, as implemented through a policy management system 44. As illustrated in Fig. 1, an address tracker application 36, including an address tracker server and real-time address resolution service, together with an address tracker GUI (Graphical User Interface) 34, operate in connection with login information provided by the user tracker server 14 to identify particular users or devices associated with particular addresses. The address tracker application 36 further maintains a collection of historical address data 42 which reflects past associations between IP and MAC addresses, as well as the locations (device and port) where the addresses were seen. The user tracker server 14 may itself rely on a service of the address tracker server 36 to process address resolution requests 38, for example in order to determine a MAC address that is currently associated with a given IP address.

The user tracker server 14 interfaces to the meta- directory 30 through an LDAP interface 32. The meta- directory 30 also provides interfaces for LDAP searches by the policy management system 44 and other applications 46. Other applications 46, for example, use the information in the meta-directory 30 to display user names involved in a particular network conversation, and/or to automate the configuration of user-based, as opposed to MAC address-based, virtual local area networks (VLANs) .

The meta-directory 30 itself initially imports user account information for a number of network services from a customer's directory 50. The meta-directory is, for example, capable of replicating user information hierarchies from customer enterprise directories, such as

Novell's NDS (Novell Directory Services), Siemens X.500 Directory, Microsoft's Active Directory™ or Netscape's

Directory Server™. For each enterprise network user (or network device) the meta-directory stores the user's common name, as well as a list of login names for respective network services. For each login session associated with a user entry, the meta-directory 30 stores the following information:

Login Name - the login name used for this session

Confidence Index - relative confidence of user identity

Login Type - the type of service Login Date - date and time of login Logout Date - date and time of logout End Station Name - name of computer used by the user

IP Address - IP address of the user's end station interface at the time of login MAC Address - MAC address of user's end station network interface at time of login

Network Device - Network device

(switch/repeater) attached to the network to which the user's end station is attached; most likely a layer 2 device (bridge), but may alternatively be a layer 3 device (router)

Network Device iflndex - SNMP iflndex

(interface index) value corresponding to the interface on the Network Device at which the MAC address of the network interface on the user's end station was last seen

Default Gateway - The user's end station's default gateway router Default Gateway iflndex - Index of the interface on the Default Gateway router where the user's end station's MAC address was last seen

Fig. 2 shows steps performed by an illustrative embodiment of a login listener. Numerous types of login listeners can be provided; i.e., one for each type of supported network service. Additionally, multiple instances of a given login listener type can be installed on various server machines throughout the enterprise. At step 60, the login listener detects a successful user login. Next, at step 62, the login listener determines whether the login detected at step 60 is for an account whose login events are filtered, and which may therefore be ignored. The list of filtered accounts includes shared accounts such as root, administrator, and guest accounts. Activities involving shared accounts are typically not useful to track for purposes of associating specific users with address or other login information. If the detected event is for a filtered account, step 62 is followed by step 68, and processing of the event detected at step 60 is complete. Otherwise, step 62 is followed by step 64. At step 64, the login listener determines if the login information associated with the login event detected at step 60 is currently stored in a cache of previously reported login information. If so, then no reporting of the event is made to the user tracker server 14, since the associated login information has already been reported. In that case, step 64 is followed by step 68. Otherwise, step 64 is followed by step 66.

Any caching of login information within the login listener is completely configurable. For example, the cache may have a configurable size and cache entry time out parameters. A first illustrative login listener cache is configured to store the most recent login event of each user, and to notify the user tracker server 14 only when a login event is detected having new login information for a particular user. In another illustrative embodiment, the login listener cache is configured so that for each user, current login information is forwarded to the user tracker once per predetermined time period, such as once a day. Various other configurations could be provided based on the network management needs of each particular enterprise or customer.

At step 66 the login listener reports login information associated with the login event detected at step 60 to the user tracker server 14. The login information includes the login name used to log into the service, the type of login (service type) , the date and ti e of the login, a name of the computer used by the user to log into the service, the IP address of the source of the service request, and a confidence index. The confidence index is a value representing the relative strength of the authentication mechanism used on the server with which the user has established a session. For example, a login to a Windows NT version 5 server, using the Kerberos version 5 authentication protocol may be assigned a higher confidence index than a login to a Windows NT version 4 server, using the Challenge/Response authentication protocol. Similarly, successful logins to services using the relatively robust Kerberos authentication protocol may receive higher confidence index values than logins to services which transmit unencrypted passwords, such as TELNET.

The confidence index for a given session is used by the policy management system 44 when deciding whether or not to honor security policy-related service requests on behalf of the associated user. For example, a user may initially set up a session with a particular server. The initial level of service provided to the user is relatively low, providing basic access only. Subsequently, the user may request a higher level of service. The requested higher level of service may, for example, have potential security policy implications. Accordingly, the subsequent service request is processed through the policy management system, which accesses the confidence index associated with the initial session, and possibly confidence indices associated with other sessions of the same user, to determine whether the request for a higher service level should be granted. Fig. 3 shows steps performed in an illustrative embodiment of a user tracker server. The user tracker server is generally responsible for collecting and processing login information received from the login listeners. At step 80, the user tracker server listens for and accepts connections from various login listeners, for example TCP connections, or any other type of network connection which features reliable message delivery. Following step 80, at step 82, the user tracker server sends configuration information to the login listeners with which it formed connections at step 80. Configuration information includes, for example, cache entry time out periods, indication of whether or not to track logout events as well as login events, how large of a cache, if any, is to be used to store received login information, how often to report or update received login information with regard to any one particular session or user, and/or how generally to handle receipt of duplicate login information. At step 84, the user tracker server receives a set of login information from one of the login listeners. Then, at step 86, the user tracker server determines a MAC layer address corresponding to an IP address contained in the login information, for example by way of a real-time address resolution function within an address tracker server. Figs. 6-8 describe in greater detail the disclosed system for determining a MAC layer address corresponding to an IP address.

At step 88, the user tracker server searches the meta-directory for a user entry associated with a login name contained in the login information received at step 84. If the login name in the login information does not match a login name associated with any user entry in the meta-directory, the user tracker may provide an indication to the meta-directory reporting the event, which would in turn cause the meta-directory, at some point in time, to load or reload login names and user names from customer directories of service account information. In general, the mappings of login names to users in the meta-directory are provided from such customer directories by a process of importing service account information from user account directories associated with specific service types. For example, in an enterprise network including Lotus Notes™ servers, the login names of users having Lotus Notes accounts would be downloaded into the meta-directory, together with the common names of the corresponding users. Alternatively, the common names of the users for the Lotus Notes accounts could be entered separately into the user tracker server 14, for example by the network manager.

The user entry located in the meta-directory at step 88 is examined at step 90 to determine whether the login information received at step 84 has already been stored. In an illustrative embodiment, the user tracker server determines whether the user entry determined at step 88 is currently associated with both the IP address in the login information at step 84 and the MAC layer address determined in step 86. If the user entry does not include login information associating the user entry with both addresses, then step 90 is followed by step 92, in which the login information received at step 84 is entered as a session entry within the user entry identified at step 88. Otherwise, step 90 is followed by step 94, in which the login information received at step 84 is entered into a security log file. Step 92 is also followed by step 94, so that all login and/or logout events are recorded into the security log file.

Fig. 4 is a flow chart showing steps performed by an illustrative embodiment of a meta-directory in response to receipt of a search request 96, and as would be performed responsive to the LDAP searches 48 as shown in Fig. 1. LDAP is described in detail in Request for Comments (RFC) 1777, all disclosures of which are hereby included by reference herein.

At step 98, the meta-directory locates a user entry which is associated with a login name, common name, MAC address or IP address specified in the search request 96. An illustrative organization of the user entries within the meta-directory is shown in Fig. 5. At step 100, the meta-directory extracts a fully distinguished name from the user entry located at step 98. At step 102, the meta-directory returns the fully distinguished name determined in step 100, along with any session information associated with the user entry, including confidence indices.

Fig. 5 shows an illustrative organization of user entries within the meta-directory. As shown in Fig. 5, user entries are organized as leaves 116 in a hierarchical tree structure. The tree structure of Fig. 5 has a first (or "root") level 110 indicating the organization for which the entries are being stored, in this case identified as company_x. A second level 112 identifies the organizational units within the overall organization, for example HQ (for headquarters) , US (for United States), and GB (for Great Britain). Accordingly, all user entries stored within the HQ branch would be for employees of company_x who work at headquarters, all those entries within the US branch would be for employees who work within the United States, and all those entries within the GB branch would be for employees that work in Great Britain. Each of the branches at level 112 is further divided into sub-branches 114, which for example differentiate entries that are associated with people, from those associated with devices. Other subdivisions at levels 112 and 114 would also be possible. The leaf level 116 is the level at which the individual user entries are stored. Each user entry has associated with it a common name of the user, which is used to distinguish that entry from all other user entries within the immediate sub-branch. For example, if there is only one person named John Smith within the US organizational unit of company_x, then the user entry storing login information related to all service accounts of John Smith could use the string "John_Smith" as a unique common name. However, where there are two John Smiths within the US employees of company X, one of the two would have to differentiate their common name from the other, for example by introduction of a distinguishing middle initial, resulting in "John_Q_Smith" .

When login information is reported to the meta- directory, if it has not already been stored, a session entry is added to the user entry which is associated with the login name contained within the login information. When a request for information regarding a particular user, MAC address, or IP address is received by the meta- directory, the meta-directory returns all session entries, including confidence indices, associated with the user entry which matches the user, MAC address, or IP address information included in the request. In an illustrative embodiment, only information from the most recent session entry within the identified user entry is returned to the requester. A fully distinguished name associated with the identified user entry is also returned to the requester. In the embodiment of Fig. 5, a fully distinguished name associated with a given user entry is formed by concatenating the hierarchical information that reflects the position of the entry within the hierarchical structure. For example, a request which mapped to the user entry having a common name of John_Smith would return a fully distinguished name of "company_x. us .people . John_Smith" . Thus the hierarchical organization of user entries is used to provide a fully distinguished name associated with a user entry, where the fully distinguished name is unique across the entire meta-directory.

Fig. 6 is a flow chart showing steps performed to determine a MAC layer address from an IP layer address in an illustrative embodiment of the disclosed system. At step 138, the system receives a target IP address. The target IP address is an IP address associated with a network interface of a user's end station. In the embodiment shown in Fig. 6, the user's end station is not directly connected to the local subnet of the system at which a request for the MAC address associated with the target IP address is received. The user's end station is accordingly referred to as the "remote device" or "target device". Similarly, the network interface of the user's end station is referred to as the "target network interface". At step 140, the system determines an internetworking device, for example a router, that is the last internetworking device along a route to the target device. Step 140 is described in further detail in connection with Fig. 7. At step 142, the system identifies a network interface of the last router along the route to the target device that is connected to the remote subnet to which the target device is also connected. At step 144, the system retrieves the MAC address associated with the same network interface that the target IP address is associated with from the ARP (Address Resolution Protocol) cache associated with the last internetworking device that is connected to the remote subnet to which the target network interface is also connected. ARP is a known protocol for mapping IP addresses to MAC addresses. A table, usually called the ARP cache, is associated with the network interfaces within a router, and is used to maintain a correlation between MAC addresses and corresponding IP addresses for network interfaces of other network devices in the subnet to which the router connected. ARP defines the protocol rules for establishing and maintaining these correlations, and providing address conversions from IP addresses to MAC addresses. The Reverse ARP protocol performs translations from MAC addresses to IP addresses.

The present system takes advantage of the fact that ARP software maintains IP address to MAC address mappings in its address cache during normal packet forwarding operations of a router. Specifically, when an incoming packet, destined for a network device on a specific subnet, arrives at a router, the router searches the ARP cache to find a MAC address that matches the IP address. If the router finds a corresponding MAC address, then the packet can be converted to include the new MAC address. If no corresponding MAC address is found for that IP address, ARP software broadcasts a request packet in a special format to all network devices on the attached subnet to see if a network device has the IP address associated with one of its interfaces. A network device that recognizes the IP address as being associated with one of its network interfaces returns a reply so indicating. ARP then updates the ARP cache for future reference. The router next transmits the received packet, converted so that it includes the MAC address of the responding network device as a destination MAC address. ARP protocol details differ for each type of local area network. Accordingly, there are separate ARP Requests for Comments (RFCs) for Ethernet, Asynchronous Transfer Mode (ATM), Fiber Distributed Data Interconnect (FDDI) , and other protocols. For example, RFC 826 specifies the Ethernet ARP protocol. Fig. 7 describes illustrative steps performed to determine a last internetworking device along the route to a target device. The steps shown in Fig. 7 may for example, be performed using the UNIX utility tool commonly referred to as "Traceroute" . At step 150, a request packet is generated and transmitted having a destination IP address equal to the target IP address. The request packet may, for example, be an ICMP (Internet Control Message Protocol) Echo Request packet or, alternatively, a UDP (User Datagram Protocol) probe packet. The system writes a time to live value of 1 into the initial request packet. The initial request packet is received by the first internetworking device along the route to the target device. The receiving internetworking device is, for example, a router. The receiving router decrements the time to live value, and the resulting zero value indicates that the packet cannot be forwarded. The router accordingly sends back a reply message to the system which originated the request packet, indicating that the request packet was dropped, and including an IP address of the router that dropped the packet. In the case where the request packet did not reach the remote device, the reply packet is an ICMP Time Exceeded packet.

Upon receipt of the reply packet at step 152, the system determines whether the reply packet is from the target device at step 154. In a first embodiment, the system determines that the reply packet is from the remote device if the reply packet is an ICMP Echo reply packet. In an alternative embodiment, the system determines that the reply packet is from the remote device if the reply packet is an ICMP "port unreachable" packet. In another alternative embodiment, the system determines that the reply packet is from the target device if the IP source address of the reply packet matches the target IP address.

If the system determines that the reply packet is from the remote device, then step 154 is followed by step 156. In that case the requesting device has recorded the IP addresses of each router along the route between the disclosed system and the remote device. Moreover, at this point the reply packet has been sent by the remote device through the last router along the route to the remote device, back to the requesting device on which the disclosed system is, executing. When the last router along the route received that reply packet, it updated its ARP cache to include a mapping between the target IP address and the MAC address of the target network interface on the target device. This updated and relatively current mapping may then be accessed by the system as described above in connection with steps 142 and 144 of Fig. 6.

If the system determines at step 154 that the received reply packet was not originated at the target device, because, for example, the reply packet is an ICMP Time Exceeded packet, then the system knows that the reply packet was generated by a router along the route to the target device, and step 154 is followed by step 158. At step 158, the system increments the time to live value from that which was included in the previously transmitted request packet. For example, the initial request packet's time to live value would be incremented from 1 to 2 for the second request packet at step 158. When the incremented time to live value exceeds a predetermined limit, the target system is determined to be unreachable.

Step 158 is followed by step 150, and a new request packet is transmitted, for example, having a time to live value of 2, and again having the provided target IP address as a destination IP address. The second request packet is received at the first router along the route to the target device, which again decrements the time to live value, this time resulting in a value of 1. The first router forwards the second request packet to the second router along the route to the target device, which decrements the time to live value to zero, thereby determining that the request packet cannot be forwarded. The second router then sends a reply packet back to the requesting device, indicating that the request packet was dropped, and including the IP address of the second router. In this manner, steps 150, 152, 154 and 158 are repeated until a reply packet is received which indicates that the request packet was received by the target device.

An illustrative configuration of network devices is shown in Fig. 8, in connection with which is described processing of a request for a MAC address associated with a target network interface of target device 170. The target IP address of the target device 170 is 158.101.121.230. Illustrative IP addresses along the route to the target device, as determined by the disclosed system running on a source network device 160, are as follows:

Source device: 151.104.89.178

Router 1 162 151.104.89.1 Router 2 164 151.104.14.6

Router 3 166 151.104.99.18

Router 4 168 158.101.96.23

Target Device: 158.101.121.230

The last router along the route from the source 160 to the target device 170 is Router 4 168. The IP address of the network interface to Router 4 168 along the route from the source network device 160 to the target device 170 is 158.101.96.23. This is not the IP address for the network interface of the router that is connected to the remote subnet on which the target network interface is connected. However, this IP address (158.101.96.23) of Router 4 168 may be used to access a Simple Network Management Protocol (SNMP) software agent executing within Router 4 168 in order to determine IP addresses of other network interfaces of Router 4 168. Because Router 4 168 is the last router along the route to the target device, Router 4 168 must have another network interface that is connected to the subnet to which the target interface is connected.

The IP address for the network interface of Router 4 168 that is connected to the subnet to which the target network interface is also connected is obtained by issuing an SNMP Get ipRoutelfIndex command to the SNMP agent within the Router 4 168. To perform this command, the present system first determines the SNMP "read community" string of the router, which is the SNMP read- access password necessary to read the SNMP data structures controlled by the SNMP agent. The read community string may be, for purposes of example, obtained through an Open Management Platform (OMP) service such as Hewlett Packard's OpenView™, or from a vendor specific network management product such as 3Com Corporation's Transcend™.

The disclosed system identifies the specific network interface of Router 4 168 that is on the 158.101.121.0 subnet by accessing an SNMP Management Information Base version 2 (MIB II) stored within Router 4 168 to determine an "interface index" (iflndex) value associated with that interface. The iflndex value associated with the desired interface is obtained through an ipRoutelfIndex object within an ipRouteTable structure, which is also defined within the SNMP MIB II data structure. In order to accomplish this, the disclosed syste first determines the network address within the target IP address. As it is generally known, any IP address includes a host address and a network address. The network address of the target IP address is also referred to as the "route destination address" of the remote subnet to which the target interface is connected. The route destination address must be obtained in this case because the ipRouteTable structure must be indexed using a route destination address value, and not simply using the full target IP address.

The route destination address of the remote subnet to which the target device is connected is obtained by logically ANDing the target IP address with the appropriate subnet mask. The system may require the user to supply the appropriate subnet mask with the target IP address. Several alternative approaches may be employed to determine the route destination address. They include :

-Querying the IP topology database of an OMP server to determine the subnet to which the target device is connected;

-Using trial and error by applying common subnet mask values to the target IP address. This may be accomplished by first applying the subnet mask 255.255.255.0. If the resulting value, when applied as an index to the SNMP ipRoutelfIndex structure, returns a valid iflndex value, then the attempt was successful. Otherwise, if an error is returned, then the least significant binary '1' in the subnet mask is cleared, resulting in a value of 255.255.254.0, and applying the mask to the target IP address. If the result still fails to provide a valid iflndex value, then the next least significant bit in the subnet mask is cleared, and the process repeated until a valid iflndex is obtained.

In the configuration of Fig. 8, the route destination address is 158.101.121.0. It is, for purposes of example, obtained by logically ANDing the target IP address 158.101.121.230 with the subnet mask 255.255.255.0. With the route destination address known, the following SNMP request may be issued:

SNMP Get ipRoutelfIndex.158.101.121.0

The above request, for purposes of example, returns a value of 8, which is the iflndex value for the network interface of Router 4 168 on the 158.101.121.0 subnet. Next, in order to determine the MAC address of the target network interface, the system uses the ipNetToMediaPhysAddress MIB object from ipNetToMediaTable associated with Router 4 168. The ipNetToMediaTable structure is the Address Resolution Protocol (ARP) cache for the Router 4 168. The iflndex value determined in step 142 of Fig. 6 and the target IP address 158.101.121.230 are the indices to the ipNetToMediaTable. In the example of Fig. 8, where the iflndex is 8, and the target IP address is 158.101.121.230, the following SNMP command:

SNMP Get ipNetToMediaPhysAddress.8.158.101.121.230

returns a MAC address, for example, 00C04FC2C2CE84 , which is the MAC address of the target network interface on the target device. The functions herein described can be implemented in many forms, including one or more Application Specific Integrated Circuits or any other suitable hardware implementation, or some combination of hardware components and software. Where a portion of the functionality is provided using software, that software may be provided to the computer in many ways; including, but not limited to: (a) information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment) ; (b) information alterably stored on writable storage media (e.g. floppy disks and hard drives) ; or (c) information conveyed to a computer through communication media, for example, using baseband or broadband signaling techniques, including carrier wave signaling techniques, such as over computer or telephone networks via a modem.

While the invention is described through the above exemplary embodiments, it will be understood by those of ordinary skill in the art that modification to and variation of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed. Accordingly, the invention should not be viewed as limited except by the scope and spirit of the appended claims.

Claims

1. A method for associating a user identity with a network address, comprising: monitoring a communications network for login events; detecting a login event, said login event associated with login information including a login name and at least one network address; forming an association between said network address and a user identity in a directory, responsive to an association between said login name and said user identity; and providing said user identity responsive to a request for information associated with said network address.

2. The method of claim 1, further comprising loading, into said directory, a plurality of associations between respective ones of a plurality of login names and corresponding ones of a plurality of user identities.

3. The method of claim 1, wherein said login event reflects successful login to a network service.

4. The method of claim 3, said login information including a time a session associated with said successful login was established with said network service .

5. The method of claim 4, said login information including a date said session was established with said network service.

6. The method of claim 4, said login information including a geographic location from which said session was established with said network service.

7. The method of claim 1, further comprising: monitoring said communications network for logout events indicating termination of previously established sessions with said network service; detecting one of said logout events, said detected logout event associated with logout information including a login name and at least one network address; and storing, responsive to said detection of said detected logout event, said logout information in association with a user identity associated with login name included in said logout information.

8. The method of claim 7, said logout information including a time said previously established session with said network service was terminated.

9. The method of claim 7, said logout information including a date said previously established session with said network service was terminated.

10. The method of claim 1, wherein said network address is a media access control (MAC) layer address.

11. The method of claim 1, wherein said network address is an internet protocol (IP) layer address.

12. The method of claim 1, wherein said user identity identifies a person.

13. The method of claim 1, wherein said user identity identifies a network device.

14. The method of claim 1, further comprising: generating a confidence index reflecting a degree of certainty that said user identity is associated with said network address; and providing, responsive to said request for an entity associated with said network address, said confidence index.

15. The method of claim 14, wherein said generating of said confidence index reflects a level of confidence that said login event was initiated by an authenticated user.

16. The method of claim 1, further comprising obtaining, responsive to said providing of said user identity, a network management policy associated with said user identity.

17. The method of claim 1, wherein said association of said login information and said user identity comprises an entry within a hierarchical tree structure, wherein said user identity reflects the position of said entry in said hierarchical tree structure.

18. A system for associating a user identity with a network address, comprising: at least one login listener for monitoring a communications network for login events, and for detecting a login event, said login event associated with login information including a login name and at least one network address; at least one user tracker server for forming, responsive to said detected login event, an association between said network address and a user identity in a directory, responsive to an association in said directory between said login name and said user identity, and for providing said user identity responsive to a request for information associated with said network address.

19. A computer program product including a computer readable medium, said computer readable medium having a network management computer program stored thereon, said network management computer program for identifying users and/or devices within an enterprise network, said network management computer program comprising: program code for monitoring a communications network for login events; program code for detecting a login event, said login event associated with login information including a login name and at least one network address; program code for forming an association between said network address and a user identity in a directory, responsive to an association between said login name and said user identity; and program code for providing said user identity responsive to a request for information associated with said network address.

20. A computer data signal embodied in a carrier wave, said computer data signal including a network management computer program, said network management computer program for identifying users and/or devices within an enterprise network, said network management computer program comprising: program code for monitoring a communications network for login events; program code for detecting a login event, said login event associated with login information including a login name and at least one network address; program code for forming an association between said network address and a user identity in a directory, responsive to an association between said login name and said user identity; and program code for providing said user identity responsive to a request for information associated with said network address.