"Azure Files" is a managed, cloud-based file share that can access via SMB protocol. Once you create Azure File share it can be accessed from any ware using Windows, Linux or macOS. It can also map as a shared drive to a system. This can be used as a unified, reliable, simple solution to replace traditional file servers. 

In the on-premises Active Directory environment, we use NTFS permissions to control access to folders and file shares. If we are replacing traditional file shares with Azure Files, we need a way to manage access permissions to it in a similar manner. This is applicable if these folders are accessed via "Windows Virtual Desktop" or "Domain-Joined Azure VM". Azure File now supports Azure Active Directory Domain Services (Azure AD DS) authentication. Now we can create NTFS access control lists (ACLs) for Azure File Shares to control access permissions in a granular level. In this demo, we are going to look into this new feature in detail. 

To test this, we need following,

• Valid Azure AD Subscription
  
• Azure AD Domain Services on the Azure AD tenant – We need Azure AD Domain Services enabled for the Azure AD tenant. 
• Domain-Joined Azure VM – This need to be added to the Azure AD Domain Services

In my demo setup, I already have a managed domain called rebeladmlive.onmicrosoft.com

I also have a domain-joined VM called SRV01 which I will be using for the testing. 

Finally, the long wait is over and Microsoft virtual desktop infrastructure (VDI) solution "Windows Virtual Desktop" preview is now available in Azure. If you ever worked with on-premises VDI solutions such as Microsoft RDS or Citrix solution, you may already know how much planning, management involve with it. It is costly as performance & availability of the solution depends on so many things such as networking, hardware resources, skills, connection, etc. But now with a cloud-based solution, we can create a robust, scalable VDI solution with few clicks. 

According to Microsoft we can do following with Windows Virtual Desktop,

• Set up a multi-session Windows 10 deployment that delivers a full Windows 10 with scalability
  
• Virtualize Office 365 ProPlus and optimize it to run in multi-user virtual scenarios
  
• Provide Windows 7 virtual desktops with free Extended Security Updates
  
• Bring your existing Remote Desktop Services (RDS) and Windows Server desktops and apps to any computer
  
• Virtualize both desktops and apps
  
• Manage Windows 10, Windows Server, and Windows 7 desktops and apps with a unified management experience
  

Source: https://docs.microsoft.com/en-gb/azure/virtual-desktop/overview 

Windows Virtual Desktop's Key capabilities are recognized as following,

• Create a full desktop virtualization environment in your Azure subscription without having to run any additional gateway servers.
  
• Publish as many host pools as you need to accommodate your diverse workloads.
  
• Bring your own image for production workloads or tests from the Azure Gallery.
  
• Reduce costs with pooled, multi-session resources. With the new Windows 10 Enterprise multi-session capability exclusive to Windows Virtual Desktop and Remote Desktop Session Host (RDSH) role on Windows Server, you can greatly reduce the number of virtual machines and operating system (OS) overhead while still providing the same resources to your users.
  
• Provide individual ownership through personal (persistent) desktops.
  

Source: https://docs.microsoft.com/en-gb/azure/virtual-desktop/overview 

Windows Virtual Desktop preview setup required following,

1. Azure Active Directory – Windows Desktop Machines must join to the Azure AD in the stranded method. It can't be Azure AD-Join
2. Virtual Desktop only should be Windows 10 Enterprise multi-session or Windows Server 2016/2019
3. OS should have one of the following licenses – Microsoft E3, E5, A3, A5, Business Windows E3, E5, A3, A5 
4. VM should be using subnet which has a connection to the same virtual network as Azure AD. 
5. Azure AD & VM should be in the same region. 

As same as any other VDI solution, user experience has a huge impact from "connectivity". Therefore Microsoft says,

• Round-trip (RTT) latency from the client's network to the Azure region where host pools have been deployed should be less than 150 ms.
• Network traffic may flow outside country borders when VMs that host desktops and apps connect to the management service.
• To optimize network performance, we recommend that the session host's VMs are collocated in the same Azure region as the management service.

There are few new terms related to the Windows Virtual Desktop setup, let's see what are they.

In this blog post, I am going to demonstrate how to set up a desktop application group. before start let's see how is the environment looks like.  

In my demo setup, I have Azure AD Domain Service enabled for tenant rebeladmlive.onmicrosoft.com

