PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,185,964
`
`Exacq Technologies, Inc.
`Exhibit 1006
`
`                        
`
`

`
`
`
`(12) United States Patent
`Nelson
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,292,838 B1
`Sep. 18, 2001
`
`US006292838B1
`
`(54) TECHNIQUE FOR AUTOMATIC REMOTE
`MEDIA ACCESS CONTROL (MAC) LAYER
`ADDRESS RESOLUTION
`
`(75)
`
`Inventor: William Joseph Nelson, Auburn, MA
`(US)
`
`(73) Assjgnee; 3Com Corporation, Santa C1ara, CA
`(US)
`
`( * ) N0tiCe3
`
`Subject t0 any disclaimer, the term Of thiS
`Patent is extended Or adjusted under 35
`U-S-C 154(b) by 0 daY5~
`
`(21) Appl. N0: 09/379,339
`22
`F1 d:
`A . 23 1999
`1 6
`ug
`’
`)
`(
`Int. Cl.7 ......................... .. G06F 15/16; G06F 15/173
`(51)
`(52) U.S. Cl.
`......................... .. 709/236; 709/238; 709/245
`(58) Field of Search ................................... .. 709/236, 238,
`709/242, 223, 224, 245
`
`(56)
`
`References Cited
`
`Us’ PATENT DOCUMENTS
`5,708,654 *
`1/1998 Arndt et al.
`....................... .. 370/242
`
`5,920,566 *
`7/1999 Hendel er a1.
`.
`370/401
`7/1999 Bare .............................. .. 395/200.55
`5,920,699 *
`5,926,463 *
`7/1999 Ahearn et al.
`..................... .. 370/254
`6,055,236 *
`4/2000 Nessett et al.
`.
`370/389
`6,199,122 *
`3/2001 Wilson ............................... .. 709/227
`
`Primary Examiner—Glenton B. Burgess
`Assistant Examiner—Tod Kupstas
`(74) Attorney, Agent, or Firm—Weingarten, Schurgin,
`Gagnebin & Hayes LLP
`
`(57)
`
`ABSTRACT
`
`A system and method for determining a MAC layer address
`of a network interface on a remote device, based on an IP
`address associated with the same network interface on the
`
`remote device. The disclosed system identifies an internet-
`working device, for example a router, that is attached to the
`remote subnet to which the network interface of the remote
`device is attached. The system identifies the network inter-
`face of the router that is attached to the remote subnet, and
`obtains the MAC address of that network interface from an
`address resolution protocol (ARP) cache associated with it.
`The system transmits a series of request packets having an
`IP destination address equal to the provided IP address of the
`rem0te deVice, each including a time t0 1iVe Value, indicating
`a maximum number of network hops over which each
`particular packet may be forwarded. The time to live values
`of the request packets result
`in each successive request
`packet being forwarded one hop further along the path to the
`remote device. The internetworking devices along the route
`t0 the remote deVice each receiVe cne request Packet that
`cannot be forwarded because the time to live value has been
`decremented to zero. As a result, each internetworking
`device along the route returns a reply packet to the request-
`iiig deviee iiidieatiiig its 113 address.
`
`19 Claims, 6 Drawing Sheets
`
`* cited by examiner
`
`
`
`
`
`Log login event into security log file
`
`Accept connections from
`login listeners
`
`
`
`
`
`Send configuration parameters
`to I in listeners
`
`Receive login information
`
`Determine mac address for
`IP address in I in information
`
`Search for user entry
`corresondin to loin name
`
`
`
`
`90
`
`
`
`Login information
`for user in data base?
`
`
`
`Add login information to user
`ent
`in database
`
`
`
`
`
`Exacq
`Ex. 1006
`Page 1
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 1 of 6
`
`US 6,292,838 B1
`
`Customers
`Directo
`
`50
`
`30
`
`Import User
`H‘e’a'°“Y
`0
`
`Address
`Tracker
`
`GUI
`
`48
`
`LDAPsearches
`
`34
`
`35
`
`44
`
`46
`
`Other
`Applications
`Policy
`
`Management
`System
`
`38
`
`\
`Address Resolution Requests
`
`Z
`
`Address Tracker 9 “War
`Server
`Address Date
`
`Real-time
`Address Resolution
`
`42
`
`ICMP and SNMP ‘A0d
`Listener
`
`SNMP Trap
`Login
`
`' ° °
`
`1s{ y
`
`i
`
`16c
`
`16d
`
`16e
`
`i
`
`20{C°'T“r$a" |
`
`N LDAPBind
`
`Device Logins
`
`Exacq
`Ex. 1006
`Page 2
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 2 of 6
`
`US 6,292,838 B1
`
`Detect successful user login
`
`60
`
`
`
`Login information in cache?
`
`Report login information to user tracker
`
`66
`
`Yes
`
`Login for
`a filtered account?
`
`No
`
`Exacq
`Ex. 1006
`Page 3
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 3 of 6
`
`US 6,292,838 B1
`
`Accept connections from
`Iogin listeners
`
`Send configuration parameters
`to loin listeners
`
`Receive Iogin information
`
`80
`
`32
`
`84
`
`Determine mac address for
`
`IP address in loin information
`
`35
`
`Search for user entry
`corresondin to loin name
`
`33
`
`
`
`
`
`Yes
`
`Login information
`for user in data base?
`
`
`
`Add Iogin information to user
`ent
`in database
`
`
`
`
`92
`
`Log Iogin event into security log file
`
`94
`
`FIG. 3
`
`Exacq
`Ex. 1006
`Page 4
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 4 of 6
`
`US 6,292,838 B1
`
`
`
`Search request
`
`Find user entry
`
`Extract fully distinguished name
`
`00
`
` 1
`
`
`
`Return session information
`
`and fully distinguished name
`
` 102
`
`FIG. 4
`
`o=company_x
`110{
`
`mm112{ ou=HQ ou=US ou=GB °
`m{ flou=peop|e
`‘___J
`116 { cn=John_Smith
`
`ou=devices
`
`'
`
`'
`
`'
`
`
`
`°
`
`°
`
`FIG. 5
`
`Exacq
`Ex. 1006
`Page 5
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 5 of 6
`
`US 6,292,838 B1
`
`
`
`Target IP address
`
`
`
`138
`
`Determine last internetworking
`device along route to remote device
`
`FIG. 6
`
`
`
`Determine network interface
`
`140
`
`FIG. 7
`
`
`
`
`
`of last internetworking device
`connected to remote subnet
`
`
`Retrieve MAC address from
`
`network interface cache
`
`
`
`Send request message to
`provided destination IP address
`
`Receive reply message
`
`is reply from
`the target remote device?
`
`142
`
`
`
`144
`
`Increment time to
`
`live value
`
`158
`
`156
`
`Exacq
`Ex. 1006
`Page 6
`
`

`
`U.S. Patent
`
`Sep. 18, 2001
`
`Sheet 6 of 6
`
`US 6,292,838 B1
`
`150
`
`164
`
`168
`
`151.104.89.178
`
`
`
`Target
`Device
`
`170
`
`158.101.121.230
`
`
`
`FIG. 8
`
`Exacq
`Ex. 1006
`Page 7
`
`

`
`US 6,292,838 B1
`
`1
`TECHNIQUE FOR AUTOMATIC REMOTE
`MEDIA ACCESS CONTROL (MAC) LAYER
`ADDRESS RESOLUTION
`
`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
`determining a Media Access Control (MAC) layer address
`responsive to an Internet Protocol (IP) layer address.
`The complex maintenance, configurations and trouble-
`shooting requirements of computer networks and commu-
`nications systems are often the responsibility of a person
`known as a network manager. Various automated tools are
`available to assist network managers, and are referred to
`generally as network management systems. The guidelines
`which define the allocation of network resources and ser-
`
`vices are referred to as network management policies. Net-
`work 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 devices.
`In existing systems, network management policies are
`sometimes applied on a per-address basis. Addresses used in
`packets transmitted over computer networks are often
`described with relation to layers of the International Stan-
`dards Organization (ISO) Model for Open Systems Inter-
`connection (OSI), sometimes called the OSI
`reference
`model. Two layers of the OSI reference model that are
`typically associated with address information are the data
`link and network layers. The data link layer is often con-
`sidered to be divided into two sublayers: a logical
`link
`control (LLC) layer and a media access control (MAC)
`layer. MAC layer address information of a packet typically
`consists of a source MAC address and a destination MAC
`address. Source and destination MAC addresses are used
`
`within what is commonly referred to as the local “subnet”.
`When a packet passes through multiple subnets between its
`source and destination, typically by way of internetworking
`devices such as routers, the packet is said to go through
`many “hops” along its route. Source and destination MAC
`addresses are generally carried over a single “hop” within
`the potentially multi-hop route to a packet’s ultimate desti-
`nation. MAC layer addresses are therefore an example of
`“single hop” or “point to point” address information. A
`MAC layer address is usually statically associated with an
`individual network interface of a device, for example as
`stored within a non-volatile memory of a network interface
`card.
`
`Network layer addresses, in contrast, are carried from the
`packet’s originating system all
`the way to the packet’s
`ultimate destination, potentially over multiple subnets or
`“hops”. For example, internetworking protocol (IP) packets
`include IP source and destination addresses that are pre-
`served from the originating system all
`the way to the
`ultimate destination of the packet. Network layer addresses
`are therefore considered to be “end to end” addresses.
`
`During operation of existing systems, a given IP address is
`
`2
`typically associated, either dynamically or statically, with a
`single network interface of a particular device.
`In existing network management systems employing
`address-based network management policies, a request to
`use a given network service is granted or rejected based on
`the privileges or level of service associated with a source
`address contained in the request. With regard to using MAC
`addresses for this purpose, a problem arises due to the way
`routers process IP packets. Specifically, when a router for-
`wards a packet from a host on one subnet to a host or a router
`on another subnet, the router overwrites the packet’s original
`source MAC address with the MAC address of the router’s
`
`egress interface. Thus, a MAC address of a given network
`interface is only visible in packets received on the subnet to
`which the network interface is directly attached, sometimes
`referred to as the “local subnet”. If a server is not located on
`
`the same subnet as the clients to which it provides services,
`source MAC addresses in service requests cannot be guar-
`anteed to be MAC addresses of the systems from which the
`requests originated. This makes it difficult for a server to
`determine the system which originated the request.
`Accordingly, a MAC address based network management
`policy is problematic in an enterprise network with many
`subnets.
`
`At least one existing network management system has
`enabled a network manager to locate a device having a
`particular MAC address within the network, and to deter-
`mine an IP address that is currently associated with that
`MA7 address. However, this system collects address data by
`periodically polling all network devices in the network.
`Address data collected by this system could, therefore, be as
`old as tie polling interval. Since this method for collecting
`data is relatively timely-consuming and bandwidth
`intensive, it is not feasible for such a system to obtain current
`address information in real-time. Accordingly, this type of
`existing system cannot be used to perform efficient and
`effective real-time trouble shooting of problems related to a
`particular user’s network layer address.
`Additionally, future versions of cable television set-top
`boxes and other home networking products may be IP based.
`It may also be desirable for service providers to be able to
`identify a particular customer by the MAC address of the
`customer’s home networking device. For example, when a
`customer initiated a request for a “premium” service, the
`service provider would need to identify the MAC address of
`the requesting customer’s network interface device, through
`the source IP address within the request, in order to bill the
`customer for the requested service.
`Finally, existing address-based network policies in gen-
`eral do not permit allocation of resources on a per-user basis.
`This arises from the fact that multiple users may be asso-
`ciated with either a single MAC or IP address. For example,
`a shared system in a guest office or library may be used by
`different users at different times. Additionally, IP addresses
`are often dynamically allocated when a user logs into a
`network enabled system. For these reasons, a single stati-
`cally allocated IP address may be associated with different
`users at different times, and different dynamically allocated
`IP addresses may be used by a single user for different
`sessions on a single system. Network management policies
`based on specific users have, therefore, been difficult to
`support.
`For the reasons outlined above it would be desirable to
`
`have a system for identifying, given an IP address, a MAC
`layer address associated with a network interface of a remote
`system with which that IP address is also associated. The
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Exacq
`Ex. 1006
`Page 8
`
`

`
`US 6,292,838 B1
`
`3
`system should enable a network management system or
`network manager to identify the MAC address of a network
`interface that originated a service request message, based on
`a source IP address within the request. The system should be
`capable of operating at any location with respect to the
`originating system or device. In particular, the system should
`be capable of obtaining a MAC address of a network
`interface on a remote system, for which an IP address is
`known.
`
`BRIEF SUMMARY OF THE INVENTION
`
`A system and method for determining a MAC layer
`address of a network interface on a remote device is
`
`disclosed, which operates using an IP address associated
`with the same network interface of the remote device. The
`
`disclosed system identifies an internetworking device, for
`example a router, that is attached to the remote subnet to
`which the network interface of the remote device is attached.
`
`5
`
`10
`
`15
`
`The system identifies the network interface of the router that
`is attached to the remote subnet, and obtains the MAC
`address of that network interface from an address resolution
`
`20
`
`protocol (ARP) cache that is associated with it.
`In an illustrative embodiment,
`the disclosed system
`responds to a request for a MAC address corresponding to
`a provided IP address by transmitting a series of request
`packets having an IP destination address equal to the pro-
`vided IP address. The request packets each include a time to
`live value, indicating a maximum number of network hops
`over which each particular packet may be forwarded. The
`time to live values of the request packets are each incre-
`mented by one with respect to the time to live value of the
`preceding request packet. Each successive request packet is
`accordingly forwarded one hop further along the path to the
`remote device, until the remote device itself is reached by
`the last request packet.
`The internetworking devices along the route to the remote
`device each receive one request packet
`that cannot be
`forwarded because the time to live value equals zero after it
`has been decremented. Upon detection of such a request
`packet, each internetworking device along the route returns
`a reply packet to the requesting device that indicates an IP
`address of the interface on which the request packet was
`received. Finally, the remote device itself receives the last
`request packet, and returns a reply packet that indicates the
`request was received at the remote device. In this way the
`requesting device forms a list of routers along the route to
`the remote device, including the router which is attached to
`the subnet to which the remote device is directly connected.
`The disclosed system then identifies the network interface
`of the last internetworking device along the route to the
`remote device that is coupled to the remote subnet to which
`the interface of the remote device is also coupled. The
`system then accesses a cache of MAC layer addresses within
`the last internetworking device to determine a MAC address
`of the network interface of the remote device that is asso-
`
`ciated with the same IP address as provided in the original
`request.
`In this way a system is disclosed which identifies, given
`an IP address, a MAC layer address associated with a
`network interface of a remote system with which the given
`IP address is also associated. The disclosed system enables
`a network management system or network manager to
`identify the MAC address of a network interface that origi-
`nated a service request message, based on a source IP
`address contained within the service request. The disclosed
`system is capable of operating at various locations with
`respect to the remote system or device.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`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 embodi-
`ment 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 deter-
`mine a MAC layer address from a target IP layer address;
`FIG. 7 is a flow chart showing steps performed to deter-
`mine 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 manage-
`ment 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
`NDSTM server 16b, and the login listener C 10c monitors
`and detects device logins to a RADIUS (Remote Authenti-
`cation Dial In User Service) server 16c.
`Further, for purposes of illustration, the login listener 10d
`listens for SNMP (Simple Network Management Protocol)
`Trap messages sent to an Open Management Platform server
`16d, which refiect cold start traps performed by the network
`devices 24, while login listener 106 listens for LDAP
`(Lightweight Directory Access Protocol) logins to a network
`management policy server 16e, which refiect 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 logic
`listener to detect logins to a COPS (Common Open Policy
`
`Exacq
`Ex. 1006
`Page 9
`
`

`
`US 6,292,838 B1
`
`5
`
`Service) server. Many other types of login listeners are
`possible for technologies which enable the automatic detec-
`tion of new devices and servers within the network.
`
`Examples include login listeners for the JiniTM 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 infor-
`mation it receives. The meta-directory 30 provides an inter-
`face to other application programs that permits such appli-
`cations 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 refiect 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 main-
`tains 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 cus-
`
`tomer’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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`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 net-
`
`work 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 if index—SNMP ifindex (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 sees
`
`Default Gateway—The user’s end station’s default gate-
`way router
`Default Gateway ifIndex—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 embodi-
`ment 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 logic
`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 infor-
`mation 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 param-
`eters. 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
`
`Exacq
`Ex. 1006
`Page 10
`
`

`
`US 6,292,838 B1
`
`7
`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 time 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 proto-
`col. Similarly, successful logins to services using the rela-
`tively 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 embodi-
`ment 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.
`
`the disclosed system for
`6-8 describe in greater detail
`determining a MAC layer address corresponding to an IP
`address.
`
`the user tracker server searches the meta-
`At step 88,
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`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 associ-
`
`ated with specific service types. For example, in an enter-
`prise network including Lotus Notes” servers, the login
`names of users having Lotus Notes accounts would be
`downloaded into the meta-directory, together with the com-
`mon 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 infor-
`mation 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 associ-
`ating 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