"Move-QADObject : 0000202B: RefErr: DSID-031007EF, data 0, 1 access points"
I get this error when I try the following:
Move-QADObject -identity $results_ep.dn -NewParentContainer "OU=Users,OU=AB,DC=domain,DC=local" -Credential $cred_ep
I am running this script from domain A, and the target domain where the object should be moving is domain B (hence the credentials).
Anyone know whats up?
The default tree in Active Directory is not OU=Users,dc=domain,dc=com but rather cn=Users,dc=domain,dc=com ( CN= not the OU= for Users).
Try change OU=Users with CN=Users
EDIT:
Reading better your question I see just now that you want move object to a different domain,
from get-help move-qadobject:
... omissis ...
Use this cmdlet to move an object between containers within an Active Directory domain (the cmdlet cannot move an object to a different domain).
... omissis ...
Read here to do it with Quest.ActiveRoles.ADManagement sanp-in.
If you are in a Windows Server 2008 R2 DC you can move in a different domain using Windows PowerShell module named Active Directory:
Move-ADObject -Identity "CN=Mary Vick,OU=Accounting,DC=SS64,DC=com" -TargetPath "OU=Accounting,DC=Europe,DC=SS64,DC=com" -TargetServer "server64.europe.SS64.com"
Better of all I think is using native Microsoft commandline like ADMT
Related
PS Version: PowerShell 7+
OS Version: Windows Server 2016
Objective: I would like to use PowerShell to get the permissions of an AD schema object without the need of the Active Directory PsDrive / PsProvider.
The Active Directory PsProvider that comes with the AD Module does not work with PowerShell 7+ on Windows Server 2016 from my testing. This MS documentation also touches on that. Because that PsProvider is needed to create/use an Active Directory PsDrive, you can't access AD objects like this AD:\. Using this method is typically what I prefer. Below is an example of exactly what I need except I'm using Windows PowerShell and not PowerShell 7+.
This gets the configuration schema permissions:
(Get-Acl "AD:$((Get-ADRootDSE).schemaNamingContext)").Access
An example of the distinguished name for that object:
CN=Schema,CN=Configuration,DC=my,DC=domain,DC=com
With the limitations outlined, what other options within PowerShell 7+ can I use to access those permissions?
• According to the command that you have run on powershell in Windows Server 2016, it displays the active directory schema permissions of the concerned domain. But when running this command in my environment with Powershell 7.0+ installed as you can see in the image below, I got the same appropriate output as in normal powershell.
• Though you can change the permissions relating to schema objects by using the query as given below: -
Add ACL rule for the right "Read-write all properties/this object and all descendants" –
$rootdse = Get-ADRootDSE
$extendedrightsmap = #{}
Get-ADObject -SearchBase ($rootdse.ConfigurationNamingContext) -LDAPFilter `
"(&(objectclass=controlAccessRight)(rightsguid=*))" -Properties
displayName,rightsGuid |
% {$extendedrightsmap[$_.displayName]=[System.GUID]$_.rightsGuid}
$extendedrightsmap
Please find the below link for more information: -
https://social.technet.microsoft.com/wiki/contents/articles/51121.active-directory-schema-update-and-custom-attribute.aspx
I need the ability to have users run a script that requires the ActiveDirectory module. I copied over the following:
"C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ActiveDirectory", "Microsoft.ActiveDirectory.Management.resources.dll", "Microsoft.ActiveDirectory.Management.dll".
The script runs two Get-ADUser commands, 1 without the -Server parameter and the other with. The issue is that the former is working but the latter is not.
Is there another module that I need to copy over?
I don't like the idea of installing administrative tools for non-admins. Even if you could get away with copying files and not doing the full-blown RSAT installation. Not the least of reasons is you are dramatically increasing the attack surface for malicious actors. The better solution is (Just Enough Administration) JEA, or a philosophically similar approach.
JEA / Contrained endpoints can get complicated, but a summary of what you can do looks something like this:
New-PSSessionConfigurationFile -Path 'C:\PSSessionConfigs\DemoPSEndpointConfig.pssc' -ModulesToImport ActiveDirectory -VisibleCmdlets "Get-ADUser"
Register-PSSessionConfiguration -Path 'C:\PSSessionConfigs\DemoPSEndpointConfig.pssc' -ShowSecurityDescriptorUI -Name DemoPSEndPoint
Run these commands on a system that has the ActiveDirectory module (likely the whole RSAT component) installed, it doesn't need to be a Domain Controller. It will create a new PowerShell remoting endpoint configuration that exposes only the commands you wish. The Register-PSSessionConfiguration command will display a security dialog where you can permission which users you want to allow to connect, you want to grant them read & execute permission. Once that's done, you can get the results with an Invoke-Command command like this:
Invoke-Command -ComputerName <ServerName> -ConfigurationName DemoPSEndPoint -ScriptBlock { Get-ADUser <UserName> }
You can add the -Server parameter in the command without issue. You can expand the cmdlets you are allowing in the New-PSSessionConfiguration command.
Again this is very much a summary of a more complex topic but should be enough to get what you want.
Personally, I don't use configuration files as much as I use startup scripts. I think the latter is more flexible. You can get some information about that here. If you really want to dig into this there are references at the end of the article including a link to the PowerShell JEA documentation. There's also a link to some of the MVP articles I used to develop my own endpoints.
The ActiveDirectory module is dependent on the RSAT (remote server administration tool). This is avalible to install/activate through powershell: https://mikefrobbins.com/2018/10/03/use-powershell-to-install-the-remote-server-administration-tools-rsat-on-windows-10-version-1809/
With this installed you automatically also get the Activedirectory module installed.
I am currently building a Hyper-V lab consisting of a DC and multiple networked VMs, using Windows Server 2016. I'd like to completely disable the windows firewall for all existing and newly created VMs.
The best way that I've found to do this so far is via Group Policy for the Domain Profile. Then set Windows Firewall: Protect all network connections to disabled. What I would like to do is to have a way of scripting this out (using Powershell if possible).
I've found that by performing the above steps in the GUI, it creates a few entries in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\WindowsFirewall\DomainProfile
In each of those entries, there is a property called EnableFirewall which is set to 0. So I tried creating all of this using Powershell like this:
New-Item -path "HKLM:\SOFTWARE\Policies\Microsoft" -name WindowsFirewall
New-Item -path "HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall" -name DomainProfile
New-ItemProperty -path "HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile" -name EnableFirewall -value 0 -PropertyType DWord -Force
Unfortunately it doesn't seem to be working, so there must be something else that I'm missing.
Does anybody know how to completely disable the windows firewall for all networked machines using the command line in Windows Server 2016?
Setting up the Windows-Firewall for your domain-computers through computer-startup-script is not a great solution in my opinion.
You should definetly use Group Policy for this task.
GP does exactly what I want, I would just like a way of modifying GP using Powershell. I'm building a lab from scratch, and I'm looking to script as much of it as possible rather than using the gui.
I am not completely sure, what you are trying to achive.
You have created a lab now and I think you are trying to script a complete automatic built-up for future use. Is this correct?
If yes, then my solution is maybe what you are looking for:
Create a new GPO in your lab named "Firewall-Settings" for example.
Make all of your needed FireWall-Settings to the new GPO.
In Group Policy Editor open the main-node named „Group Policy Objects“. (important) Find the newly created GPO, right-click it and select "Backup":
Save the GPO-backup to a folder. (folder must exist)
The GPO is beeing saved and named like on the screenshot below (GUID):
That's it for the preparation. Now you maybe want to script the creation of the GPO with Powershell for future use and import the backup to obtain it's settings in a new environment:
New-GPO -Name "FireWall-Settings" | New-GPLink -Target "DC=mydomain,DC=local" # distinguishedName of Target-OU
Import-GPO -Path $PathtoGPOBackup -TargetName "FireWall-Settings" -BackupGpoName "FireWall-Settings"
The Script creates a GPO in the new environment with the name "FireWall-Settings" and links it to the target-OU.
After that you import the settings of the backup-GPO. All the domain-members in scope of the GPO will get the Windows-Firewall configured automatically.
Now the process is documented and fully automatic, if this is, what you are looking for.
Kind regards
open cmd prompt with elevated mode and run this:
netsh -r ComputerName -u Username -p Password -c advfirewall set allprofiles state off
If you want to do it for all the machines. Get all the ad computers using get-adcomputer. Run a foreach loop and put the variable istead of computername.
If you have the domain admin creds, then you are good to go with this.
Hope it helps.
Depending on the profile you want to disable, specify profiles (public, domain, private) using the -Name parameter. To disable all profiles for a networked machine, where $computerName array is the hostname of your DC, PC etc:
$computerName = 'DC1, PC1, MS1'
Invoke-Command -Computername $computerName -ScriptBlock {
Set-NetFirewallProfile -Name Domain, Public, Private -Enabled False
}
Get-ADUser -identity $ntaccount1 -properties name, samaccountname, mail, enabled, passwordlastset
Is it possible, when looking up the user account information in powershell, to specify a domain controller to use? We have some DC's that get the data faster than others.
From Get-Help Get-ADUser -Parameter *
-Server <string>
Specifies the Active Directory Domain Services instance to connect to, by providing one of the following values for a
corresponding domain name or directory server. The service may be any of the following: Active Directory Lightweight Domain
Services, Active Directory Domain Services or Active Directory Snapshot instance.
Domain name values:
Fully qualified domain name
Examples: corp.contoso.com
NetBIOS name
Example: CORP
Directory server values:
Fully qualified directory server name
Example: corp-DC12.corp.contoso.com
NetBIOS name
Example: corp-DC12
Fully qualified directory server name and port
Example: corp-DC12.corp.contoso.com:3268
The default value for the Server parameter is determined by one of the following methods in the order that they are listed:
-By using Server value from objects passed through the pipeline.
-By using the server information associated with the Active Directory PowerShell provider drive, when running under that drive.
-By using the domain of the computer running Powershell.
The following example shows how to specify a full qualified domain name as the parameter value.
-Server "corp.contoso.com"
Required? false
Position? named
Default value
Accept pipeline input? false
Accept wildcard characters? false
I know that this is a bit of an old question, but I would like to expand on the answer given, to aid anyone else who had a similar query.
The following allows you to define a specific Domain Controller, which the entire of a script would be able to use... Why might you want to do this when the -server parameter is available to Get-ADUser, New-ADUser, Set-ADObject, etc?
Well I put together a script that creates an AD user, sets multiple properties and creates an exchange mailbox - However, one set of properties revolves around the RDS properties on a 2008 R2 user account, which cannot be set from within New-ADUser. I had to create a function that calls ADSI and uses psbase.invokeSet to update the settings. There is no parameter setting for -server that I'm aware of.
This in itself wouldn't be a big deal, but the script also creates an Exchange mailbox for the user. As my Exchange server is in different AD Site from my workstation, the user account gets created on my local DC, but the mailbox isn't set, because the DC in the same site as the Exchange server hasn't yet received a replicated copy of the new user account.
The solution I found is as follows and is courtesy of http://www.joseph-streeter.com/?p=799
Having loaded import-module activedirectory, you'll have access to AD options in the New-PSDrive commandlet which among everything else allows you to define a new Active Directory Provider to work with.
New-PSDrive -Name <<NameofYourChoice>> -PSProvider ActiveDirectory -Server <<DC Server>> -Root "//RootDSE/" -Scope Global
Once created, you can then change the working Provider with the following command.
CD <<NameofYourChoice>>:
To view the existing list of Providers, type Get-PSDrive. AD is the default Active Directory Provider created when using the ActiveDirectory commandlet. You should also see your newly created Provider.
So for instance if my remote DC is called RemoteDC I would run:
New-PSDrive -Name RemoteAD -PSProvider ActiveDirectory -Server RemoteDC -Root "//RootDSE/" -Scope Global
to create a new Provider called RemoteAD. If I then run:
CD RemoteAD:
All further active directory related commands in the script or the active shell will work with the new Provider RemoteAD. If I would need to change back to my original Provider, I'd simply type
CD AD:
Hope someone finds this useful...
This is what i use:
Get-ADUser -server dcservername.domain.local -identity username
I am writing a simple script to copy AD group membership from one user to the other. I am doing it using the ActiveDirectory module only.
The script looks like it would work and does work up until I try to ad the groups to the user.
Code:
import-module ActiveDirectory
$templateUser = get-ADUser user1
$targetUser = getADUser user2
$groups =get-adprincipalgroupmembership $templateUser
$groups2 = get-ADPrincipalGroupMembership $targetUser
foreach($group in $groups) {
add-adGroupMember $group $targetUser
}
Error:
Add-ADGroupMember : insufficient access rights to performt the operation
At line:9 char:18
+ FullyQualifiedErrorID : Insufficient access rights to perform the operation,Microsoft.ActiveDirectory.Management.Commands.AddADGroupMember
Notes/Thoughts:
I am logged in as a normal user, but I ran the powershell as a different user (my admin account). I am not a local admin, but I am an admin on the domain. I am able to add the user to groups if I launch the AD Tools and do it manually (I have permissions to add to those groups).
Edit:
Run the powershell as admin.
Run powershell as administrator.
I hit this today in Server 2012. I was running the powershell as Administrator, I was a domain admin, I was a local admin, I was every kind of admin I could find.
I "fixed" it by using the Active Directory Users and Computers tool, adding myself as the Manager of the AD groups I was trying to add users to, and ticked the box to allow the manager to change membership. I could then run AD-AddGroupMember happily.
I ran into this problem as well using Powershell remoting to connect to a domain controller.
In my case it turned out Include inheritable permissions from this object's parent was turned off for the specific object I couldn't change.
I ran into this issue today where an automated system was using powershell scripts for various things.... It turned out to be executionpolicy.
We were running our script with the ExecutionPolicy Bypass flag, and even running the command directly in powershell outside of a script wouldn't work, but once we set executionpolicy to unrestricted, everything magically worked.
For us we were able to create security groups even, but not add users to groups via powershell, even though we could make the same changes in ADUC.