I'm trying to use DSACLS command to grant specific permission to a User object. DSACLS command will only available if you have AD-Snapin installed.
When I run this command on a User object, it will list all of its object security permissions:
dsacls "CN=Aaron Ooi,OU=Users,OU=IT,DC=Domain"
The permission that I want is from the list called:
Allow BUILTIN\Windows Authorization Access Group
SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
READ PROPERTY
How do I use this command to apply the similar permission above to another User account? I cant seem to figure it out from the help menu.
If similar requirements could be done in PowerShell would be great as well.
After Google everywhere, DSACLS could not do the work for special access permission. Then I looked for my answer in PowerShell and manage to find the solution:
You need to install Quest ActiveRoles for the PowerShell command:
http://www.quest.com/powershell/activeroles-server.aspx
After install, turn on the snap-in:
Add-PSSnapin Quest.ActiveRoles.ADManagement
Command to get the AD Object security permission:
Get-QADPermission UserID -Inherited -SchemaDefault
Command to set the AD Object security permission:
Add-QADPermission UserID -Account "Windows Authorization Access Group" -Rights "ReadProperty" -Property "tokenGroupsGlobalAndUniversal" -ApplyTo "ThisObjectOnly"
Issue resolved!
Related
I am trying to delete permissions on a public folder in Exchange Online. We inadvertently desynced mail-enabled security groups in AD-Connect. This caused all permissions to be lost in the migrated public folders (even after resyncing). I've since recreated the security groups in M365 and have the permissions working on the new groups.
However, I am unable to remove the permissions from the folder for any of the synced security groups. If I do it in the GUI it saves without error, but the permission is still there.
In Powershell, I attempt to remove the permission and receive an error of There is no existing permission entry found for user: Finance Group even though the entry shows there is. The Powershell output is below. This is my first post so I am not allowed to embed images yet - apologies.
Get-PublicFolderClientPermission "\Finance\Finance Departmental Calendar"
Powershell Results for Get-PublicFolderClientPermission
Remove-PublicFolderClientPermission -Identity "\Finance\Finance Departmental Calendar" -User "Finance Group"
Powershell Results for Remove-PublicFolderClientPermission
Thanks in advance.
If the issue is not just inheritance, microsoft has some recommendations here: https://learn.microsoft.com/en-us/exchange/troubleshoot/public-folders/public-folder-permission-issues
# check permissions on the primary pf mailbox specifically
Get-PublicFolderClientPermission \puf1 -User User1 -Mailbox (Get-Mailbox -PublicFolder | ?{$_.IsRootPublicFolderMailbox -eq "True"}).Name
# check permissions on the user's pf mailbox
Get-PublicFolderClientPermission "\puf1" -User User1 -Mailbox pubmbx1
# check the hierarchy sync status, and compare between pf mailboxes
$s = Get-PublicFolderMailboxDiagnostics pubmbx1 -IncludeHierarchyInfo
$s.HierarchyInfo
$s.SyncInfo.LastAttemptedSyncTime.LocalTime
$s.SyncInfo.LastFailedSyncTime.LocalTime
$s.SyncInfo.LastSyncFailure
# manually resync permissions to entire pf mailbox
Update-PublicFolderMailbox pubmbx1 -InvokeSynchronizer
Be careful of making changes in O365 if you're in hybrid config. You probably don't want to overwrite the newly-added permissions in O365 by surprise sync up from on-prem
In my anectodal experience, 365 also needs the original user object to exist for some reason. Probably buggy behavior with how it resolves the user name on permission entries. If possible, try and resync the old groups to 365
I have had to export, delete, and recreate a mailbox or publicfolder to fix certain rare situations
I'm connecting to Exchange Online using PowerShell and the following command:
Connect-ExchangeOnline -AppId APP_ID -CertificateFilePath CERTIFICATE_PATH -Organization ORG_NAME
And would like to use the "Search-Mailbox" cmdlet.
The docs say:
By default, Search-Mailbox is available only in the Mailbox Search or Mailbox Import Export roles, and these roles aren't assigned to any role groups.
The app has the Exchange administrator role assigned in Azure.
In Exchange admin center, I added Exchange administrators to the Discovery Management role group that has the Mailbox Search role enabled.
After reconnecting, Search-Mailbox is still not available:
Search-Mailbox: The term 'Search-Mailbox' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Could someone please explain why it doesn't work and how to make it work?
It worked after I assigned "Mailbox Search" role to the "Organization Management" role group (Exchange administrators role groups inherits from it).
When the CmdLet is not available it needs to be imported, installed or run on the correct server. It seems like Search-Mailbox is part of the module ExchangePowerShell.
I believe you either need to import the module in your PowerShell session:
Import-Module -Name 'ExchangePowerShell'
Or run the CmdLet on the Exchange server directly or use Connect-ExchangeOnline.
I want to check whether a given Active Directory user (specified by username and domain) has read/(write) permissions on a given folder. And this unrelated to having them granted directly by user name or indirectly by some group membership. However I've been googling like 5 hours by now to no avail.
I understand, that Get-Acl Cmdlet is used to read folder permissions. Most likely the user is member of some group, that indirectly grants it permissions.
So my idea was to just match the output of
(Get-Acl <Folder>).Access | ft
against the group membership of the user.
I collect the group Information using the command
Get-ADPrincipalGroupMembership "<Username>" | select name
but found out, that this features an entirely different set of group names. I assumed, that the groups outputted by Get-Acl are local ones, while the other ones were AD-sided groups.
I found the command whoami /groups, that prints all groups, but only for the currently logged in user.
After quite some additional time I figured out the command (based on .NET):
(New-Object Security.Principal.WindowsIdentity -ArgumentList #(,"<User#fullDomain.com>")).Claims | select Value
This however just prints SIDs, while
(Get-Acl <Folder>).Access | ft
displays some human friendly output like "NT SERVICE\TrustedInstaller" and such.
I believe I'm pretty close, but I just can't get it to work.
On another note: Does this really have to be that complicated?
Other solutions I found only work based on direct user permissions but do not check group permissions.
Oh and one thing: Everything has to run on PowerShell 4.0 on Windows Server 2012 R2 and the PowerShell script will be running locally. No NuGet packages or anything requiring an Internet connection are allowed.
I am working on proofing out if there is a way to automate a Global administrator's Azure AD access for other User role accounts in the same tenant to grant access to OneDrive.
If you navigate to portal.office.com and then click on a user's name, that will bring up some settings for that user. The setting I am referring to is under the dropdown for OneDrive Settings, (see attached image).
Is there a way to automate this process via some PowerShell cmdlet?
Solved
I found an article that shows how to run PowerShell commands via the SharePoint Online Management Shell
Tutorial link has the section for Prerequisites for setup: Easy Manage Multiple Office 365 Tenants with Windows PowerShell
Actual PowerShell commands:
$site = Get-SPOSite -Identity https://mydemo-my.sharepoint.com/personal/sarad_mydemo_onmicrosoft_com
Set-SPOUser -Site $site.Url -LoginName admin#mydemo.onmicrosoft.com -IsSiteCollectionAdmin $true
Tutorial: How to Get Administrative Access to the OneDrive for Business Environment for a User
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.