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
Related
Are personal Exchange mailboxes having FullAccess permissions on their own mailboxes via their UPN rather than "NT AUTHORITY\SELF" a problem?
One user ran into a problem regarding Outlook tasks that would duplicate on a shared mailbox. As it turn out, the issue was only resolved once I removed the mailbox permission that was given through their UPN, and then added it back with "NT Authority\SELF" with PowerShell.
In an attempt to avoid this kind of issue in the future, I ran an analysis of all the user mailboxes to check if other users had the same configuration. Turns out there is, and I'm trying to ascertain wheter this practice is common if it can be problematic.
I couldn't find much on this, other than the couple of cases where this particular issue was encountered regarding multiplying Outlook Tasks.
folks,
my Active Directory accounts with admin privileges all start with the same characters: "ad" followed by a dot and the name of the admin. Example: "ad.tim".
I would like to have admin accounts (every account beginning with "ad.") automatically deleted (profiles and user data) by the Windows clients and would like to distribute a Powershell script to my clients (better ideas are welcome).
I'm not very familiar with Powershell nor Scripting, but I allready figured out (thanks, Google) how to list all Accounts:
Get-WMIObject -Class Win32_UserProfile | select LocalPath
Now I'd have to filter (-like ad.*) and delete, but I'm not sure how or where to install it. It would be great if someone could give me some information so that I can better understand it and reach my goal!
Background
Working in a small O365 environment that recently upgraded from E3 to E5.
Issue
The audit log shows that a user enabled DeliverToMailboxAndForward on their mailbox with the Set-Mailbox operation.
Questions
Is PowerShell the only way to issue Set-Mailbox or can it be done
through the GUI somehow?
Is there a way to disable/prevent users from settings this (i.e. do the end users have too many permissions)?
When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is False. Is this the only way to ensure the action is disabled? Does the disable action appear in any event/audit log?
Is PowerShell the only way to issue Set-Mailbox or can it be done through the GUI somehow?
As an Exchange admin, you can use the Exchange Admin Center (EAC) to go to the Mailbox properties -> Mailbox Features -> Under Mail Flow, select View details -> Check the Enable forwarding, and Browse to the recipient.
Configure email forwarding for a mailbox
Is there a way to disable/prevent users from settings this (i.e. do
the end users have too many permissions)?
From a user perspective they can forward using the Outlook GUI:
Forward email from Office 365 to another email account
When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the
ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is
False. Is this the only way to ensure the action is disabled? Does the
disable action appear in any event/audit log?
You can use either the PowerShell script to query, or navigate through ECA console to verify. The disable action should appear in the audit if it is set up.
On to the issue,
The audit log shows that a user enabled DeliverToMailboxAndForward on
their mailbox with the Set-Mailbox operation.
Typically most users don't have access to the Exchange Management Console, and the ability to run PowerShell operations. That makes this audit entry "seem" odd. But then digging through the docs I come up to this entry:
Cmdlets that are run directly in the Exchange Management Shell are
audited. In addition, operations performed using the Exchange admin
center (EAC) are also logged because those operations run cmdlets in
the background.
Administrator audit logging in Exchange Server
So what you are likely seeing is an entry that is a GUI running a cmdlet in the background, without the user actually having direct Exchange Management Shell access. As for permissions, I'm not sure about explicit permissions to deny this specific action without denying a lot of other stuff (i.e. it's like denying permissions to forward messages) unless you have a business need to do this.
This question may get a better response in an Office 365 forum, but I'll try to answer your questions:
The GUI/Web UI is executing PowerShell commands on the back end when users change their configuration. In order to be allowed to change a setting in the GUI, the same permission needs to exist for the PowerShell cmdlets.
This permissions is a default included in the MyBaseOptions management role for Office 365 mailbox users. This role includes many other permissions which users require to manage their own mailbox, such as permissions to create inbox rules or update their picture. You can see all the actions included in this role with this command:
Get-ManagementRole -Identity mybaseoptions |Select -Expand roleEntries
The easiest way to audit current mailbox settings is likely running the command as you have done. A more efficient way to query all your mailboxes for just those with specific settings is to use the -Filter parameter on the Get-Mailbox command like this:
Get-Mailbox -Filter {DeliverToMailboxAndForward -eq $true -and ForwardingSMTPAddress -ne $null}
I hope that helps answer your questions!
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 running Outlook 2010, Exchange 2010, and Windows Server Std 2012. I want to view the owner and permissions of a shared folder for an email user without prior knowledge through the exchange shell.
The Scenario
In outlook, user1 creates a folder named “shared” under their mailbox. User1 then adds permissions to said folder allowing user2 to read and write. User2 then adds the folder named “shared” by utilizing outlook’s “Add another person's mailbox” found in the email account settings. The shared folder will now replicate any data that is place in it by either user.
From the exchange management shell, how can I tell that User2 has access to a share folder in User1’s mailbox without knowing about User1 or that a share even exists?
I have tried several commands and scripts found on the internet; however my guess is the mailbox/folder permissions are stored in exchange for User1, but offline for User2.
If needed, I can provide links to scripts and list of commands tomorrow.
Update #1 10/29/2013
Get-MailboxFolderPermission only produces permissions for specific folders i.e. Get-MailboxFolderPermission -Identity User2:/foldername. This will not work because when I run Get-MailboxFolderStatistics -Identity userid, which lists all folders for a user, the shared folder does not appear. More So, when user the Get-MailboxFolderPermission -Identity User2:/shared it too does also not work. But remember, I’m trying to deduce the presence of a shared folder without prior knowledge.
So if it doesn’t list it as a folder it must be a mailbox right? Cause, after all, I am using the “Add another person's mailbox” in outlook to add this shared folder. However, Get-Mailbox userid | Get-MailboxPermission does not show that User2 has permission to access User1 shared folder under their mailbox.
In addition, I have also tried the script found here
http://exchangeblog.pl/en/2013/03/list-exchange-mailbox-folder-permissions-script/
that list all folder permissions in a mailbox.
Now if i take the commands above and point them to User1, I can see a folder name shared and User2 permissions. However, once again, In my scenario, I do not know about User1 or a shared folder exists.
Update #2 10/30/2013
It is not a public folder as it was 1) not configured in that manner and 2) does not show when any of the Get-PublicFolder commands are used.
Use Get-MailboxFolderPermission to get the delegate permissions on mailbox folders.
http://technet.microsoft.com/en-us/library/dd335061(v=exchg.141).aspx
Note this cmdlet uses a rather odd Identity syntax primarysmtpaddress\folder path to specify the folder to get the permission on.