Persistent database of dhcp clients seen on the network
This is a feature request for an endpoint database in Stork, of all the clients serviced by any of the Kea servers managed by Stork.
Stork users would like to be able to store, view and update client information that persists after the lease may have been released. It would be useful to maintain a database of client information that could associate networked client identity with other administrative parameters that a help desk or network admin function might need.
Possible use cases
- identify the end user associated with an ip address or subnet of addresses, in order to send email notification about upcoming maintenance that might impact that subnet
- identify the date a client associated with a particular DNS host name was last seen on the network, to help in identifying abandoned hostnames in the DNS.
- identify the end user associated with a device for which there is an unused host reservation, in order to follow up off-line and possibly 'reclaim' that HR
- identifying all the printers scattered across multiple subnets, in order to move them all to a separate subnet
- determine the physical location for a client device that is misbehaving on the network in order to find it and remove it, update, or reboot it
- find all devices associated with an end user who has recently left the company, to determine whether any of those devices are still responding/renewing on the network
- identify the phone number associated with an ip phone, to update a directory listing (this is probably not the ideal way to do this however)
- locating all the users with client devices of a particular vendor and device type in case of an urgent security update (this is probably not the ideal way to do this however)
Possible db fields
- client-identifying parameters from the DHCP interaction (MAC, DUID, etc)
- host reservation information (if there is an associated HR), including DNS name, boot file location, user-context, perhaps any other options on the HR
- IP address assigned and date/time it was last renewed.
- device type, such as Android phone, iPhone, Windows laptop, HP Printer, etc (eventually we might want to try populating this information using client fingerprinting from options provided in requests)
- vendor/manufacturer (e.g. Apple, Samsung, HP etc). This could eventually be populated by fingerprinting.
- geographic location (this could be a city/office such as Baltimore, MD, or it could be some other code such as BLDG21-3rdFlr. We should probably permit a wide range of possible end user formats/strings for this.
- any 'user context' data associated with the client. Other than host reservations, is there any other way that user context could be associated with a client? There could be user context associated with the subnet that the client most recently received a lease from, would we want to associate that with the client??
- end user contact information fields, such as fname, lname, userID, email address, phone extension, mobile and administrative affiliation (e.g. department). (this might be in a different linked table, so a user could be associated with multiple devices? Also, that would facilitate importing a table of end user contact data.)
Other features
-
it would be very cool if this database of endpoints could be created from lease data, but without removing endpoints when the leases failed to renew
-
it would be ideal if the information could be updated when a new lease is assigned, if the endpoint is found in the database with a prior lease. So, for example, the ip address and some option data might be updated, but the rest of the information, much of which would have been administratively entered, would persist on the record
-
some organizations might have a table of endpoints that they would want to import, in csv format, for instance. It would also be useful to be able to export this information for import into some other client inventory system
-
this should be different from the Lease db in that Kea does not need to maintain it in real time! Nobody would want this if updates were blocking on assigning or renewing leases, or if using it put a big performance strain on Kea. It is fine if updates to this database are not acknowledged to Kea, and Kea definitely should not wait for responses from the endpoint db. Possibly this could use the 3rd lease data stream from HA as an input?
-
Some of the above may be features that make more sense as use cases for a network documentation system, such as NetBox. We are not trying to replace the network documentation, but to provide documentation at a more granular level... So we might want to investigate what a NetBox might offer for endpoint tracking first, and possible somehow leverage that ...
-
The Stork admin would likely want to customize which fields are used and displayed in the GUI, as many enterprises would not populate all of the fields.
-
It might be necessary for the Stork admin to identify which endpoint identifier should be used as the unique index field, so that updates are possible.
We haven't discussed the GUI features that might leverage this database, but it does seem to be desirable to permit record deletion, or at least mark them as historical/deprecated/inactive or something. Otherwise this db would grow and grow like an unrotated log file...