This is set up under resource group called AAD and it is using subnet called AAD-vnet 

I also set up a subnet called AAD-VM for session hosts. 

Corporate applications may also hold critical operation data related to the company. By doing regular reviews, we can make sure only the relevant people have access to corporate applications. However, if we just use the native method, it will be mainly based on Enterprise app Sign-ins and audit log data. the only problem with this method is, it is so time-consuming. As it is all manual process, the result may not be that accurate either. But now with Azure AD Access reviews, we can do this by setting up a simple access review job. Here is why it is good rather than a typical audit. 

Automated – It is all automated. You do not need to go through logs and do anything manually. 

Actions – we can also attach predefined action to execute at the end of a successful access review job. If required, we also can manually decide what to do with the findings (approve or deny access)

Schedule – Access reviews jobs can be scheduled to run periodically. It helps to do it more frequently than the manual method.

Recommendation – Access review job itself provides recommendations based on findings. It helps reviewers to decide. 

Delegations – Access reviews job allows delegation. We can assign someone else in the team to decide what to do with the findings. It helps to get more accurate results. 

So, let's go ahead and see how it works. In my demo environment, I have linkedin application assigned to different groups and users. I like to know who has access to it and do permission changes if required.

 1. To start, log in to Azure portal as Global Administrator

2. Then make sure Access reviews onboarding process is completed. More info about this can be found in one of my previous blog posts http://www.rebeladmin.com/2019/02/step-step-guide-review-privileged-accounts-using-azure-pim/

3. To create a new access review job, go to Access Reviews | Controls

4. Then click on + New Access Review 

In on-premises Active Directory environments, we use “trusts” to establish identity infrastructure collaboration between businesses. In that way, partner organization can use their own user accounts to authenticate in to trusted organization resources. When it comes to cloud/hybrid identity, Azure AD B2B allow organizations to establish cross-organization identity connections. Unlike on-premises, it is not required additional infrastructure changes. In my previous article about Azure B2B explains how we can allow external users to authenticate in to cloud app using their own accounts. You can find it here http://www.rebeladmin.com/2018/11/cross-organization-collaboration-azure-ad-b2b/ . However, when external user’s sign up process it is asking to create “Microsoft Account” to continue. 

If users are having Google Accounts, now Azure AD B2B can initiate federation with google to allow users to use their own google accounts to authenticate instead of Microsoft Accounts. In this demo I am going to demonstrate how we can initiate federation with google. 

Prerequisites

• Valid Azure AD B2B Subscription – If the guest users are going to use Azure AD paid services, make sure you have enough licenses allocated. More info about licensing can find here https://docs.microsoft.com/en-us/azure/active-directory/b2b/licensing-guidance

• Shared Google Account – During the setup we need to create credentials at Google APIs. To do that we need to use existing google account. It is recommended to use separate google account for this instead of existing user account. 

To start the configuration,

1. Go to https://console.developers.google.com and log in with the Google account you have selected for the task. 

2. In Dashboard, Click on Create to start new project. 

3. Then in new window, give unique name to project and click on Create.

4. Once project is created, select it from the project drop down box. 

5. Then click on Credentials. 

In my previous blog posts about conditional access polices I talked about location based and application based polices. In this new blog post I am going to cover risk-based conditional access policies. You can access previous blog posts about conditional access policy using following links,

Step-by-Step Guide to configure location-based Azure conditional access policies – http://www.rebeladmin.com/2018/08/step-step-guide-configure-location-based-conditional-access-policies/

Step-by-Step guide to enable MFA for applications using Azure conditional access – http://www.rebeladmin.com/2018/09/step-step-guide-enable-mfa-applications-using-azure-conditional-access/

Azure AD Identity protection can detect six types of suspicious sign-in activities. 

• Users with leaked credentials

• Sign-ins from anonymous IP addresses

• Impossible travel to atypical locations

• Sign-ins from infected devices

• Sign-ins from IP addresses with suspicious activity

• Sign-ins from unfamiliar locations 

These six-types of events are categorized in to 3 levels of risks – High, Medium & Low. 

We can use these risk levels with conditional access policies to protect sensitive application access. In this demo I am going to demonstrate how to create risk-based conditional access policies. 

