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.
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 want to be able to set an email forward in Exchange Powershell O365
I'm trying
Set-Mailbox -Identity emailaddress -DeliverToMailboxAndForward $true -ForwardingSMTPAddress forwardingaddress
but getting
A parameter cannot be found that matches parameter name
'DeliverToMailboxAndForward'.
Do I need to load a snap-in? I can't find any help about this.
You forgot your $'s my friend
Set-Mailbox -Identity $emailaddress -DeliverToMailboxAndForward $true -ForwardingSMTPAddress $forwardingaddress
Also something to look out for when using Exchange Online PSSession (and maybe regular Exchange PSSession) is that it uses the JEA functionality of PowerShell. JEA is Just Enough Administration it actually looks at what roles the account used to connect to the PowerShell Session has and it ONLY gives you the commands that account has the roles to do. I'm not sure if it goes to the level of removing parameters from functions you only have partial access to do. For the missing Cmdlet part though I ran into this while beating my head against the wall writing a batch migration utility come to find out SysAdmin never gave me the permission to do batch migration. As soon as They gave me the permission and I imported the PSSession again BAM Cmdlet was there.
Hope that helps.
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.
How can I auto delete Junk E-mail folder Exchange 2010 in OWA if I have Exchange 2010 Standard license and standard license CALs?
Custom retention policy tags won't work because it needs Exchange Enterprise license and CALs.
Currently I use this command, but I need to script the command to delete messages from a specific folder in OWA.
Search-Mailbox -Identity User -SearchQuery "Subject:'*[Spam]' sent:<$("10.06.2016")" -Delet
eContent -confirm:$false
You can use Get-Mailbox to pass mailbox identities to the Search-Mailbox command similar to the way described in this question. Ex:
Get-Mailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery "Subject:'*[Spam]' sent:<$("10.06.2016")" -LogOnly -LogLevel Full
There are a few things to keep in mind when using Search-Mailbox this way. It can't search JUST the spam folder, so test your queries using the -LogOnly switch. You may want to further limit the kind of mailboxes retrieved by using -RecipientTypeDetails to retrieve only UserMailbox types. Regardless of what you're trying to delete, be sure you are getting only the results you want from your query before pulling the trigger on -DeleteContent.