Scenarios are plenty when O365 admins are requested to convert a user mailbox to a shared mailbox.
Here is one that comes up often,
User/Employee leaves the organization and others in the team need access to the user’s mailbox to keep track of the project they were working on
When we convert a user mailbox to a shared mailbox, the mailbox must have a license assigned and after the conversion is complete, we can remove the license.
One little caveat to the licensing part is, without license assigned to the shared mailbox, its size is limited to 50GB. So, before converting, make sure to check the mailbox’s size and to increase the shared mailbox’s size to 100GB, assign a Exchange Online Plan 2 license.
Note: If you are on Exchange hybrid environment, you’ll have to manage your mailboxes using on-premises Exchange management tools.
To convert a user mailbox to Shared mailbox using PowerShell
Before proceeding further make sure you are connected to Exchange Online,
We can enable users to sign in to AppStream 2.0 by using their existing Azure AD credentials, and start streaming applications. To accomplish this, we use an IAM role and a relay state URL to configure Azure AD and enable AWS to permit users to access an AppStream 2.0 stack. The IAM role grants users the permissions to access the stack. The relay state is the stack portal to which users are forwarded after successful authentication by AWS.
In this post, I’ll go over steps on how to configure federated user access for Amazon AppStream 2.0 using Azure AD SSO for Enterprise Apps.
The below diagram illustrates the authentication flow between AppStream 2.0 and Azure AD as identity provider (IdP).
Authentication Workflow
From a user’s perspective, this above process happens seamlessly. The user starts at myapps.microsoft.com and is automatically redirected to an AppStream 2.0 application portal without being required to enter AWS credentials.
The setup process goes like in this diagram below,
Select Integrate any other application you don’t find in the gallery (Non-gallery) and click Create
Create your own application
Once the application is added, from the left navigation menu, Click on Single sign-on, and choose SAML
SSO method – SAML
Click Edit in the Basic SAML Configuration
Basic SAML Configuration
Provide the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL), then click Save
Identifier (Entity ID) = URN:AMAZON:WEBSERVICES
Reply URL (Assertion Consumer Service URL) = https://signin.aws.amazon.com/saml
Sign on URL (Optional) = <leave it blank>
Relay State (Optional) = <leave it blank>, We will revisit this later in this post
The entity ID is passed during the SAML exchange
Azure AD requires this value to be unique for each application
When we add more AppStream 2.0 stacks, we can append a number to the string; for example, URN:AMAZON:WEBSERVICES1,URN:AMAZON:WEBSERVICES2
Basic SAML Configuration – Continued
In the SAML Signing Certificate section, click Download next to the Federation Metadata XML and save the .xml file to your computer
Download Federation Metadata XML
Create the SAML identity provider
Now, we need to create the SAML provider in AWS IAM console.
In AWS console, search and open IAM
In the left navigation window, click Identity providers, and the Add provider
AWS IAM – Add provider
On the Configure Provider page, for the Provider Type, select SAML
For Provider name, I’ve named it AzureAD-SSO
Click Choose File to upload the metadata document that previously downloaded from Azure AD, and click Add provider
Configure identity provider
Click on the identity provider we just created
Identity provider added
Copy the value for the Provider ARN
The ARN is in the following format: arn:aws:iam::AccountID:saml-provider/Provider Name
Copy Identity provider ARN
Configure an IAM policy
We need to create a policy with permissions to the AppStream 2.0 stack. This way we can ensure that users have only the permission to stream applications from a specific stack.
In the IAM console, choose Policies, click Create Policy
In Create policy page, choose the JSON tab
Copy and paste the following JSON policy into the JSON window
Modify the resource by entering your AWS Region Code, account ID, and stack name
Unique User Identifier (Name ID) = Key used to identify users in the SAML assertion
I generally stick with user.userprincipalname
Usually user.mail or user.userprincipalname works
Click + Add new claim and add the below claims
By default, Azure AD populates several SAML attributes for all new applications
These attributes are not needed for the federation to AppStream 2.0
We can remove them by choosing the three dots next to each, and choosing Delete
If you decide to leave them as is, it doesn’t do any harm
Name = Role Namespace = https://aws.amazon.com/SAML/Attributes Source = Attribute Source Attribute = This is the Role ARN from earlier in this post, followed by a comma and then the Provider ARN
Role attribute
Name = RoleSessionName Namespace = https://aws.amazon.com/SAML/Attributes Source = Attribute Source Attribute = We can provide any string value. I’m going with user.mail
RoleSessionName attribute
Name = SAML_SUBJECT Namespace = https://aws.amazon.com/SAML/Attributes Source = Attribute Source Attribute = We can provide any string value. I’m going with user.displayname
SAML_SUBJECT attribute
If the user intend to use the AppStream 2.0 client, sessions will default to a 60 minute timeout. This setting will determine the duration.
Name = SessionDuration Namespace = https://aws.amazon.com/SAML/Attributes Source = Attribute Source Attribute = Value in seconds between 900 (15 minutes) and 43200 (12 Hours). I’m going with 28800 (8 Hours)
SessionDuration attribute
Assign Azure AD groups in Application
In the left navigation menu, click Users and groups, click + Add user/group
In Add Assignment, click Users and groups
In the Users and groups dialog box, select the Azure AD group to provide access the AppStream 2.0 stack
Click Assign
Assign Group
Also click on the Properties tab in the left navigation menu to check the following,
Enabled for users to sign-in? = Yes
Assignment required? = Yes
Visible to users? = Yes
I also uploaded an icon file for the app to look nicer.😉
Test Application
With a Azure AD security group assigned to the application and the other setting configured, we’re ready to test this with a user account. I’ve already added the user account to the assigned Azure AD group. To test this,
I also created a second fleet and stack, associated the fleet to the stack to demonstrate how we can assign different users to stacks. IMO, the myapps portal is a really cool feature and we can it to present AppStream to our users.
As I mentioned earlier in this post, adding more stack will require adding additional Azure AD applications and assigning AD group(s) to it.
All Stacks
All Fleets
This below is a different user logging into the myapps portal (https://myapps.microsoft.com/) with their Azure AD credentials and I’ve assigned the ‘DeveloperUsers-Stack-0323’ stack to them.
User’s myapps portal view
The user gets redirected to the AppStream 2.0 portal
User redirected to AppStream 2.0 app catalog
Issues you may encounter and How to fix it
Error: RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
Fix: I encountered this error with the second stack I had created. When is saw this error, my obvious first step is to make sure I didn’t miss the RoleSessionName attribute in the Azure AD app I created. And it was there with the expected value.
I then decided to go back over the AWS IAM role and policy I created and realized that in the I had picked the wrong identity provider and once I picked the correct one, this issue was resolved.
RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
Error: Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401
Fix: This error message occurs when the IAM policy does not permit access to the AppStream 2.0 stack or when the stack name is not entered into the policy. Similar mess up on my part.
I had mistyped the stack’s name while creating/typing in the JSON window during the policy creation step.
Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401
In my experience, the SAML-tracer for Chrome and Firefox comes in handy to help identify SAML related issues. It has certainly helped me in several instances.
Hope this post helped you to setup Azure AD SSO for your AppStream 2.0 stacks.
AWS root account has access to the billing information by default and the root user can allow IAM users to access the billing information. In this post I will go through the steps on how to allow IAM users to be able to access billing information.
Below are the steps on the workflow to enable access,
When an IAM user tries to access the Billing Dashboard, this below error is displayed.
Activate access to billing data
Sign in to the AWS Management Console using root account credentials
On the top right of the window, choose account name, and then click Account
In the IAM User and Role Access to Billing Information section, click Edit
Select the Activate IAM Access check box to activate access to the Billing and Cost Management console pages
Click Update
With these above steps, we have activated IAM user access.
Create IAM policies to grant permissions to billing data
In the left navigation menu, choose Policies and click Create Policy
In the Visual editor tab, click Choose a service to get started, Select Billing
In this step, I’ll show steps to create two different policies,
Full Access Policy
In Actions, Under Specify the actions allowed in Billing select the check box next to All Billing actions (aws-portal:*)
No need to select a resource or condition for this policy
Click Next:Tags to add necessary tags, click Review policy
On the Review page, provide name as BillingFullAccess, and then click Create policy
Read-only access Policy
In Actions, Under Specify the actions allowed in Billing select the check box next to Read
No need to select a resource or condition for this policy
Click Next:Tags to add necessary tags, click Review policy
On the Review page, provide name as BillingViewAccess, and then click Create policy
Create groups and attach billing policies
It is possible to attach policies directly to users or roles but it is best practice to attach polices to groups. I will create two groups and attach the policies created in the previous step.
In the left navigation menu, choose User groups and click Create group
In this step, I’ll create the two groups and attach the policy,
BillingFullAccessGroup
In the User group name, provide name as BillingFullAccessGroup
Under Attach permissions policies, select BillingFullAccess policy which we created in earlier step
Click Create group
BillingViewAccessGroup
In the User group name, provide name as BillingViewAccessGroup
Under Attach permissions policies, select BillingViewAccess policy which we created in earlier step
Click Create group
If you already have IAM users created, you can add them while creating the groups as you can see in the user group creation window. I didn’t have any users yet and I chose not to add any but that’s fairly easy step.
Test access
It is recommended to test the billing access with some test users to make sure the access works as intended.
IAM users can login to the AWS console, On the top right of the window, choose account name, and then click My Billing Dashboard to view the billing information.
Hope this post helped you set up billing access for your users.
Public folders are meant for shared access and to enable an easy way to collect and share information with other users in an organization. Public folders makes it easier to browse content and users will see the full hierarchy in Outlook using which they can find the content they are looking for.
Public folders can also be used to archive email sent to distribution groups. When a public folder is mail-enabled, and added as a member of the distribution group, email sent to this group is automatically added to the public folder to be referenced later.
Public folders use mailbox infrastructure for high availability and mailbox database storage technologies. This architecture uses specially designed mailboxes to store both public folder hierarchy and the content.
The main component of public folders are the public folder mailboxes. Before creating public folders, we must first create public folder mailboxes. There are two types of public folder mailboxes,
Primary hierarchy mailbox: This is the one writable copy of the public folder hierarch and is copied to all other public folder mailboxes. The first public folder mailbox created will be the primary hierarchy mailbox in the organization
Secondary hierarchy mailbox: Additional public folder mailboxes created are secondary hierarchy mailboxes and can also contain content. Is a read-only copy of the public folder hierarchy
Before proceeding further make sure you are connected to Exchange Online,
To create first mailbox that will be the Primary hierarchy mailbox:
$Name = Read-Host "Enter a name for the Public Folder"
New-Mailbox -PublicFolder -Name $Name
To create additional public folder mailboxes that will be Secondary hierarchy mailboxes:
$Name = Read-Host "Enter a name for the Public Folder"
New-Mailbox -PublicFolder -Name $Name
To create public folders
To create a new public folder:
$Name = Read-Host "Enter a name for the Public Folder"
New-PublicFolder -Name $Name
To create a public folder under and existing folder:
$Name = Read-Host "Enter a name for the Public Folder"
$Path = Read-Host "Enter a existing folder name"
New-PublicFolder -Name $Name -Path $Path
example shows ‘Reports’ folder created under Sales
example shows ‘Monthly’ folder under ‘Reports’ folder created under Sales
To mail enable a public folder:
$Name = Read-Host "Enter Public Folder which you wish to mail enable"
Enable-MailPublicFolder $Name
To add permissions to a specific user on a public folder:
$Name = Read-Host "Enter name of public folder that you wish to add permissions"
$user = Read-Host "Enter email address of user"
$AccessRights = Read-Host "Enter permissions separated by comma"
$AccessRights = $AccessRights -split ' *, *'
Add-PublicFolderClientPermission -Identity $Name -User $user -AccessRights $AccessRights
To determine permissions on a specific folder:
$Name = Read-Host "Enter a name for the Public Folder to query permissions"
Get-PublicFolder -Identity $Name | Get-PublicFolderClientPermission | Select Identity, User, AccessRights
Who are the licensed users in our tenant and what licenses are assigned to them? This question comes up way too often in several scenarios and there are a few methods to determine this. I will go over those in this post. I’ve updated this post with some newer information about exporting from the admin portal when I learned them.
Using PowerShell
There are two versions of the PowerShell module that you can use to connect to Microsoft 365 and administer user accounts, groups, and licenses:
Microsoft Azure AD Module for Windows PowerShell, whose cmdlets include Msol in their name
Azure AD PowerShell for Graph, whose cmdlets include AzureAD in their name
Please make sure you have the MSOnline Module for PowerShell installed and loaded
The Get-MsolUser is a powerful cmdlet which provides a lot of details and I’m going to use it for determining the user’s license.
