List of user groups command line

On Windows OS we can find the list of local user groups created on a system from Contorl Panel -> User Accounts. This information can be obtained from command line also using net command. Syntax is shown below.

Example: Running this command shows the following local groups on my system.

How to list the users in a local group?

Use the below command to know the list of members of a group from command line.

For example to get the list of all remote desktop users on a system we can run the below command.

How to find the list of all groups a user is member of?
You can run the below command to list the groups a user is member of. This command prints the details of the given user account. You can find the group membership information in the last two line of this command output.

Useful references, however “net use username” should be changed to “net user username”

Thank you Kennedy. Corrected the command.

Please get me a command which will display all local users as: LOGIN, FULL NAME, DESCRIPTION, GROUP etc..

I’d just like to express my frustration with this API. As you can see in these examples, thet net API localgroups functionality will happily list all members of a group. However the net user code completely ignores system accounts, as does most of the rest of what Windows makes available. Internally they are organized as a subclass of Win32_Account but not Win32_UserAccount. So it’s possible to retrieve a bunch of useless information from the Windows API. This happens with LookupAccountSid as well. If you give it an SID like S-1-5-20, it will give you an answer. But the answer it gives you can’t be used as input for anything else, which is obnoxious.

You can query if users exist by doing

SET /P query_user=What user do i look for?
::Take out /domain if you want to look on the local computer
Net User %query_user% /domain
if NOT %errorlevel% == 0 goto s_error_1
if %errorlevel% == 0 goto s_success_1

“net user /domain username” lists only the groups to which the username is a direct member. It can’t show nested groups. I was doing a quick check to see if a username was a member of a group:

net user /domain username | find “Group Name”

That fails since the user is not directly a member of “Group Name”. In reality, they are a member, as they’re a member of a nested group.

Any idea of a command line that will expand groups to look for a particular member? I’ve used the “dsquery” and “dsget” commands, but they are only present if the AD tools are installed.

Very useful thanks, didn’t worked for me the first time.

The command is not case sensitive.

For example “NET USER /DOMAIN MYDOMAIN/MyUser” Didn’t worked.

But “NET USER /DOMAIN MyUser” works fine!
So not necessary to put explicitly the domain.

By the way it means also you can’t query another domain than the main one you are logged on to ?

Is there any option where we can get the multiple user’s output in excel for local computer and remote computer
net user userName

How to list the users and groups of an AD Security Group when not a domain admin

I am on Windows 8 connected to domain.

I wish to view the users and groups of an AD Security group. I am not the owner of the group. The command:

shows the direct users of that group but does not show the groups within the group.

As an alternative to the Windows 8, I also have remote access to a Windows Server 2008 R2 and am an admin for that machine but not an admin for the domain. The program «dsget» does not appear to be installed.

This question is expanding on this one (511715)

3 Answers 3

Go to ‘Computer’, click on ‘Network’ from the left menu, in the top bar select ‘Search Active Directory’

You should be able to search for groups and view membership here, even if not an admin.

Run this from a command prompt to get the complete membership of an AD group (users AND groups). Tested on Windows 10.

There’s a handy Advanced Tab in there that supports partial string searches (starting with, ending with).

Sysinternals offers AD Explorer, a utility for listing the complete LDAP structure of an AD forest. It’s slighty overkill for your intended use, though.

I don’t know which permissions exactly are necessary for querying this data, but I guess any logged-in user can do it. I never had any problems querying just about everything, but maybe the domain at work isn’t secured properly.

Usability note: You need not enter your credentials if you’re logged on as a domain user.

You do, however, need the IP address or host name of a Domain Controller. It’s likely this is the same as your DNS server, so just fire up nslookup and try the address displayed there.

Check user group windows

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’m trying to find out if a specific users is member of a specific group in the Active Directory. Google shows me a lot of examples for loginscripts, Quest’s tool and local groups. I don’t need local groups but domain groups that are located in the Active Directory and that Quest tool needs installment which i can’t do unfortunately.

I don’t really have much to start with although I know how to add a specific user to a specific group. I need this to know if he already is member of that group or not.

I’m hoping for a simple solution.

This is what I have now:

