You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an owner of a system I need to know which users have access to a host. I want to run something on the host and get a report who can access it.
The reports must contain information about HBAC but does a SUDO report would also be beneficial. This would allow me to pass audits and make sure that right people have right access to systems and applications.
Idea:
Create a utility that would trigger one time enumeration, populate caches and run a report against the cache. That would actually solve do two problems:
a. Priming of the cache with the full database
b. Actually creating a report based on the cached data
We see several inquiries about this capability in recent days.
Some more details based on a discussion in a RHBZ (private, sorry)
it was suggested to output the result in CSV along the lines of name:object_type:service
machine-parseable output would make it easy to consume the data with an ansible module
an ansible module should be developed to gather the data from the output. Where to track this module is not clear, we need to find who would be working on the IDM/AD ansible integration
Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2840
Use case:
As an owner of a system I need to know which users have access to a host. I want to run something on the host and get a report who can access it.
The reports must contain information about HBAC but does a SUDO report would also be beneficial. This would allow me to pass audits and make sure that right people have right access to systems and applications.
Idea:
Create a utility that would trigger one time enumeration, populate caches and run a report against the cache. That would actually solve do two problems:
a. Priming of the cache with the full database
b. Actually creating a report based on the cached data
We see several inquiries about this capability in recent days.
Comments
Comment from jhrozek at 2015-10-15 21:09:20
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1272214
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=1272214 1272214]
Comment from jhrozek at 2015-10-22 17:34:15
For now, I'll file the ticket into 1.15, since it hasn't been requested for the next release.
If it is requested, we will move it back up.
milestone: NEEDS_TRIAGE => SSSD 1.15 beta
Comment from dpal at 2017-02-24 14:34:14
Metadata Update from @dpal:
Comment from jhrozek at 2017-05-18 12:31:40
Some more details based on a discussion in a RHBZ (private, sorry)
Comment from jhrozek at 2017-05-18 12:31:43
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-08-10 13:30:15
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-08-18 18:22:49
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-10-19 17:51:53
Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1
Comment from jhrozek at 2017-10-19 17:51:54
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-10-19 20:21:22
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-10-23 18:13:32
I updated the ticket title to make it clear that the scope of the work for now is only IPA domains.
Comment from jhrozek at 2017-10-23 18:13:33
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-10-31 22:38:44
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-11-21 20:28:58
master:
Comment from jhrozek at 2017-11-21 20:28:59
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-11-21 20:29:10
Metadata Update from @jhrozek:
The text was updated successfully, but these errors were encountered: