It occurred to me that it would be nice to be able to create and store canned LDAP searches and be able to provide a set of pre-created LDAP searches that customers can use out of box or tweak.
I see it being a CLI interface to define such searches (UI may be later) and then the CLI?UI to execute.
A quick design: - The storage object would contain following attributes: - Name of the query - Description - Base DN - Scope - Filter - The CLI to manage will consist of: - ipa query-add --filter=<> --base=<> --scope=<> --description=<> query-name - ipa query-mod --filter=<> --base=<> --scope=<> --description=<> query-name - ipa query-del query-name - ipa query-find query-name - ipa query-search query-name-regex - The CLI to use will be ipa query-run, it will have a corresponding UI interface - There should be a way to output information in different formats (CSV, HTML, XML, JSON, etc). HTML is actually very well processed by Excel (do not know if Calc is same good) and looks much nicer than CSV. - System will provide some canned queries about the users, host and other objects that we see necessary - Users without passwords - Users with expiring passwords - Users that have not had any activity for a defined period of time - Hosts that are provisioned - Hosts that are not provisioned - Hosts with expiring certs - etc.
This combines two orthogonal features: management of canned searches and different CLI output formats.
Management of canned searches seems like reinventing the wheel; there are already LDAP monitoring tools that are much better than what we can code up -- they're not limited to plain LDAP searches, they have good analysis/reporting/notifications. It would be better to integrate (write templates for) Nagios or Zabbix.
Despite that I believe an "ipa query-run" command could be useful -- ldapsearch already exists, but this would run with correctly set connection parameters, do failover, and format the output like ipa --raw would.
As for supporting different output formats, this would be helpful for all IPA commands, not just these. A question was raised whether this should be done on the client (more consistent API), or on the server (better integration or other clients -- web UI, dumb curl). Server-side is probably the better choice.
There is an existing thesis topic proposal for this RFE: https://thesis-managementsystem.rhcloud.com/topic/show/6/reporting-capability-in-freeipa
Dmitri shared extension of the original idea that was also added to the thesis:
FreeIPA stores a lot of valuable identity and policy information in its LDAP tree. But this information is stored in a way that is easy to search, but not necessarily easy to digest for an Administrator. The users of the Identity Management system (Administrators and DevOps) are seeking a better introspection into who can access what and which policies apply in which situations. Reports like this are not an easy task to create.
The thesis would start with investigation and research of what kind of information people are actually looking for, how the disjoint polices and objects are stored in different parts of the LDAP tree and how they can be correlated together to provide a coherent view for an Administrator and helps him to meet his compliance requirements. Once there is an understanding of how data can be collected and correlated, there is a need to make it easy for an Administrator to develop the reports and manage them in the system. That includes creating, deleting and modifying them, storing them, scheduling their execution or for example sharing with others.
This thesis requires a lot of research and design that needs to be validated with real users and then an implementation of the tools that would make a practical difference for users of the FreeIPA system.
Metadata Update from @dpal: - Issue assigned to someone - Issue set to the milestone: Ticket Backlog
Login to comment on this ticket.