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!
Related
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.
Now, before I start, I will let you in on a secret: this is on a Domain Controller.*
*The above statement is stricken due to irrelevance as the only significant change that occurs to the Local Administrator account and the Local Administrator Group (within the context and scope of this question) is minimal and doesn't alter the outcome enough to require differentiation.
I didn't have this kind of trouble on any of the other servers and I am willing to bet that the reason behind it is because it is on a DC.*
*Same reason as stated above. The accepted answer explains the inconsistency and was an oversight on my part, not the architecture (read features) of Windows Security or Domain Controllers.
I have been playing around with a few ideas on how to check if a script has been called from an account that is either the local Administrator or, at the very least, called by an account that is part of the Local Administrators group.
I have renamed the local Admin account, however, I know that I can see if the script has been called by local Admin account by typing:
(New-Object System.Security.Principal.NTAccount('reserved')).Translate([System.Security.Principal.SecurityIdentifier]).Value
and I can see if the SID ends in -500.
The problem occurs when I run a condition to see if the calling account is part of the Administrators group (which is a larger scope) by typing:
PS> [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups -match "S-1-5-32-544")
PS> False
A quick check to see what account it was using:
PS> $env:username
PS> reserved
or the needlessly complicated way (though I prefer it sometimes):
PS> Write-Host ((Get-WmiObject Win32_Account | ?{$_.SID.Substring($_.SID.Length-4,4) -eq '-500'}).Caption).Split("\",2)[1] -fore GREEN
PS> reserved
and I even type:
PS> net user reserved
where it tells me Local Group Memberships *Administrators.
I pull up ADUC (dsa.msc) and I look in the Builtin container and double-click on the Administrators group. I select the Members tag and lo, and behold, reserved is actually a member!
So, a recap:
By typing net user reserved, I was able to verify it was part of the Local Administrators group
I looked in ADUC and verified reserved was a member of the builtin Administrators group
I ensured reserved was indeed the Local Administrator account by verifying the SID started with S-1-5... and ended with ...-500
To take it a step further, I made sure the SID matched the Active Directory Group named "Administrators" by typing Get-ADGroup -Identity "Administrators". I then typed Get-ADGroupMember -Identity "Administrators" and made sure reserved was listed (it was AND the SID matched!).
When I check to see if the well-known Administrators Group SID is found in the Groups of that account (by getting the current Windows Identity), it says that it isn't.
What gives?
Why do I get every indication that it actually is a member of the Local Administrators group but that SID isn't found in the account's groups?
When a computer is promoted to a domain controller, there are no more local users or groups on the machine. Member computers have local users and groups, and can also use domain users and groups for authentication, but on a DC, there are only domain objects.
See also: https://serverfault.com/a/264327/236470
I happened to stumble across something and I realized the answer to this question. For the sake of those that come here looking for assistance, here is the answer to my question:
Very simply--in regards to Powershell--if the Administrator Group SID (S-1-5-32-544) does not show up in the Groups of the user, that is a first-line indication that the script is not running with Administrative credentials.
For example, when I type out:
([Security.Principal.WindowsIdentity]::GetCurrent()).Groups
and I do not see the Administrator Group SID listed even though I know for a fact that the account I am signed into is a member of the Administrator Group, it means the current Powershell process does not have Administrative credentials.
If you click Run As Administrator and type the same as above, you will see that it lists the Administrator Group SID in Groups.
The reason why I was experiencing the inconsistency is simply because I was not running the Powershell process as an Administrator.
So, in short, there are a few ways you can check to verify if your current Powershell session has Administrator credentials. The first one is found in countless websites around the internet and is very common (I did not write this one):
$myWindowsID = [Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal = New-Object Security.Principal.WindowsPrincipal($myWindowsID)
$adminRole = [Security.Principal.WindowsBuiltInRole]::Administrator
if($myWindowsPrincipal.IsInRole($adminRole)) {
\\ TODO: Process is running as Administrator
Clear-Host
} else {
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "Powershell"
$newProcess.Arguments = "& '" + $script:MyInvocation.MyCommand.Path + "'"
$newProcess.Verb = "runas"
[System.Diagnostics.Process]::Start($newProcess)
exit
}
Here is another way (I did write this one):
[Security.Principal.WindowsIdentity]::GetCurrent() | %{
if($_.Groups -contains "S-1-5-32-544") {
\\ TODO: Process is running as Administrator
Clear-Host
} else {
Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
exit
}
}
# The Foreach-Object (%) could be replaced with another pipeline filter
I see a lot of people asking this question and because of Powershell appealing to many Systems Administrator (especially ones without a background in programming), I really think this will come in handy for others down the line.
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.
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.