My finance team accessing Microsoft teams’ app remotely. I like to create policy to block access to app if their sign in risk level is detected as High & Medium. 

To set up the policies,

1. Log in to https://portal.azure.com

2. Click on Azure Active Directory

3. Click on Conditional access

4. In new window, click on New policy to create policy.

5. In policy window, type name for policy & then click on Users & groups. after I select sg-Finance group.

6. Then click on Cloud apps & select Microsoft teams.

7. As next step, click on Conditions | Sign-in risk, then under Configure click on Yes. That will enable sign-in risk policy. We also need to select High & Medium risk levels. 

8. Under access control section select Grant, then click on block access. 

9. At last, click On under enable policy. then click on Create to complete the process. 

10. Now policy is in place. For testing I am going to use what if feature under conditional access policies. This feature in azure allows to create scenario and see if the policy going to apply as expected. This is the best way to test this type of policies as it is not always practical to create real scenario for testing. 

11. To do that, go to Azure Active Directory | Conditional access and then click on what if

12. In new window, I have selected a demo user from finance team, also selected the Microsoft teams as cloud app. Under IP address I just define dummy ip and select the country Afghanistan. For sing-in risk, I choose medium level. once data is in, we need to click on what if button to complete the test. 

13. Once job is executed, result section shows that new policy we just created is applying successfully. This confirms the policy in place is going to work as expected in real world. 

This marks the end of this blog post. Hope now you have better understanding how to configure risk-based azure conditional access policies. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Azure active directory conditional access policies allow to control user access to resources, based on the environment he/she login from. This is really important in modern day zero trust infrastructures. we no longer can depend on traditional firewall rules to control access as threats are more sophisticated. Conditional access policies allow to verify user access based on different conditions such as location, device type, risks, applications etc. 

In this demo, we are going to learn how to setup location-based conditional access policies.

In my demo setup I have Microsoft Flow app used by sales & marketing department. We are going limit its access based on locations they are login from. 

1. First, I have logged in to azure portal as global administrator. 

2. Then navigate to Azure Active Directory 

3. Then click on Conditional Access

4. In new panel, click on Named locations

5. Then click on Configure MFA trusted IPs.

6. In new window, I have typed 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 as trusted ip addresses. After define ip addresses click on Save. 

7. Then close all the additional windows and go back to Azure AD home page. Then click on Enterprise applications. 

8. From the list search for Microsoft Flow app and click on it. 

9. Then click on Conditional Access 

10. In new window, click on New Policy

11. In new wizard, type name for the policy first. Then under users & groups, I have select sales & marketing group. 

12. Then go to Conditions | Locations and click on Yes under configure tab.

13. Under Include tab select Any location

14. Under exclude tab, select All trusted locations

15. Then keep clicking Done to apply the configuration. 

16. Then click on Grant under access controls and then click on Block access. 

17. At last, click on On under enable policy and then click on Create to complete the policy wizard. 

18. Now we have the policy in place. According to policy it will only allow the access from the trusted location. 

19. To test it, I logged in to https://myapps.microsoft.com using user account belongs to sales & marketing group. 

20. Then I click on Flow app, as expected my access was blocked as I am login from a IP not belong to trusted range.

21. Then I go back to Named locations page and add my current ip 77.97.127.39 in to trusted list. 

22. After that, as expected I can access the flow portal.

This marks the end of this blog post. Hope now you have better understanding how to create location based conditional access policy. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

I am sure every engineer knows how “Local Administrators” works in a device. If it’s a device in on-premise Active Directory environment, either domain admin or enterprise will need to add it to Administrators group. if it’s a workgroup environment, another user with local administrator privileges will need to add additional users to Administrators group. 

If it is Azure AD join device, Azure Global Administrators and Device Owner have local administrator rights by default. 

Azure AD allow to define local administrators in device level. however, this is a global setting. If it is need to handle in device level, still you need to login from an account which already have local administrator rights and then add additional users. 

Let’s see how we can do this. 

1) Log in to azure portal as Global Administrator. 

2) Then click on Azure Active Directory and the Devices. 

3) Then click on Device Settings

4) By default, Additional local administrators on Azure AD joined devices setting is set to None. click on tab Selected to enable it. 

5) In my demo, I am going to make user RA886611@therebeladmin.com local administrator for devices. To do that click on Selected option. 