But it keeps saying FALSE

Answers

Your script worked like a charm! Thank you for helping me again. I also found out that you need to use the CN name which was different than the login name from the Active Directory. When I changed Nathan with the real CN it worked.

Thank you again for helping so fast!

All replies

Your script worked like a charm! Thank you for helping me again. I also found out that you need to use the CN name which was different than the login name from the Active Directory. When I changed Nathan with the real CN it worked.

Thank you again for helping so fast!

I would only point out that the Common Name of the group (the value of the cn attribute) may not uniquely identify the group. The cn need only be unique in the OU or container. Also, the string $Group could match another group Common Name, or even another part of the Distinguished Name of another group. For example, if $Group is «West», it would match «cn=Western,ou=East,dc=domain,dc=com», as well as «cn=Sales,ou=West,dc=domain,dc=com», when neither is intended. However, these problems can be avoided by specifying the full Distinguished Name of the group, or at least enough of it to ensure uniqueness, like «cn=West,ou=Engr».

Also, I get your original code to work if I bind to the user object and pass the ADsPath of the user to the group object. For example, the following returns either True or False:

Richard Mueller — MVP Directory Services

What you are saying is true and as you can see in the code below I already did that. But it’s nice that you point this out because this is good advise!

I translated most of it to Dutch because I come from The Netherlands.

I tested this part of my script and it worked great. I have a CSV file which has a Group1 — GroupOU1 — Group2 — GroupOU2 and people can add 3,4,5 and more to it so that they can add as much groups as they want. This may look like a beginner made this because I am a beginner.

How to Configure a Domain User or Group

The deployment settings enable you to control which users or groups can access the MED-V workspace, as well as how long the MED-V workspace can be utilized and whether it can be used offline. You can also configure additional rules to control access between the MED-V workspace and the host.

All MED-V workspace permissions are configured in the Policy module, on the Deployment tab.

To allow users to utilize the MED-V workspace, you must first add domain users or groups to the MED-V workspace permissions. You can then set permissions for each user or group.

How to Add a Domain User or Group

To add a domain user or group

In the Users / Groups window, click Add.

In the Enter User or Group names dialog box, select domain users or groups by doing one of the following:

In the Enter User or Group names field, type a user or group that exists in the domain or as a local user or group on the computer. Then click Check Names to resolve it to the full existent name.

Click Find to open the standard Select Users or Groups dialog box. Then select domain users or groups.

Click OK.

The domain users or groups are added.

Note
Users from trusted domains should be added manually.

How to Remove a Domain User or Group

To remove a domain user or group

In the Users / Groups window, select a user or group.

Click Remove.

The user or group is deleted.

How to Set Permissions for a User or a Group

To set permissions for a user or a group

Click the user or group for which you are setting the permissions.

Configure the MED-V workspace properties as described in the following table.

On the Policy menu, select Commit.

Workspace Deployment Properties

Property Description General

Enable Workspace for

Select this check box to enable the MED-V workspace for this user or group.

Workspace expires on this date

Select this check box to assign an expiration date for the permissions set for this user or group.

When selected, the date box is enabled. Set the date, and permissions will expire at the end of the date specified.

Offline work is restricted to

Select this check box to assign a time period in which the policy must be refreshed for this user or group. When selected, the time period box is enabled. Set the number of days or hours, and at the end of the specified time period, the user or group will not be able to connect if the policy is not refreshed.

Workspace deletion options

Click to set the MED-V workspace deletion options. For more information, see How to Set MED-V Workspace Deletion Options.

Support clipboard between host and Workspace

Select this check box to enable copying and pasting between the host and the MED-V workspace.

Support file transfer between the host and Workspace

Select this check box to enable transferring files between the host and MED-V workspace. Select one of the following options from the File Transfer box:

Both—Enable transferring files between the host and the MED-V workspace.

Host to Workspace—Enable transferring files from the host to the MED-V workspace.

Workspace to Host—Enable transferring files from the MED-V workspace to the host.

Note
If a user without permissions attempts to transfer files, a window will appear prompting him to enter the credentials of a user with permissions to perform the file transfer.

