Wanted to add an answer to what I learned after researching and succeeding with this issue.
I have a Microsoft O365 account where I run my business. I am using Microsoft Teams so my executive team can see information and emails specific to that function. For instance, Human Resources. That team is setup to use humanresources#contoso.com as its email Office 365 Group. I want to add jobs#contoso.com as an alias to the group. But the O365 Admin panel or Exchange Admin Center (EAC) do not have that function available. How do you add an Alias to a Microsoft O365 Group?
There is a link that describes how to use PowerShell to add an alias:
Add Additional SMTP Aliases to Office 365 Groups
Concise Instructions
Open PowerShell.
Allow Remote, Signed scripts so you can import Microsoft O365 Exchange commands. We will set this back to default when done:
Set-ExecutionPolicy RemoteSigned
Enter your credentials so you can manage the O365 environment you are working on. It will prompt you for your username and your password:
$UserCredential = Get-Credential
Create a new PowerShell session to import the Microsoft O365 Exchange commands:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import the session. You should see the standard PowerShell progress bar as the commands are imported:
Import-PSSession $Session
Now you are ready to issue your commands. First, make sure you can read the properties of the Exchange Group:
Get-UnifiedGroup -Identity humanresources#contoso.com | FL EmailAddresses
It should output the aliases assigned to the Outlook Group.
To add the alias, enter this command. I will use my example in the question above to show what it looks like:
Set-UnifiedGroup -Identity humanresources#contoso.com -EmailAddresses #{Add="jobs#contoso.com"}
You can then run the Get-UnifiedGroup command and see the alias now listed in the email addresses.
Return to the default execution policy:
Set-ExecutionPolicy Default
Next Steps
At this point the group has an alias. You can email the alias internally to your O365 account. For instance, User1#contoso.com can email jobs#contoso.com and it will work correctly. It will be received in your O365 Human Resources group.
However, if you attempt to send email to the alias from external, you will get a 5.4.1 access denied error. You will get this even if you are able to email humanresources#contoso.com. (If you can't email the primary alias externally, you have another problem where the group is not set to receive external email, that can be set in the EAC.)
The problem where the alias cannot receive external email has to do with Directory Based Edge Blocking (DBEB). Essentially, before O365 performs any of its protection actions (anti-malware, anti-virus, SPAM, etc.) it performs a simple lookup into your Active Directory. It looks to see "Hey, does this user even exist here?"
For instance, if you are sending email to User1#contoso.com, DBEB looks up the directory and say, OK, that user exists, send it on. It does the same for humanresources#contoso.com. However, the lookup fails for additional aliases assigned to O365 Groups. There is a workaround.
Workaround
The workaround is disabling DBEB for the contoso.com domain. This does not disable the additional layers of protection of email hygiene (anti's, spam, etc.). To do so, you need to go into the EAC of your O365 account and change the Accepted Domains from Authoritative to Internal relay.
If you have natively started in O365, this is probably set to Authoritative. If you have a hybrid (O365 and Onsite), or did a migration from Onsite to O365 it is most likely already set to Internal relay (Unless post-migration you changed it to Authoritative). This is why for some people, just adding the alias works for them. DBEB is already disabled. Again, this only disables the first check of a valid user or not and the remainder of the hygiene stack is still in place.
After this change, your O365 Groups should now receive external email to their additional aliases.
Better Ways?
Yes, there should be better ways to add aliases to O365 Groups, like going to the group, selecting aliases, and adding them. That way we aren't in the shell and EAC making things work like they should. Microsoft, make it so!
Another way may be somehow to use New-EOPMailUser to create an entry in the Directory for the alias. When I tried to create a new Contact in the EAC, it stated that the email address was already in use. So, I got it to work and haven't looked at other options. I am assuming Microsoft will get aliases added in a more admin friendly way (PLEASE?!).
Keep Calm and Cloud On!
Wayne is spot on, however, there is a method to work around the DBEB issue. If you cycle each alias as the primary address (Cap SMTP) and then end back on the desired primary, all addresses will receive mail from outside addresses.
Set-UnifiedGroup -Identity "O365 Identity" -EmailAddresses SMTP:email#domain1, email#domain2, smtp:email#domain.onmicrosoft.com
Found the work around Here (The update at the very bottom)
If you are an admin, this works (at least for a Distribution Group) using O365.
Go to Admin
On the left, click Show All and then Exchange
In the Exchange Admin go to Recipients and then Groups
Double click the group.
Click Email Options
Click the + and add the additional email.
I've just done this and didn't have to do anything to allow me to email the alias externally (except configure the O365 Group to be able to be emailed externally). I checked the config of my Accepted Domains and they are both Authoritative. We are a cloud only tenant, so no hybrid, and I didn't muck around with the primary address.
To add to existing answers what worked for me:
Create a shared mailbox with desired e-mail.
Set up auto-forwarding
to O365 Group.
Extra hop, little hassle, same effect.
Related
I have a hybrid environment with on-prem exchange (almost done migrating) and O365 Email.
I create a new user in our on-prem AD via powershell. It syncs properly via AADConnect to our Azure environment and creates the O365 user and Exchange online (O365) email account. Using powershell I can correct proxy addresses and the msExchRecipient/Remote attributes.
The expected result is that I have an email account on both sides for the hybrid environment, with the on-prem Exchange srerver showing the Mailbox Type as "Office 365".
For one particular user, I ended up with email accounts in both on-prem and online exchange as expected. The user receives messages in their O365 account. However, messages that are trapped by our Mimecast server are not getting through. The Mailbox Type listed in on-prem is "User". This is messing up the mail routing for incoming messages from outside the domain.
Is there a way I can powershell my way out of this mess and somehow convert the mailbox type from "User" to "Office 365"? I can't migrate the user because the account already exists in O365. If I delete the O365 I would lose the email.
Should I have my powershell user creation script create the ad user, create the on-prem mailbox and also perform the migration? At least until we are fully migrated and out of our hybrid environment?
For this user, would it work to delete the AD and on-prem Exchange, and re-create both manually? How would I connect the on-prem to online exchange without losing the mail?
Any insight into this can of worms would be greatly appreciated.
One of the documents I referenced is this one about Recipient Type Values:
https://answers.microsoft.com/en-us/msoffice/forum/all/recipient-type-values/7c2620e5-9870-48ba-b5c2...
: Keith
I am currently using O365 Graph API to create services for customers and realized that some of the capabilities that customers need, i.e. creating transport rules or accessing quarantined email information, are only available through PowerShell.
Can a vendor create transport rules or execute PowerShell commands for their customers? Similar to how vendors register their Azure AD application and request permissions, is there a way to run PowerShell command for customers by a vendor?
Documentation is not really helpful on this front.
When using Graph, I don't think you can, but if you want to do it with Powershell, if you're a Microsoft Partner, and have configured yourself as an advisor (delegated access permissions) for your clients (invite them to add you, or add yourself if you have their consent and global admin access to their tenancy).
Adding a partner to a tenant:
https://learn.microsoft.com/en-us/partner-center/customers_revoke_admin_privileges
See a bit of additional info here:
https://learn.microsoft.com/en-us/office365/enterprise/powershell/manage-office-365-tenants-with-windows-powershell-for-delegated-access-permissio
When running Powershell commands, you'll need to refer to the TenantID when running a command on the client's tenancy (rather than your own).
A simple example of this might be:
Get a list of TenantIDs:
Get-MsolPartnerContract -All | Select-Object TenantId
Get a list of mailboxes for one of the TenantIds listed above:
Get-Mailbox -TenantID "asddfsdfadfg-dsfgsdfg-sdfgsdfg-dsfgsdfg"
This relies on you having logged into the Powershell session with a user that has administrative 'Partner' permissions in your partner tenancy.
Hopefully that helps somewhat!
Goal: Give users an account (domain user or basic, doesn't matter) and have them use Get-DhcpServerv4Lease cmdlet to convert their DHCP leases to reservations via the powershell web access feature using a web browser.
Issue/problem: I already made my own AuthorizationRule by importing that specific cmdlet but I feel like its missing others modules in order to authenticate/login? I can login if I grant microsoft.powershell configurationrule but cant if I grant the custom one that I made.
Error received upon login with my own custom configuration:
The Windows PowerShell Web Access gateway cannot establish a connection to the destination computer. Contact the gateway administrator. The error at the gateway is: The WS-Management service cannot process the request. The service is configured to reject remote connection requests for this plugin.
Question: Is there some other module I need to add to my custom rule or maybe there is a way to know what permissions microsoft.powershell contains so that I could mirror/copy them into my own rule?
Thanks
The quick answer: Remote Powershell needs to be enabled on the target system!
You can use System names, IP addresses or the FQDN. All of them will work (Use a mix as well)
To keep your Rules simple: Use Groups! Here is a Gist that could help you a bit. I have just a few rules and use AD Groups to manage the access (Systems and Users)
Please execute this (in an elevated PowerShell): Enable-PSRemoting -Force
You have to do this on all systems that you would like to access via the Web Gateway.
You will find a lot more Info about this on TechNet.
IT admin here, First Question on this site. Online I found a simple Powershell script that manually creates a System Restore Point on a user's PC. I want to deploy this to all company computers via a GPO scheduled task. Script as follows:
Checkpoint-Computer -Description 'System Restore Point' -RestorePointType modify_settings
Script work perfectly fine. Issue is that powershell needs to run as an admin. In scheduled task menu, the option to run with highest privileges only works if the user is a local admin. For security reasons at our company, it will not be possible to grant user's local admin access.
My question, is there some simple commands I can add that will elevate powershell to have admin privileges? Also, have to make sure that the user will not be prompted, and that the rest of the command will still execute. I do not mind having to store username or admin passwords in the script itself as the users will not see the script. I appreciate any suggestions, but only if it is fairly simply to execute. Keep in mind, I am not a programmer, I am a Cisco network engineer as well as a Windows Server admin. My boss just wants me to create manual restore points on a set schedule and I think powershell might be the best. Open to other script types though.
There are 2 parts to your question. The first part is about how to run a scheduled task as a specific user with elevated rights. I don't think it's correct that it's only possible to do so with a local admin account, but that's off-topic for this site. Consider posting that separately on ServerFault (if you do and link it, I will take a look).
The second part concerns embedding credentials into the script.
This is typically a bad idea. Saying that the user "won't" see it is not the same as saying they can't see it. If they can see it, the credential is compromised and essentially that user now can trivially have elevated rights.
So you would need to secure the script file well enough so that the unprivileged user cannot read the file.
Encrypted Credentials
PowerShell also has a [PSCredential] object which stores the password as a secure string. It is possible to store and retrieve an encrypted version of this object.
For example:
$cred = Get-Credential
$cred | Export-CliXml -Path C:\my\cred.xml
The XML file will contain the credential but it will be encrypted. It can only be decrypted by the same user on the same machine that encrypted it to begin with.
This could be a way for you to use a credential if needed. But to be honest it probably isn't.
How I would do this
Run your scheduled task as SYSTEM.
It should be privileged enough to take a restore point
It's local
It's easy to set a scheduled task to run as SYSTEM even through GPO
It requires no password handling
I'm building a PowerShell script that requires local administrator rights on the server it's run on and I would need to check that the user has those rights.
The problem is that the user might not be directly in the local Administrators group, but in a domain group that's in the local group and has the permissions that way. Then again the local Administrators group might have several domain groups as members.
Is there a way to "simply" check whether the user has local admin rights or not without going through Get-ADGroupMember for all the nested domain groups in Administrators or so?
edit: For example, one option could be a simple command that returns "Access denied" if the user is not local admin, but such a command that would be "safe" to execute just for this purpose.
I found this approach, which is quite lovely, on Garrett Serack's Git repository.
If ( ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{"You're a wizard Harry!"
#DoAdminThingsHere
}
ELSE{"Not an Admin!"}
Seems to get the job done. It determines the current permission level of the user using .net types.