Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Comments

10 comments
Date Votes
  • Just to clarify, I have setup the report as outlined in the attached 'reportsetup.png' but the attached 'reportoutput.png' shows a PC included in the report that has no additional groups listed. Why is that PC in the report?

    0
  • Looks ok, you don't really need all those Filter Groups if they are all set to ALL, you only need the first one at the top.

    0
  • I'll expand a little on what I'm trying to do...

    We currently lock down local admins but don't lock down the group. We have a group of 'admin' users who are part of the IT_Admins group in AD who are local admins within the local PC. Some of these users have added their standard network user to the local admins group so want to lock this down.

    At the same time, there are other users that have legitimate local admin rights that I need to collate the information for so that I can tackle their individual rights separately, via groups in AD.

    So my report needs to show any local admin entries that don't correspond to the standard, hence why they are included. It's just as the original post linked at the top.

    Sorry for the long winded explanation, just wanted to outline why I'm doing this.

    0
  • You should prevent user accounts from being added to the local admin group once you get it sorted out. That's what I'm doing.

    0
  • Yes, that is my ultimate goal but before I do this, I want PDQ Inventory to provide me with a report of who has current access so I can identify any potential issues with implementing that setup. I'm trying to mitigate support tickets from users can't run software because they previously had local admin rights.

    0
  • Hi Jon,
    There is a difference in how the reports should be set up. Originally, the logic for the Local Group Member was a simpler and gentler logic, but it failed to meet certain complexity needs. That was changed and expanded (we're working on an update to the post you linked to). Since Local Group Members can contain both users and groups, you should use 'group' and 'name' as they apply to the membership you are trying to define.

    The two following images show you the following (this is an updated variation from the version found in the link you used as a reference):

    • ALL Computers that do not have "servers" listed in their AD parent path AND
    • ALL Computers where the local group member is Administrators [this should be the majority of your machines] AND
    • All Computers where Domain Users are a member of Administrators

    DomainUsersInAdministratorsColumns.png

    DomainUsersInAdministratorsFilters.png

    So, to do what you want you would want rules that indicate:

    • ALL Computers where the local group member is Administrators AND
    • ALL Computers where the local group member is NOT admin AND
    • ALL Computers where the local group member is NOT IT_Admins AND
    • ALL Computers where the local group member is not Domain Admins AND
    • All Computers where the local group member is not root

    And you probably want to exclude servers as well as the 'Administrator' user as well, since it's pretty ubiquitous, but test to see if this meets your needs.

    unapproved_users.PNG

    That should provide you the report you're looking for.

    1
  • Wonderful - works exactly as expected. Thank you very much.

    0
  • Bit of a thread ressurection.

    Would it be possible to pass the list of users to PDQ Deploy and run a command to disable/delete the unwanted local users?

    -1
  • Would it also be possible to change the password of a user you wished to keep?

    0
  • How would I get this to spit out the offending user name in the report without having to click on each individual machine name to see who it is?

     

    0