Important
To support file transfer in Windows XP SP3, you must disable offline file synchronization by editing the registry as follows:

REG ADD HKLM\software\microsoft\windows\currentversion\netcache /V Enabled /T REG_DWORD /F /D 0

Click to set the advanced file transfer options. For more information, see How to Set Advanced File Transfer Options.

Enable printing to printers connected to the host

Select this check box to enable users to print from the MED-V workspace using the host printer.

Note
The printing is performed by the printers defined on the host.

Enable access to CD / DVD

Select this check box to allow access to a CD or DVD drive from this MED-V workspace.

Multiple Memberships

If the user is part of a group and permissions are applied to the user as well as to the group they are part of, all permissions are applied.

If the user is a member of two different groups, the least restrictive permissions are applied.

User Account Control Group Policy and registry key settings

Applies to

• Windows 10
• Windows Server 2016

Group Policy settings

There are 10 Group Policy settings that can be configured for User Account Control (UAC). The table lists the default for each of the policy settings, and the following sections explain the different UAC policy settings and provide recommendations. These policy settings are located in Security Settings\Local Policies\Security Options in the Local Security Policy snap-in. For more information about each of the Group Policy settings, see the Group Policy description. For information about the registry key settings, see Registry key settings.

Group Policy setting	Registry key	Default
User Account Control: Admin Approval Mode for the built-in Administrator account	FilterAdministratorToken	Disabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop	EnableUIADesktopToggle	Disabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode	ConsentPromptBehaviorAdmin	Prompt for consent for non-Windows binaries
User Account Control: Behavior of the elevation prompt for standard users	ConsentPromptBehaviorUser	Prompt for credentials on the secure desktop
User Account Control: Detect application installations and prompt for elevation	EnableInstallerDetection	Enabled (default for home) Disabled (default for enterprise)
User Account Control: Only elevate executables that are signed and validated	ValidateAdminCodeSignatures	Disabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations	EnableSecureUIAPaths	Enabled
User Account Control: Run all administrators in Admin Approval Mode	EnableLUA	Enabled
User Account Control: Switch to the secure desktop when prompting for elevation	PromptOnSecureDesktop	Enabled
User Account Control: Virtualize file and registry write failures to per-user locations	EnableVirtualization	Enabled

User Account Control: Admin Approval Mode for the built-in Administrator account

The User Account Control: Admin Approval Mode for the built-in Administrator account policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account.

The options are:

• Enabled. The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
• Disabled. (Default) The built-in Administrator account runs all applications with full administrative privilege.

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

The User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.

The options are:

