Link to home
Start Free TrialLog in
Avatar of Dan
DanFlag for United States of America

asked on

identifying all permissions of all users in windows AD and on each PC

Is there a way built into windows server or AD to find out what permissions all users have?  I am in the process of cleaning up my AD and want to tighten down my domain admin accounts.  For example, I also need to know which computers and users have full admin rights on their own computers?


Is there a way to do this with any built in tools to windows, or do I need to purchase any software and which one if needed?

Avatar of Hayes Jupe
Hayes Jupe
Flag of Australia image

Short answer - No.

Do you have a desktop management solution such as SCCM? If yes, you can inventory local admins. - https://eskonr.com/2017/03/sccm-configmgr-report-for-local-admins-and-local-group-members/
If not - you can do it - but you'll need to run some scripts.

alternatively, yes, you could probably purchase something for this. 
ASKER CERTIFIED SOLUTION
Avatar of Scott Silva
Scott Silva
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Dan

ASKER

Scott, thanks, I'm running it now.  I'm getting a lot of errors for computers, the below error, so I was wondering, what does this mean?  If a computer object is disabled, I'm assuming I'll get this error?
Also, I'm trying to figure out which computers are not in use, and the ones I need to disable, will this script help with that as well?  After I disable them, I will delete them.  

Also, I don't have all my computers in the "computers" container, so is that a problem, will the script search my entire AD?

Exception calling "Invoke" with "2" argument(s): "The network path was not found.
"
At C:\PS1scripts\LocalAdminAccount.ps1:11 char:1
+ $members = @($members.psbase.Invoke("Members"))
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException
 