6) In new window click on Add members to add users. 

7) From the list find the relevant user and click on it to select. Then click on Select

8) Then click on OK

9) Finally click on Save to apply the settings. 

10) To Test this, I logged in to a Azure Domain Joined Device as RA886611@therebeladmin.com 

11) Now to test it, I trying to launch PowerShell console as Administrator. If it works, I shouldn’t get login prompt. 

12) As expected it didn’t ask for admin user name and password as logged in user now have local admin privileges. 

13) Also, when needed, using Remove Members option in Local administrators on devices page, we can remove the users from local administrator group. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

If you work with Active Directory you may already know what is roaming profiles is. Roaming profiles allows to sync application and user settings to a file share. When same user login from another computer in to same domain, those settings will sync back from file share. It allows users to have same user experience and data in different corporate devices. Azure Active Directory users may also login from multiple Azure domain joined devices. Enterprise state roaming allows to sync user settings and application settings securely across corporate azure domain joined devices. 

Secured Sync – When this feature enables it will activate free limited Azure Rights Management subscription. It will use to encrypt and decrypt data which is sync to cloud. This will ensure the security of data used by Enterprise State Roaming feature. 

Data Storage – Data storage location for Enterprise State Roaming feature will be align with your Azure Active Directory subscription region. It will not sync between different regions. 

Better Control – This feature can be enable for entire directory or only for selected users. Sync data for each device can review using portal. With help of Azure Support, administrators also can forcefully remove sync data for a device. 

Data Retention – If user account been deleted from directory, profile data will be deleted after 90 days. Administrators also can request (from azure support) to delete specific data from a user profile. If data not been access for 1 year it will consider it as stale data and remove forcefully. It will also happen if Enterprise State Roaming feature is disable in later time. 

Let’s see how we can enable this feature. In order to enable this feature, you must have Azure AD Premium or Enterprise Mobility + Security (EMS) license. Azure AD join devices must be running with Windows 10 (Version 1511, Build 10586 or greater)

1) Log in to Azure Portal as a Global Administrator

2) Go to Azure Active Directory | Devices  

 

 

3) Then click on Device Settings 

 

 

4) Under device settings there is option says Users may sync settings and app data across devices. In there you can select All or Selected. If you use selected option, you will need to define the users. in my demo, I am going to enable Enterprise State Roaming for entire directory. Once selection is made click on Save. 

 

After the feature is enabled we can review the sync status using Azure Active Directory Admin Center. To do this, 

 

1) Log in to Azure Active Directory Admin Center using https://aad.portal.azure.com

2) Go to Azure Active Directory | Users and Groups 

 

 

3) In next window, Click on All users and then click on the relevant user. In my demo it is user RA722725@therebeladmin.com

 

 

4) Then click on Device in new window. 

 

 

5) Then in right hand window select Device sync settings and app data option from show drop down menu.

 

 

6) In list it shows the devices, that user logged in and the last sync time. 

 

 

Now we have everything ready for testing. Before we start there is few things to remind. This is only sync user and app settings. Not user data. Also, sync is not happening at login/log off event. It happens once user is log in. so if you do not see sync data right away after login, allow sometime and keep eye on last sync time value. 

 

In my demo, I am login to a pc called REBEL-PC01 as RA722725@therebeladmin.com. In that pc, I have done certain settings changes. 

 

Under IE, I added few links to favorites. 

 

 

I also change setting on code writer App and change font and default text size to 20.  

 

 

After initial sync, I login in to another pc called REBEL-PC02 as RA722725@therebeladmin.com. In there I expect to see the changes I made. (The sync cycles can take up to 30 minutes. So far I didn’t find way to override this setting) 

 

As expected I can see same IE favorites list. 

 

 

Also, code writer app settings are there. 

 

 

As we can see it helps to streamline user experience across corporate devices. This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

In this series of articles, it which will explain how to use PowerShell to manage your Azure Active Directory instance. In Part 01, I am going to show how to connect with Azure AD using PowerShell and show actions of some day to day operation related commands.

In order to use PowerShell with Azure AD, first we need to install Azure Active Directory Module in local computer. there is two version of Azure active directory PowerShell module. One was made for the Public Preview and the latest one released after announces Azure AD GA. You can download module from http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