• Enabled. UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you do not disable the User Account Control: Switch to the secure desktop when prompting for elevation policy setting, the prompts appear on the interactive user’s desktop instead of the secure desktop.
• Disabled. (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the User Account Control: Switch to the secure desktop when prompting for elevation policy setting.

UIA programs are designed to interact with Windows and application programs on behalf of a user. This policy setting allows UIA programs to bypass the secure desktop to increase usability in certain cases; however, allowing elevation requests to appear on the interactive desktop instead of the secure desktop can increase your security risk.

UIA programs must be digitally signed because they must be able to respond to prompts regarding security issues, such as the UAC elevation prompt. By default, UIA programs are run only from the following protected paths:

• . \Program Files, including subfolders
• . \Program Files (x86), including subfolders for 64-bit versions of Windows
• . \Windows\System32

The User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting disables the requirement to be run from a protected path.

While this policy setting applies to any UIA program, it is primarily used in certain remote assistance scenarios, including the Windows Remote Assistance program in Windows 7.

If a user requests remote assistance from an administrator and the remote assistance session is established, any elevation prompts appear on the interactive user’s secure desktop and the administrator’s remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user may select the Allow IT Expert to respond to User Account Control prompts check box when setting up the remote assistance session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.

If you enable this policy setting, requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator’s view of the desktop during a remote assistance session. This allows the remote administrator to provide the appropriate credentials for elevation.

This policy setting does not change the behavior of the UAC elevation prompt for administrators.

If you plan to enable this policy setting, you should also review the effect of the User Account Control: Behavior of the elevation prompt for standard users policy setting. If it is configured as Automatically deny elevation requests, elevation requests are not presented to the user.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

The User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode policy setting controls the behavior of the elevation prompt for administrators.

The options are:

Elevate without prompting. Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.

Note Use this option only in the most constrained environments.

Prompt for credentials on the secure desktop. When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user’s highest available privilege.

Prompt for consent on the secure desktop. When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

Prompt for credentials. When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

Prompt for consent. When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

Prompt for consent for non-Windows binaries. (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

User Account Control: Behavior of the elevation prompt for standard users

The User Account Control: Behavior of the elevation prompt for standard users policy setting controls the behavior of the elevation prompt for standard users.

The options are:

• Automatically deny elevation requests. When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that is running desktops as standard user may choose this setting to reduce help desk calls.
• Prompt for credentials on the secure desktop. (Default) When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
• Prompt for credentials. When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

User Account Control: Detect application installations and prompt for elevation

The User Account Control: Detect application installations and prompt for elevation policy setting controls the behavior of application installation detection for the computer.

The options are:

• Enabled. (Default for home) When an application installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
• Disabled. (Default for enterprise) Application installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies such as Group Policy Software Installation or Systems Management Server (SMS) should disable this policy setting. In this case, installer detection is unnecessary.

User Account Control: Only elevate executables that are signed and validated

The User Account Control: Only elevate executables that are signed and validated policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.

The options are:

• Enabled. Enforces the PKI certification path validation for a given executable file before it is permitted to run.
• Disabled. (Default) Does not enforce PKI certification path validation before a given executable file is permitted to run.

User Account Control: Only elevate UIAccess applications that are installed in secure locations

The User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following:

• . \Program Files, including subfolders
• . \Windows\system32
• . \Program Files (x86), including subfolders for 64-bit versions of Windows

Note Windows enforces a PKI signature check on any interactive application that requests to run with a UIAccess integrity level regardless of the state of this security setting.

The options are:

• Enabled. (Default) If an application resides in a secure location in the file system, it runs only with UIAccess integrity.
• Disabled. An application runs with UIAccess integrity even if it does not reside in a secure location in the file system.

User Account Control: Run all administrators in Admin Approval Mode

The User Account Control: Run all administrators Admin Approval Mode policy setting controls the behavior of all UAC policy settings for the computer. If you change this policy setting, you must restart your computer.

The options are:

• Enabled. (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode.
• Disabled. Admin Approval Mode and all related UAC policy settings are disabled.

Note If this policy setting is disabled, the Security Center notifies you that the overall security of the operating system has been reduced.

User Account Control: Switch to the secure desktop when prompting for elevation

The User Account Control: Switch to the secure desktop when prompting for elevation policy setting controls whether the elevation request prompt is displayed on the interactive user’s desktop or the secure desktop.

The options are:

• Enabled. (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
• Disabled. All elevation requests go to the interactive user’s desktop. Prompt behavior policy settings for administrators and standard users are used.

When this policy setting is enabled, it overrides the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode policy setting. The following table describes the behavior of the elevation prompt for each of the administrator policy settings when the User Account Control: Switch to the secure desktop when prompting for elevation policy setting is enabled or disabled.

Administrator policy setting	Enabled	Disabled
Prompt for credentials on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for consent on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for credentials	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.
Prompt for consent	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.
Prompt for consent for non-Windows binaries	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.

When this policy setting is enabled, it overrides the User Account Control: Behavior of the elevation prompt for standard users policy setting. The following table describes the behavior of the elevation prompt for each of the standard user policy settings when the User Account Control: Switch to the secure desktop when prompting for elevation policy setting is enabled or disabled.

Standard policy setting	Enabled	Disabled
Automatically deny elevation requests	No prompt. The request is automatically denied.	No prompt. The request is automatically denied.
Prompt for credentials on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for credentials	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.

User Account Control: Virtualize file and registry write failures to per-user locations

The User Account Control: Virtualize file and registry write failures to per-user locations policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software.

The options are:

• Enabled. (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry.
• Disabled. Applications that write data to protected locations fail.

Registry key settings

The registry keys are found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. For information about each of the registry keys, see the associated Group Policy description.