The following exception occurred while retrieving member "GetType": "The network path was not found.
"
At C:\PS1scripts\LocalAdminAccount.ps1:12 char:21
+ $members | foreach {$_.GetType().InvokeMember("Name", 'GetProperty',
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException
    + FullyQualifiedErrorId : CatchFromBaseGetMember
Avatar of Dan

ASKER

Hayes, I dont have SCCM.  I use PDQ inventory to show me all my computers, but it doesn't show me the permissions.
It will only access running and domain joined computers... And if they are not in an OU called "computers" you might have to edit the script...
I have ou's for several divisions, but inside each of them I still have computers ou's and users ou's...Never tried it any other way...
They alsohave to be reachable by the computer you are running the script from and it needs to be run as an account that has access to all computers, like the domain admin account...

Avatar of Dan

ASKER

Scott, the script ran and it's completed.

I can see there's not that many compared to what my AD shows.  So it's only computers turned on.  Looks like it finds all computers across my entire domain, so that's great.  I'm assuming if a user is listed there, then it's enabled, right?
There won't be any disabled users listed there, for example, if the built in administrator account is disabled, will that be listed or no?

This helps, but how do I find out which computers were last turned on, as I want to disable and delete any old computers in my AD, as I'm trying to clean it up?

Also, is there a way to remotely remove admin rights for a user, or do I have to physically log in to the computer as administrator?

I think sometime soon, I need to install LAPS, because some users have the local administrator account and that's not good, it's a security issue.

Avatar of Dan

ASKER

Does this error just mean that the computer is turned off or disabled?

At C:\PS1scripts\LocalAdminAccount.ps1:12 char:21
+ $members | foreach {$_.GetType().InvokeMember("Name", 'GetProperty',
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException
    + FullyQualifiedErrorId : CatchFromBaseGetMember 
I do remember an error similar to that with every machine it couldn't reach.
As to removing accounts remotely, it can be scripted to running machines, and could also be scripted to login scripts...
Avatar of Dan

ASKER

Got it, so to get a better picture, I should run the script once a day for a few days to make sure I capture all computers turned  on?

If I only have a few machines to remove the local admin access, I'll just do it manually.
so while all the above is good.... if you just want to set local admin group members (approach it from the point of view that *this* is the new standard - then i will handle variations later) - you could just use group policy to set membership of the local admin group.... the downside is that people that currently have local admin will probably scream.... but that might be an acceptable way of finding them in your business? (if security is more important to your business right now - then its far quicker to just lock it down - then open up where required - as opposed to the other way around)
Avatar of Dan

ASKER

Hayes,  so how would I use GP to lock down local administrators group to only the  users or groups I want?
The best way is to lock down ALL users at the domain level and NO ONE has local admin... We don't even give our executives Local admin rights... They will only slime themselves with the first click thru virus they run across...

SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Dan

ASKER

So you're saying not even the IT department should have local admin rights, only to enter the user/pass when needed, right?
I'm not... IMO there should be a "workstation administrators" AD group.... which is an administrator on all workstations... this is seperate from server and domain admins - as per good security practice.

the "workstation admins" is added to the local administrator group on all machines... and then any IT support personnel are added to the "workstation admins" AD group.

IF any users genuinely require local admin (which is rare - most of the time its just a matter of setting file or registry security properly for a badly written app) - then utilise an additional group policy to grant that admin - so its managed in one place.
In my company even we IT admins use a different account to do admin tasks... We didn't, and we got spanked by an audit from our cyber security insurance vendors.
Anyone can get a zero day virus... If your daily account has "the keys to the city", then your entire network will get hosed...

Scott is correct again... admin and day-to-day accounts should always be seperate.... this is just a given to me.... but forget sometimes this isn't just "everywhere".

If you want best practice, then day-to-day, workstation admin, server-admin and domain admin accounts should all be separate - but that may be a bridge too far if your coming from a not-so-great existing security standopoint.
Avatar of Dan

ASKER

Hayes, I get what you're saying and agree.  The last part I'm not sure how that would be done, so let's say no one has local admin rights on their computers, but I have a person who's telling me they need it, how do I use GP to only apply local admin rights to that specific person?   Instead of doing that, would it be better to just create a local admin account and give them the password, so they can use it when prompted each time?
Yes your IT admins won't be happy, but this should be a management policy and they will get used to it...
The first couple days it was a PITA, but now I can type that password in my sleep...  lol
We don't give ANYONE local admin except when we have a vendor installing a complex server package, and then we require it to not need that user enabled to operate...
We even create separate service accounts where needed so auditing is easier...

Having a person tell you they need it and them ACTUALLY needing it are usually 2 different things...
They need to show WHY they need it...
Our VP of engineering told us he needed local admin, but he didn't get it...

Avatar of Dan

ASKER

Scott, so how do I give a user local admin if they need it, via GP?
Basically, you're saying no one gets it, and if it's needed, IT will go and take care of the issue, is you're saying, right?
Avatar of Dan

ASKER

Scott, true.
Ok, IMO the process is

- find why why they "need it".... 90% of the time, its an application that needs read/write to its install directory under C:\program files or a registry key under HKLM.... then you can make that part of your install process - no admin rights actually needed.
- in the cases where they really do need admin rights (e.g. tech's working around multiple isolated SCADA networks that need to update IP addresses etc), then you have two options
1) create a local admin account locally - and have them logon as that account for that one purpose
2) Use GPO to grant their account admin access over their machine only. Create a GPO, just like in the process above - add the username into local administrators (along with workstation admins) and then assign to that computer only. Ensure this policy has higher precedence in the OU.
Yes... Either I or the other admin will remote in and take care of whatever issue they have.
I also deploy patches and software remotely as much as possible...
We have about 300 pc's and laptops, and close to 100 servers... Plus cloud based apps...

Avatar of Dan

ASKER

What do you guys use for remote admin software?  We use teamviewer, but it seems clunky.
You say you have PDQ software? I also use that and you probably could create a dynamic collection based on local users... I never tried since I know we don't have any local admins these days...

We have a Connectwise account. 
Avatar of Dan

ASKER

How do you like that?
When I was the ONLY admin at both our offices I had a system running with VNC. It worked OK, but that was always users in the building... I had a VNC based app that remote users could pull from a website for their admin needs.
Or they could VPN in and I could use the VNC...
It got hard to scale, and a lot of tweaking to make the encryption work. Continuum works great, and it comes with a service that emails me when servers have issues, and when admin accounts get added to AD...

Avatar of Dan

ASKER

So which product are you using?
https://control.connectwise.com/?_ga=2.251388545.686917890.1648597789-679867964.1648597789

Looks like they have access, support and premium.  
We get it as part of a third party support contract.
Avatar of Dan

ASKER

I know the question is closed, but I ran a script to get the last logon date for all my users, and a lot of them have a date of:  
12/31/1600


I know some of those users haven't logged in for a few years, but why does it show all the same?
Have you tried running powershell as an admin?
Avatar of Dan

ASKER

Yes, I ran powershell as an admin.   There were about half of the users with days ranging from today to1 month ago as the last login date, but then I had at least half of the users that has a date of 12/31/1600, not sure what that means?  Does that mean the user never logged in before?  I know that's not true, as I have some users that logged in before, but still shows the 12/31/1600 date.
That seems like maybe a default date number for users that might have been logging on with cached credentials and not actually on the network...


For clarification... I have a domain admin account. When i right click the PowerShell icon then pick Run As Administrator, it runs correctly. If I don't, I get the issue you experience
Avatar of Dan

ASKER

That's what I did, I right clicked on "windows powershell ISE", selected "run as administrator"
Ran the script again, and still same results.