<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Lois,</div><div class=""><br class=""></div><div class="">The auditors that I have worked with will generally know enough to ask good questions even if they don’t know exactly what technology is specifically in use. But they also gave me scripts to run to pull information like passwd that I’m pretty sure they _never_ looked at the output... </div><div class=""><br class=""></div><div class="">John Malloy,</div><div class=""><br class=""></div><div class="">Red Hat IdM will make things different, as it is an additional layer to the host-based files. You’ll need to find out who manages that in order to get an authoritative list. That should be based on assigning roles, but you can look at the groups the host is in and work backward with that person; IdM can also determine sudo access (though it may depend on the version - I’ve mostly worked with CentOS 7). Remember, no one can “log in” via sudo...</div><div class=""><br class=""></div><div class="">The other element to this is what John Stoffel said: it’s really process. They’ll believe you when you have a good, documented process. The step of sitting down with a systems admin and asking for this sort of thing is really pretty far along, what they are most likely looking for is “evidence” that a policy is being adhered to. They aren’t interested in a rat hole any more than you are, and they are trying to help you be compliant, but doing the right thing isn’t of interest to them if it’s not “business as usual” backed by the right “controls”. And, btw, those should include a statement about the principle of least privilege with respect to access, and that means if you find violations that’s better than not being able to call them as such.</div><div class=""><br class=""></div><div class="">And I have done PCI so if there’s anything I can tell you about that, feel free to ping me directly. It might help if you know what they are auditing “for” (PCI, HIPAA, DoD,…) and if they’re internal v. external auditors, etc.</div><div class=""><br class=""></div><div class="">_KMP</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 18 Apr 2020, at 15:22, Dean Anderson <<a href="mailto:dean.anderson71@yahoo.com" class="">dean.anderson71@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">You need to report who has the root passwords and who is in the sudo files, and whether there are any other means of becoming root. Powerbroker or other tools including Tivoli, puppet etc are included. If you can run a puppet script as root, you’re root.<div class=""><br class=""><div dir="ltr" class="">Sent from my iPad</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Apr 17, 2020, at 11:56 AM, John Malloy <<a href="mailto:jomalloy@gmail.com" class="">jomalloy@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><br class=""></div>What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?<div class=""><br class=""></div><div class="">(I am new at this company, and don't have access to all their resources) </div><div class=""><br class=""></div><div class="">We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)</div><div class=""><br class=""></div><div class="">We also have the RedHat Identity Management running here, but I am not familiar with this tool.</div><div class=""><br class=""></div><div class="">Any suggestions would be appreciated.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br clear="all" class=""><div class=""><div dir="ltr" data-smartmail="gmail_signature" class=""><br class="">John Malloy<br class=""><a href="mailto:jomalloy@gmail.com" target="_blank" class="">jomalloy@gmail.com</a></div></div></div></div>
<span class="">_______________________________________________</span><br class=""><span class="">bblisa mailing list</span><br class=""><span class=""><a href="mailto:bblisa@bblisa.org" class="">bblisa@bblisa.org</a></span><br class=""><span class=""><a href="http://www.bblisa.org/mailman/listinfo/bblisa" class="">http://www.bblisa.org/mailman/listinfo/bblisa</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">bblisa mailing list<br class=""><a href="mailto:bblisa@bblisa.org" class="">bblisa@bblisa.org</a><br class="">http://www.bblisa.org/mailman/listinfo/bblisa</div></blockquote></div><br class=""></div></body></html>