If you had the previous version installed, highly recommended to replace it with the new version.

Once installed let’s check its status.

Get-Module MSOnline

In order to list down all the commands associate cmdlets with the module we can use

Get-Command -Module MSOnline

Next step is to connect to Azure AD Instance. In order to do that we can use,

Connect-MsolService

It will prompt for the login details. Please use your Azure DC Admin account details. Please note login via Microsoft account not supported.

First, we can list down all the domain under the given subscription. To do that we can use,

Get-MsolDomain

As next steps I like to list down all the users in Azure AD Setup.

Get-MsolUser

It will list down all the Users in the Azure AD.

I also can search for a specific user based on text patterns. In below example I am searching users with Name which match text “Dishan”

Get-MsolUser -SearchString "Dishan"

Idea of my search is to find some object values for this user. I can combine above command to return all the object value.

Get-MsolUser -SearchString "Dishan" | Select-Object *

Now we know what are the objects been use and I can make more unique search.

Get-MsolUser | Select-Object DisplayName,whenCreated,LastPasswordChangeTimestamp

Above command will list me all the users with Display Name, Date and Time It was created, and Date and Time of Last Password Change Action.

Get-MsolUserRole another handy cmdlet. It can use to check the role of a user account.

Get-MsolUserRole -UserPrincipalName "dcadmin@REBELADMIN.onmicrosoft.com" | fl

The above command will find the role for the given user account.

Get-MsolGroup cmdlet can use to list, filter Groups in the Azure AD.

Using searchstring can search for the groups based on text patterns.

Get-MsolGroup -SearchString "AAD"

Get-MsolGroupMember can use to list down the members in the group.

Get-MsolGroupMember -GroupObjectId "77a76005-02df-48d5-af63-91a19ed55a82"

Remove-MsolUser cmdlet can use to remove the user object from the Azure AD. This can combine with searchstring to search for user and then remove the object same time.

Get-MsolUser -SearchString "user2" | Remove-MsolUser

Above command will search for the user object which have display name similar to user2 and then delete it.

In next post let’s dig further in to cmdlets which can use to manage Azure AD.

If there is any question, please feel free to contact me on rebeladm@live.com

In my previous post on this series I have explain about azure AD privileged identity management including its features and how to get it enabled. If you not read it yet you can find it using this link.

in this post I am going to show you more of its features and capabilities. 

How to manage privileged roles?

The main point of the identity management is that administrators will have the required privileges when they needed. In part 1 of the post billing administrators and service administrator roles were eligible for the Identity management. So it will remove its permanent permissions which is assigned to role. 

So if you still need to make one of the account permanent administrator let’s see how we can do it. 

Log in to the azure portal as global administrator (it should be associated with relevant AD instance)

Open the azure identity management from portal

Then click on managed privileged roles

In next page it will list down the summary of the roles. Let’s assume we need to make one of the billing administrators “permanent”. To do that click on billing administrators

It will list down the users which is eligible for the role and click on the account you need to make permanent. 

Then click on more in next page and click on option make perm

Once completed its shows as permanent

Same way we can add an administrator to the roles. To do it go to roles, if you need to add new role it can do too. Click on roles on the manage privileges roles page

Then click on add

Then from roles click on the role you going to add

Then under the select users, select the user using search and click on done

How to activate roles?

Now we have the roles but how we can use them with time bound activation (Just in time administration) 

Go to the role page again like in previous page. In my demo I am going to use service administrator role

Then click on settings

In next window we can see that option to define the time. Also we can enable notifications so email notification will send to admin in event of role activation. Also option to request ticket or incident number. This is important to justify the privileged access. Also can use the multifactor authentication in activation to make sure the request is legitimate. 

Once you satisfied with settings, click on save to apply. 

Then for the testing I logged in as the security administrator to the azure portal. 

Then go to the privileged identity management page. 

Click on the service administrator 

Then click on the activate button, to activate the role

According to the settings its asking for ticket number for activation. Once put the information click on ok

Perfect, now its saying when it expires and it also shows the that roles been activated

Now I change the login and logged back as global administrator.

Then if go to privileged management page and click on audit history you can see all the events. 

Hope this series add knowledge about azure AD privileged identity management and if you have any questions feel free to contact me on rebeladm@live.com