Removing AccessRights - WARNING: An inherited access control entry has been specified and was ignored - WARNING: An inherited access control entry has been provided and was ignored

So this just happed:

Remove-MailboxPermission -Identity SharedMailboxAlias -User Username -AccessRights FullAccess -InheritanceType all

Confirm
Are you sure you want to perform this action?
Removing mailbox permission "SharedMailboxAlias" for user "UserName" with access rights "'FullAccess'".

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
WARNING: An inherited access control entry has been specified: [Rights: CreateChild, Delete, `

ReadControl, WriteDacl, WriteOwner, ControlType: Allow]  and was ignored on object `

"CN=SharedMailboxAlias,OU=Shared Mailboxes,OU=Mail,DC=Domain,DC=lan".

Checked to see what was keeping me from removing the access rights:

Get-MailboxPermission -Identity SharedMailboxAlias -User UserName

Identity             User                 AccessRights                 IsInherited Deny
========             ====                 ============                 =========== ====
Domain.lan/Mail/S... Domain\UserName      {FullAccess}                 True        True
Domain.lan/Mail/S... Domain\UserName      {FullAccess}, Delete...      True        False

And there it was, the "IsInherited" value True.
So its coming from above...

So I had to go through and remove some legacy permissions from Exchange. This can be added at multiple levels so it’s aways a diagnostic trail to where this was added. Go through each of these and if IsInherited is set to False you’ve found out where it’s being applied from.

Get-MailBoxPermission Domain\UserName

Get-MailboxDatabase | Get-ADPermission -User Domain\UserName

Get-ExchangeServer | Get-ADPermission -User Domain\UserName

Get-OrganizationConfig | Get-ADPermission -User Domain\UserName

Remove the Permissions per level with

Get-MailBoxPermission Domain\UserName | Remove-ADPermission

Get-MailboxDatabase | Get-ADPermission -User Domain\UserName | Remove-ADPermission

Get-ExchangeServer | Get-ADPermission -User Domain\UserName | Remove-ADPermission

Get-OrganizationConfig | Get-ADPermission -User Domain\UserName | Remove-ADPermission

Some of the permissions where also added from AD.

Open up ADSI Edit and Navigate to these :

In “Default Naming Context” OU=Microsoft Exchange Security Groups,DC=Domain,DC=lan
In “Default Naming Context” CN=Microsoft Exchange System Objects
In “Configuration” CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=lan

Make sure the user is not in any of these.
After the User has been removed from any of these places its inheritance is gone is no longer listed.

Disable/remove PowerShell V2.0 and why you should

Microsoft is planning to deprecate PowerShell V2.0 in the upcoming fall creator update.
The reason why you should remove or disable it is basically, it's old.
And old in computercountry doesn't work well when it comes to security.
Another reason to remove it is because PowerShell V2.0 can be used for lateral movement and persistence techniques with the same functionality. PowerShell V2.0’s extra value is that because it does not have native logging capabilities, it remains undetected and offers stealth in attacker operations.

PowerShell V2.0 was first seen on Windows XP and Server 2003 then on Vista and 7, Server 2008. When Windows PowerShell 3.0 was released as part of Windows 8, Server 2008 R2, and WMF 3.0, Windows PowerShell moved to a newer version of the .NET Framework (CLR4) that was not compatible older applications. In order to maintain backwards compatibility with these older applications, Microsoft kept Windows PowerShell 2.0 as an optional, side-by-side component in later versions of Windows and Windows Server.

As PowerShell Core 6.0 (and PowerShell 7 is in development) enters the marketplace, Microsoft will reduce the complexity of the PowerShell ecosystem. Removing an outdated version of .NET from the equation makes development easier for cmdlet and script authors by focusing on the .NET Standard ecosystem that includes only .NET Framework 4.6+ and .NET Core 2.0.

You can check whether Windows PowerShell 2.0 is installed by running the following (as an administrator).

On Windows 7/8.1/10, the following will return a State as either Enabled or Disabled:

Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2

On Windows Server, the following will return an InstallState of either Installed or Removed:

Get-WindowsFeature PowerShell-V2

To disable PowerShell V2.0 run PowerShell with elevated privileges (run as administrator).

Enter the following:

Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

This command should disable both "MicrosoftWindowsPowerShellV2Root" and "MicrosoftWindowsPowerShellV2" which correspond to "Windows PowerShell 2.0" and "Windows PowerShell 2.0 Engine" respectively in "Turn Windows features on or off".

Prevent account discovery - AzureAD read access and how to block it

This is some serious stuff from Mauricio Velazco.

Account discovery is the technique that allows an adversary to enumerate domain accounts in order to obtain situational awareness on a target network.

This can easily be prevented:

(Assuming you installed the MSOnline module)

Connect-MsolService

Then Sign in with an account in Azure Active Directory that has the Global administrator role assigned.
Perform multi-factor authentication, when prompted.
Execute the following line of PowerShell to configure the Azure AD tenant:

Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $false

Check to see the setting is active:

Get-MsolCompanyInformation | select UsersPermissionToReadOtherUsersEnabled            
            
UsersPermissionToReadOtherUsersEnabled            
            
                                 False