Tag Archives: Azure Active Directory Domain Service

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

I am sure most of you aware what is single sign-on (SSO) in Active Directory infrastructure and how it works. When we extend identity infrastructures to Azure by using Azure AD, it also allows to extend Single Sign-On capabilities to authenticate in to cloud workloads. it can be done using on-premises ADFS farm. Password Hash Synchronization or Pass-through Authentication allow users to use same user name and password to log in to cloud applications but this is not a “Seamless” access. Even they are using same user name and password, when log in to Azure workloads it will prompt for password. 

In my below example, I have an Azure AD instance integrated with on-premises AD using Pass-through Authentication. In there I have a user R272845. I logged in to a domain joined computer with this user and try to access application published using Azure. when I type the URL and press enter, it redirects me to Azure AD login page.

sso1

sso2

Azure Active Directory Seamless Single Sign-On is a feature which allow users to authenticate in to Azure AD without providing password again when login from domain join/ corporate device. This can be integrated with Password Hash Synchronization or Pass-through Authentication. This is still on preview which means cannot use in production environment yet. However, if it doesn’t work in environment, it will always issue the typical Azure AD authentication page, so it will not prevent you from accessing any application. This feature is not supported if you using ADFS option already.

According to Microsoft, following can list as key features of Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

Users are automatically signed into both on-premises and cloud-based applications.

Users don't have to enter their passwords repeatedly.

No additional components needed on-premises to make this work.

Works with any method of cloud authentication – Password Hash Synchronization or Pass-through Authentication.

Can be rolled out to some or all your users using Group Policy.

Register non-Windows 10 devices with Azure AD without the need for any AD FS infrastructure. This capability needs you to use version 2.1 or later of the workplace-join client.

Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior – i.e, the user needs to enter their password on the sign-in page.

It can be enabled via Azure AD Connect.

It is a free feature, and you don't need any paid editions of Azure AD to use it.

It is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication

According to Microsoft, following environments are supported. 

OS\Browser

Internet Explorer

Edge

Google Chrome

Mozilla Firefox

Safari

Windows 10

Yes

No

Yes

Yes, additional config required

N/A

Windows 8.1

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 8

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 7

Yes

N/A

Yes

Yes, additional config required

N/A

Mac OS X

N/A

N/A

Yes

Yes, additional config required

Yes, additional config required

The current release (at the time this blog post was written) do not support edge browser. Also this feature will not work when users use private browser mode on Firefox or when users have Enhanced Protection mode enabled in IE. 

How it works?

Before we look in to configuration, let’s go ahead and see how it’s really works. In following example, user is trying to access cloud based application (integrated with azure) using his on-premises username, password and domain joined device. 

Also, it is important to know what happen in corporate infrastructure when seamless SSO enabled.

System will create AZUREADSSOACCT computer object in on-premises AD to represent Azure AD

AZUREADSSOACCT computer account’s Kerberos decryption key is shared with Azure AD.

Two Kerberos service principal names (SPNs) are created to represent two URLs that are used during Azure AD sign-in which is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net 

sso3

1. User is accessing the application URL using his browser. He is doing it using his domain joined device in corporate network.

2. If user is not sign in already, it is pointed to Azure AD sign in page and then user type his user name.

3. Azure AD challenge back user via browser using 401 response to provide Kerberos ticket.

4. Browser request a Kerberos ticket for AZUREADSSOACCT computer object from on-premises AD. This account will be created in on premise AD as part of the process in order to represent Azure AD. 

5. On-premises AD locate the AZUREADSSOACCT computer object and return the Kerberos ticket to the browser encrypted using computer object’s secret. 

6. The browser forwards Kerberos ticket to Azure AD.

7. Azure AD decrypts the Kerberos ticket using Kerberos decryption key (This was shared with azure AD when SSO feature enable)

8. After evaluation, Azure AD pass the response back to the user (if required additional steps such as MFA required).

9. User allowed to access the application. 

Prerequisites

In order to implement this feature, we need the following,

1. Domain Admin / Enterprise Admin account to install and configure Azure AD Connect in on-premises 

2. Global Administrator Account for Azure subscription – in order to create custom domain, configure AD connect etc.

3. Latest Azure AD Connect https://www.microsoft.com/en-us/download/details.aspx?id=47594 – if you have older Azure AD connect version installed, you need to upgrade it to latest before we configure this feature.

4. Azure AD Connect can communicate with *.msappproxy.net URLs and over port 443. If connection is control via IP addresses, the range of azure IP addresses can find in here https://www.microsoft.com/en-us/download/details.aspx?id=41653 

5. Add is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net to browser intranet zone. If users are using IE and chrome, this can be done using group policy. I have written blog post before how to create policy targeting IE. You can find it here

6. Firefox need above URL added to the trusted Kerberos site list to do Kerberos authentication. To do that go to Firefox browser > Type about:config in address bar > in list look for network.negotiate-auth.trusted-uris > right click and select modify > type “https://autologon.microsoftazuread-sso.com, https://aadg.windows.net.nsatc.net" and click ok

7. if its MAC os, device need to be joined to AD. More details can be found in here

Configure Azure AD Seamless SSO
 
Configuration of this feature is straight forward, basically it’s just putting a one tick box. 
 
If its fresh Azure AD connect installation, select the customize option under express settings.
 
sso4
 
Then in User Sign-in page select the appropriate sign-in option and then select Enable single sign-on option.
 
sso5
 
If you have existing Azure AD connect instance running, double click on Azure AD connect short cut. In initial window click on Configure.
 
sso6
 
In additional task page click on Change user sign-in and then click on Next.
 
sso7
 
In next window, type the Azure AD sync account user name and password and click on Next.
 
sso8
 
Then under the User Sign-in page select Enable single sign-on option and then click Next
 
sso9
 
In next page, enter the credentials for on-premises domain admin account and click Next.  
 
sso10
 
At the end click on Configure to complete the process. 
 
sso11
 
This completes the configuration and next step is to verify if its configured SSO. First thing is to check if its create computer object called AZUREADSSOACCT under on-premises AD. You will be able to find it under default Computers OU.
 
sso12
 
Then log in to Azure Portal and go to Azure Active Directory > Azure AD Connect then under the user sign-in option we can see seamless sign-on option is enabled. 
 
sso13
 
This means it’s all good. Next step is to check if its working as expected. in order to do that I am login to corporate device with same user I used earlier which is R272845 and try to access same app url. 
 
This time, all I needed to type was the user name and it log me in. nice!!!!
 
sso14
 
Note – before testing make sure you added the two Azure AD urls to intranet zone as I mentioned in prerequisites section. 
 
Hope this information was useful and if you have any questions feel free to contact me on rebeladm@live.com

Azure Active Directory Pass-through Authentication

When organizations want to use same user name and passwords to log in to on-premises and cloud workloads (azure), there are two options. One is to sync user name and password hashes from on-premises active directory to azure AD. Other option is to deploy ADFS farm on-premises and use it to authenticate cloud based logins. But it needs additional planning and resources. On-premises AD uses hash values (which are generated by a hash algorithm) as passwords. They are NOT saved as clear text, and it is almost impossible to revert it to the original password even someone have hash value. There is misunderstanding about this as some people still think Azure AD password sync uses clear text passwords. Every two minutes, the Azure AD connect server retrieves password hashes from the on-premises AD and syncs it with Azure AD on a per user-basis in chronological order. In technical point of view, I do not see a reason why people should avoid password hash sync to azure AD. However, there are company policies and compliance requirements which do not accept any form of identity sync to external system even on hash format. Azure Active Directory Pass-through Authentication is introduced by Microsoft to answer these requirements. It allows users to authenticate in to cloud workloads using same passwords they are using in on-premises without syncing their password hash values to Azure AD. This feature is currently on preview. Which means it’s still not supported on production environment. But it is not too early to try it in development environments.

According to Microsoft, following can list as key features of Pass-through Authentication.

Users use the same passwords to sign into both on-premises and cloud-based applications.

Users spend less time talking to the IT helpdesk resolving password-related issues.

Users can complete self-service password management tasks in the cloud.

No need for complex on-premises deployments or network configuration.

Needs just a lightweight agent to be installed on-premises.

No management overhead. The agent automatically receives improvements and bug fixes.

On-premises passwords are never stored in the cloud in any form.

The agent only makes outbound connections from within your network. Therefore, there is no requirement to install the agent in a perimeter network, also known as a DMZ.

Protects your user accounts by working seamlessly with Azure AD Conditional Access policies, including Multi-Factor Authentication (MFA), and by filtering out brute force password attacks.

Additional agents can be installed on multiple on-premises servers to provide high availability of sign-in requests.

Multi-forest environments are supported if there are forest trusts between your AD forests and if name suffix routing is correctly configured.

It is a free feature, and you don't need any paid editions of Azure AD to use it.

It can be enabled via Azure AD Connect.

It protects your on-premises accounts against brute force password attacks in the cloud.

How it works?

Let’s see how it really works. In following example, user is trying to access cloud based application (integrated with azure) using his on-premises username and the password. This organization is using pass-through authentication.

pt1

1. User is accessing the application URL using his browser. 

2. In order to authenticate to the application, user is directed to Azure Active Directory sign-in page. User then type the user name, password and click on sign-in button. 

3. Azure AD receives the data and it encrypt the password using public key which is used to verify the data authenticity. Then it places it’s in a queue where it will wait till pass-through agent retrieves it.   

4. On-premises pass-through agent retrieves the data from Azure AD queue (using an outbound connection) 

5. Agent decrypt the password using private key available for it. 

6. Agent validates the user name and password information with on-premises Active Directory. It uses same mechanism as ADFS. 

7. On-premises AD evaluate the request and provides the response. It can be success, failure, password-expire or account lockout. 

8. Pass-through agent passes the response back to Azure AD. 

9. Azure AD evaluate response and pass it back to user.

10. If response was success, user is allowed to access the application. 

Prerequisites
 
In order to implement this feature, we need the following,
 
1. Domain Admin / Enterprise Admin account to install and configure Azure AD Connect in on-premises 
2. Global Administrator Account for Azure subscription – in order to create custom domain, configure AD connect etc. 
3. On-premises servers running windows server 2012 R2 or latest to install Azure AD connect and pass-through agent.
4. Latest Azure AD Connect https://www.microsoft.com/en-us/download/details.aspx?id=47594 – if you have older Azure AD connect version installed, you need to upgrade it to latest before we configure this feature. 
5. Allow outbound communication to Azure via TCP port 80 and 443 from servers which will have Azure AD connect and authentication agents. You can find azure datacenter ip ranges from https://www.microsoft.com/en-us/download/details.aspx?id=41653
 

Configure Azure Active Directory Pass-through Authentication
 
Once we have all the prerequisites ready, we can look in to configuration. if you running Azure AD connect for first time make sure to use custom method.
 
pt1-1
 
Then in User sign-in option, select pass-through authentication and continue. 
 
pt1-2
 
If you running it already in servers, first run as Azure AD Connect as administrator. Then click on Configure.
 
pt2
 
Then in next page, select Change user sign-in option and click Next.
 
pt3
 
In next window type the Azure AD sync account login details and then click Next.
 
pt4
 
In next window, select pass-through authentication and click Next
 
pt5
 
Note– If you have Azure AD App Proxy Connector installed on same Azure AD connect server you will receive error saying, Pass-through authentication cannot be configured on this machine because Azure AD Connect agent is already installed. To fix it uninstall the Azure AD proxy connector and then reconfigure AD connect. After that you can reinstall Azure AD App proxy Connector. 
 
Once it finishes the configuration click on configure to complete the process. 
 
pt6
 
Once process is completed, log in to Azure Portal and then go to Azure Active Directory > Azure AD Connect. In there we can see pass-through authentication is enabled. 
 
pt7
 
And if you click on there it will shows the connected agents status. 
 
pt8
 
At this stages users from on-premises should be able to sign in to their cloud applications by using pass-through authentication.
 
in order to add high availability, we can install agent in multiple domain join servers. it can download from pass-through authentication page.
 
pt9
 
This completes the implementation of pass-through authentication and hope this post was useful. If you have any questions, feel free to contact me on rebeladm@live.com

Protect cloud Identities with Azure Active Directory Identity Protection

Symantec released their latest Internet Security Threat Report in early June. This report includes data about infrastructure threats for year 2016. It says, for year 2016, near 1.1 billion identities has been exposed. Also for last 8 years total identity breach is around 7.1 billion which is almost equal to total world population.

aip1

In Identity infrastructure breach, most of the time advisories get in to the system using a legitimate user name and password belong to an identity in that infrastructure. This initial breach can be result of malware, phishing or pass-the-hash attack. If it’s a “privileged” account, it makes easier for advisories to gain control over identity infrastructure. But it’s not always a must. All they need is some sort of a breach. Latest reports show after an initial breach it only takes less than 48 hours to gain full control over identity infrastructure.

When we look in to it from identity infrastructure end, if someone provides a legitimate user name and password it allows access to the system. This can be from the user or an advisory. But by default, system will not know that. In local AD infrastructure, solutions like Microsoft Advanced Threat Analytics, Microsoft Identity Management helps to identify and prevent inauthentic use of identities. Azure Active Directory Identity Protection is a feature comes with Azure AD Premium, which can use to protect your workloads from inauthentic use of cloud identities.  It mainly has following benefits. 

Detect vulnerabilities which affect the cloud identities using adaptive machine learning algorithms and heuristics.

Issue alerts and reports to detect/identify potential identity threats and allow administrators to take actions accordingly. 

Based on policies, force automated actions such as Block Access, MFA authentication or Password reset when it detects a suspicious login attempt. 

According to Microsoft https://docs.microsoft.com/en-us/azure/active-directory/active-directory-identityprotection Azure AD Identity protection has following capabilities.

Detecting vulnerabilities and risky accounts:

Providing custom recommendations to improve overall security posture by highlighting vulnerabilities

Calculating sign-in risk levels

Calculating user risk levels

Investigating risk events:

Sending notifications for risk events

Investigating risk events using relevant and contextual information

Providing basic workflows to track investigations

Providing easy access to remediation actions such as password reset

Risk-based conditional access policies:

Policy to mitigate risky sign-ins by blocking sign-ins or requiring multi-factor authentication challenges.

Policy to block or secure risky user accounts

Policy to require users to register for multi-factor authentication

Azure Active Directory Identity Protection detect and report following as vulnerabilities,

User logins without Multi-Factor Authentication

Use of unmanaged cloud apps – These are the applications which is not managed using Azure Active Directory. 

Risk events detect by Azure Privileged Identity Management – This is another additional service which can use to manage and monitor privileged accounts associated with Azure Active Directory, Office 365, EMS etc.

More info about these events can find on here 

Azure Active Directory Identity Protection also reports about Risk events. These are Azure Active Directory based events. These also use to create policies in Azure Active Directory Identity Protection. It detects six types of risk events. 
 
Users with leaked credentials
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from unfamiliar locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activity
 
More information about Azure risk events can find here 
 
Let’s see how we start using Azure Active Directory Identity Protection. Before we start we need to have following, 
 
1) Azure Active Directory Premium P2 Subscription
2) Global Administrator account  
 
Once you have above, log in to Azure as Global Administrator.
 
1) Go to New | then type Azure AD Identity Protection 
 
aip2
 
2) On Azure AD Identity Protection page click on Create
 
aip3
 
3) Then it loads up a new page with Azure Directory details and feature details. Click on Create again to proceed. 
 
aip4
 
4) Once it is done, go on and search for Azure AD Identity Protection under more services. Then it will show the dashboard for the feature. 
 
aip5
 
5) In my demo environment, it is immediately detect that I have 257 user accounts without MFA. 
 
aip6
 
6) The beauty of this is, once it detects a problem it guides you to address the issue. If I double click on the MFA alert, I gets the Multi-factor authentication registration policy settings page, where I can enforce users to use MFA. 
 
aip7
 
Under the user assignment, I can force it for all users or group of users. 
 
aip8
 
Under the controls, by default it selected the Require Azure MFA registration option. 
 
aip9
 
Under the Review option we can evaluate the impact. 
 
aip10
 
Once configuration is done, we can enforce the policy using Enforce Policy option. 
 
aip11
 
7) Using Sign-in risk policy, we can define actions system need to take in an event it detects sing-in risk from user. In order to define policy settings, click on Sign-in risk policy in Azure AD Identity Protection Dashboard
 
aip12
 
8) Then it loads up the policy configuration page. 
 
aip13
 
Under the Assignments we can decide which users this policy applies to. It can be either All users or group of users. we also can exclude users from the selection. 
 
aip14
 
Under the Conditions, we can select the level of sing-in risk events need to consider in the policy. there are three options to select with which is low and above, medium and above or High.
 
aip15
 
Under the Access option we can define what system should do once it detect risk events. It can either block access completely or allow access with additional security conditions such as Require multi-factor authentication.
 
aip16
 
Using Review option we can see what kind of impact policy will make ( if there are any existing risk events). 
 
Once all these done, use Enforce Policy option to enforce it. 
 
aip17
 
9) In similar way using User risk policy we can define policy settings to handle risky users. 
 
10) We also can configure Azure AD Identity Protection to send alerts when it detects an event. To do that go to Alerts option in Azure AD Identity Protection Dashboard
 
aip18
 
In configuration page, we can define the lowest alert level that need to consider. So, any event equal to that level or above will send out as alert to the selected recipients. 
 
aip19
 
11) Azure AD Identity Protection also can send automated weekly email report with events it detected. In order to configure it go to Weekly Digest option in Azure AD Identity Protection Dashboard
 
aip20
 
In configuration page, we can select which recipients it should goes to. 
 
aip21
 
In this article, I explained what is Azure AD Identity Protection and how we can use it to protect cloud identities. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Conditional Access Policies with Azure Active Directory

When it comes to manage access to resources in infrastructure, there are two main questions we usually ask.

  1. “Who” is the user and “What” resources?
  2. Is it allow or deny access? 

Answers to above questions are enough to define the base rules. But depending on the tools and technologies that can use to manage the access, we will have additional questions which will help us define accurate rules. As an example, Sales manager walks up to the IT department and says “Peter need to access “Sales” folder in the file server”. So, based on the statement, we know the user is “Peter” and resources is “Sales” folder in the “File Server”. Also, we know the user “Peter” needs to “Allow” access to the folder. However, since we are going to use NTFS permission, we know that we can make the permissions more accurate than that. When sales manager says “Allow” peter to access “Sales” folder he didn’t define it as “Read & Write” or “Read Only”. He didn’t also define if he need same permission to all the sub folders in the “Sales” folder. Based on answer to those, we can define more granular level rules.

Access control to resource in an infrastructure happens in many different levels with many different tools and technologies. The first level of control happens in the network perimeter level. Using firewall rules, we can handle “in” and “out” network traffic to/from company infrastructure. If user pass that level, then it will verify the access based in users and groups. After that it comes to applications and other resources. But problem we have as engineers is to manage all these separately. Let’s go back to our previous example. In there we only consider about NTFS permission. If “Peter” is a remote worker and he connect to internal network using Remote desktop services, first we need to define firewall rules to allow his connection. Then if multi-factor authentication required for remote workers, I need to configure and defines rules in there. Also, when user logs in, he will not have same permission he has in company workstation. So, those session host permissions need to be adjusted too. So, as we can see even its sounds simple, we have to deal with many different systems and rules which cannot combine in to “one”.

So far, we looked in to on-premises scenarios. When it comes to cloud, the operation model is different. We cannot apply the same tools and technologies we used to manage access in on-premises. Microsoft Azure’s answer for simplifying access management to workloads is “Conditional Access”. This allow manage access to applications based on “Conditions”.  When it comes to public cloud mostly we allowing access to applications from networks we do not trust. There for, using “Conditions” we can define policies for users which they need to comply, in order to get access to the applications.

In Condition Access Policy, there are two main section.

Assignments –  This is where we can define conditions applying to user environment such as users and groups, applications, device platform, login locations etc.

Access Control –  This is to control access for the users and groups when they comply with the conditions specified in the “assignments” section. it can be either allow access or deny access.

cac1

Let’s see what conditions we can applies using conditional access policies. 

Assignments 

Under the assignment section there are three main options which can use to define conditions. 

1) Users and Groups

2) Cloud apps

3) Conditions 

User and Groups

Under the user and groups option we can define the users and groups targeted by the condition access policy. 

We can select define target as “All” or selected number of users and groups. 

cac2

We also can explicitly select groups and exclude individuals from it. 

cac3

  

Cloud Apps

  

Under the cloud app option we can select the applications which is targeted for the policy. these applications can be Azure apps or on-premises applications which is published via Azure Active Directory using Azure App Proxy. Similar to users and groups, we also can explicitly allow access to a large group and exclude specific entities. 

cac4

Condition 

Using options under this category we can specify the conditions related to user’s login environment. This category has 4 sub-categories. 

1) Sign-in risk

2) Device Platforms

3) Locations

4) Client Apps

It is not required to use all these sub-categories for each and every policy. By default, all these are in disabled mode. 

 

Sign-in risk

Azure Active Directory monitor user login in behavior based on six types of risk events. These events are explained in details on https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-risk-events#risk-level . As an example, I am usually login to azure from IP addresses belongs to Canada. I log in to azure at 8am from Toronto. After 5 minutes, its detects a login from Germany. In typical scenario, it’s not possible unless I use a remote login. From Azure point of view, it will detect as malicious activity and will rate as “Medium” risk event. In this sub-category, we can define what level of sign-in-risks need to consider. 

cac5

Note – If you need enable the policy, you need to first click on “Yes” under configure option.

cac6

Device Platforms

Device platforms are categorized based on the operating systems. it can be,

Android

iOS

Windows Phone

Windows

cac7

We also can explicitly allow all and then exclude specific platforms.

Locations

Locations are defined based on IP addresses. If it’s only for “trusted” IP addresses, make sure to define trusted IP addresses using the given option.

cac8

Client Apps

Client apps are the form that users access the apps. It can be using web, mobile apps or desktop clients. Exchange ActiveSync is available when Exchange Online is the only cloud app selected. 

cac9

Access Controls 

There are two categories which can use to add the access control conditions to the policies. 

1) Grant

2) Session

Grant

In this category, we can specify the allow or deny access. Under the allow access, we can add further conditions such as,

Require multi-factor authentication

Require device to be marked as compliant

Require domain joined device

cac10

MFA

Multi-factor authentication is additional layer of security to confirm the authenticity of the login attempt. Even policy set to allow access, using this option we still can force user to use MFA. This is allowed to use Azure MFA or on-premises MFA solution (via ADFS).

 

Compliant

 

Using Microsoft Intune, we can define rules to categorize the user devices are compliant or not according to company standards. if this option is used, only the devices which is compliant will consider.

 

Domain Joined

 

If this option is used, it will only consider connection from Azure Active Directory domain joined devices.

Once you define the options, it can either force to use all the options or only to consider “one” of the selected. 

cac11

Sessions

This is still on preview mode. This is basically to provide additional information about session to the cloud app so it can confirm authenticity of the session. Not every cloud app supports this option yet. 

cac12

Demo

By now we know what are the conditions we can use to define a condition access policy. Let’s see how we can configure a policy with a real-world example. Before we start, we need to look in to prerequisites for the task. In order to setup condition access policies we need following.

1. Valid Azure Active Directory Premium Subscription

2. Azure Administrator Account to create policies

In my demo, I have a user called “Berngard Saller”. He is allowed to access an on-premises application which is published using Azure Application Proxy (http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-02/). 

cac13
 
I need a condition access policy to block his access to this app if he is login from a device which use “Android OS”. 
So, let’s start,
 
1. Log in to the Azure portal as Administrator.
2. Click on Azure Active Directory | Conditional Access
 
cac14
 
3. In new page, Click on + New Policy
 
cac15
 
4. In next window, first provide a Name for the policy
 
cac16
 
5. Then click on Users and Groups | Select Users and Groups | Select. Then from the list of users select the appropriate user (in my demo its user Berngard Saller) and then click on Select button. 
 
 
cac17
 
6. Then in next window click on Done
 
cac18
 
7. Next step is to define the App. To do that, Click on Cloud Apps | Selected Apps | Select. Then from the list select the relevant app (in my demo its webapp1) and then click on Select button. 
 
cac19
 
8. Then in next window click on Done
 
9. As next step, go to Conditions | Device Platforms | Click on Yes to enable Condition | Select Device Platforms | Android. then click on Done button. 
 
cac20
 
10. Then in next window click on Done
 
11. Next step is to define Access Controls. To do that Click on Grant | Block Access. Then click on Select button. 
 
cac21
 
12. Now we have the condition policy ready. Click On under Enable Policy and click on Create button to create the policy. 
 
cac22
 
Now we have the policy ready. The next step is to test. 
 
cac23
 
When I access the app from windows system, I have allowed access. 
 
cac24
 
But when I do it from android mobile it denied access as expected. 
 
cac25
 
As we can see conditional access simplifies the access control to workloads in Azure. 
 
This is the end of this post and if you have any questions feel free to contact me on rebeladm@live.com

Manage Azure Active Directory with PowerShell – Part 01

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

mson1

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

Get-Command -Module MSOnline

mson2

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

mson3

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

Get-MsolUser

mson4

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 *

mson5

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.

mson6

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.

mson7

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

mson8

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

Get-MsolGroup -SearchString "AAD"

mson9

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

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

mson10

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.

mson11

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

Which azure active directory edition I should buy?

4ac52e5b-b3ac-4fbd-bbc7-bd4bae8403da

Azure active directory is responsible for providing identity service for Microsoft online service’s needs. When I talk to people about azure AD one of most common problem they ask is what version I should buy? my existing subscription will work for the features I looking for? The myth is, lot of people still thinks azure subscriptions and prices are complicated, but if you understand what each subscription can do it’s not that hard. I have seen people paying for Azure AD premium version when azure AD free version can give the features they needed for their environment and some people struggling to implement features only available for premium version using their free azure AD instance. In this blog post I am going to list down the features for each azure AD version and hope it will help you to decide the version you need for your setup.

There are 4 Azure AD editions,

1) Free

2) Basic

3) Premium P1

4) Premium P2

Free – if you subscribed to any Microsoft online service such as azure or office 365 you will get the free azure AD version. You do not need to pay for this. But it got limited features which I will explain later in this post.

Basic – Designed for task workers with cloud-first needs, this edition provides cloud centric application access and self-service identity management solutions. With the Basic edition of Azure Active Directory, you get productivity enhancing and cost reducing features like group-based access management, self-service password reset for cloud applications, and Azure Active Directory Application Proxy (to publish on-premises web applications using Azure Active Directory), all backed by an enterprise-level SLA of 99.9 percent uptime.
 
Premium P1 – Designed to empower organizations with more demanding identity and access management needs, Azure Active Directory Premium edition adds feature-rich enterprise-level identity management capabilities and enables hybrid users to seamlessly access on-premises and cloud capabilities. This edition includes everything you need for information worker and identity administrators in hybrid environments across application access, self-service identity and access management (IAM), identity protection and security in the cloud. It supports advanced administration and delegation resources like dynamic groups and self-service group management. It includes Microsoft Identity Manager (an on-premises identity and access management suite) and provides cloud write-back capabilities enabling solutions like self-service password reset for your on-premises users.
 
Premium P2 – Designed with advanced protection for all your users and administrators, this new offering includes all the capabilities in Azure AD Premium P1 as well as our new Identity Protection and Privileged Identity Management. Azure Active Directory Identity Protection leverages billions of signals to provide risk-based conditional access to your applications and critical company data. We also help you manage and protect privileged accounts with Azure Active Directory Privileged Identity Management so you can discover, restrict and monitor administrators and their access to resources and provide just-in-time access when needed.
 
azure ad version 1
azure ad version 2
azure ad version 3
 
You can find more info about the subscriptions from 
 
if you got any question feel free to contact me on rebeladm@live.com

 
Note : Image Source https://f.ch9.ms/thumbnail/4ac52e5b-b3ac-4fbd-bbc7-bd4bae8403da.png

Getting Started with Azure AD B2B collaboration

What is Azure AD B2B ?

By now I assume you have idea what is Azure AD and how it works. If you are new to my blog, please search for Azure AD on my blog and you will be able to find articles explaining about it and its capabilities. Azure AD manage identities for the company and it will allow to control access to resources such as applications. Sometime based on business requirements companies have to share their resources with partners, other companies in group etc. in such scenario Azure AD B2B collaboration supports to share resources with another party using their own identities.

Using Azure AD B2B partners can use Azure AD account they create using the invitation process. Then azure admins can control the access to the applications. Once the tasks are completed those accounts easily can remove from the azure AD and all the permissions to the resources will be revoked. The partner company do not need to have any azure subscription and it allow to provide quick access to the resource with minimum changes.  

How it works?

1) Administrator invites the partner users by uploading the user details using CSV file. This file need to create with specific fields and values and more details can find on https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2b-references-csv-file-format/

2) Azure portal sends invite emails to the users which is imported using CSV file

3) Users click on email link and sign in using their work credentials (if they have azure AD account) or sign up as an Azure AD B2B collaboration user

4) User log in and access the shared resources

Let’s see it in action 

To enable azure AD B2B collaboration for an Azure AD instance you need to have global administrator privileges. So before you start make sure you got the relevant permissions. 

As I said previously the user accounts details need to be uploaded via a CSV file. In here I have created a simple CSV file with test account.

b2b1

After that log in to azure portal and load the Azure AD instance you already have.

b2b2

Then go to users and click on Add

b2b3

From the wizard select the “Users in Partner Companies” as the type of the user

b2b4

then brows for the CSV file and import

b2b5

after few minutes the user got email with link

b2b6

once click on the link it will load up a page and click next to continue

b2b7

in next page provide a password and click next

b2b8

it will send code to verify email address and once you put it there click on finish

b2b9

once process finish, we can see the new user under the azure AD users

b2b10

now I have application under my directory and when I go to users I can see the new user we setup. I have assign the permission for the new user for the app.

b2b11

So when login to the azure portal as the new partner user now can see the applications which is assigned for the user.

b2b12

Hope this was helpful and if you have questions feel free to contact me on rebeladm@live.com 

Azure Rights Management (Azure RMS) – Part 1

Microsoft Right management service help organizations to protect organization’s sensitive data getting unauthorized access. This service been used on-premises active directory infrastructures in years and it’s also available in azure.

If you not familiar with RMS let me explain it in simpler way. Let’s say user A got a document which contain some sensitive data about company stock prices. User A sending it to User B. This we know should be a conversation between user A and B. and how we can verify these data not been to pass to another user? What if someone gets a printed copy of this document? What if the user B edit this and add some false information? Using RMS you can prevent those. RMS can use to encrypt, managed identities and apply authorization policies in to your files and emails. The files you can define to open only by the person who you wished to open it, set it to read-only and also prevent user from printing it.

Using Azure RMS you can integrate the above features with your cloud applications, office 365 to protect the confidential data.

azrms_elements

In order to enable the Azure RMS you need the following prerequisites.

1)    Valid Azure Subscription – You need to have valid azure subscription to start with. If you not have paid version you still can start with a trial.
2)    Azure AD – You must have Azure AD configured to have RMS. I have written articles about how to get Azure AD services enable and you can simply search the blog if you need help with it. Also you can integrate it with your on-premises Ad infrastructure.
3)    RMS Supported Devices – you need to have devices runs with RMS supported OS to use this features. The list is available at https://docs.microsoft.com/en-us/rights-management/get-started/requirements-client-devices
4)    RMS Supported Applications – to use RMS features its need to be used with RMS supported applications. The list is available here https://docs.microsoft.com/en-us/rights-management/get-started/requirements-client-devices

Once you are ready with above first step is to enable the Azure RMS Service.
1)    Log in to the Azure Portal with a privileged account
2)    Go to Brows and then type rms, then it will list the RMS service then click on it.

rms1

3)    It will load the classic portal. In here you can see all the azure Ad instance running and its RMS service status. In my demo I do not have any instance enable with RMS.

rms2

4)    To enable the RMS service, select the AD instance and the click on “Activate” button in the bottom of the page.

rms3

Once it’s activated we have RMS enabled. In next part of the article let’s see how to use its features.

If you have any questions feel free to get back to me on rebeladm@live.com

Step-by-Step Guide to create Organizational Unit (OU) in Azure AD Domain Service Managed Domain

Organizational unit in active directory is a container where you can place users, computers, groups and other organization units even. OU are helps to create logical structure of the AD. You can use it to assign group policies and manage the resources.  This is common procedure in in-house domain environment, but what about the Azure managed domain? Can engineers use same method?

Answer is YES, but with some limitations. It is managed domain so you do not have full control over the functions such as complex group policies etc. I will explain those in later article but for the Organizational units, we can create those and manage those in azure managed domain. There is no option in azure portal to create this, this need to be created using a PC, server which is connected to the Azure Ad managed domain.

I wrote an article about adding a VM to the Azure managed domain. It is good place to start with http://www.rebeladmin.com/2016/05/step-step-guide-manage-azure-active-directory-domain-service-aad-ds-managed-domain-using-virtual-server/ . To create OU, you must have this done before start.

You also need be a member of AAD DC Administrators group.

Let’s see how we can create OU.

In my demo I am using a windows 2016 TP5 server which is connected to managed domain. Also I logged in as a member of AAD DC Administrators group.

ou1

Also I have already installed AD DS and AD LDS Tools (Remote server administration tools > Role administration tools > AD DS and AD LDS Tools)

ou2

To start the process, go to Server Manager > Tools > Active Directory Administrative Center

ou3

In left hand side in the console click on the managed domain

ou4

In the right hand under the Tasks click on New > Organizational Unit

ou5

In next window we can provide the information about new OU and click OK to complete.

ou6

Then you can see the new OU added.

ou7

By default the user account I used for to create the OU got full permissions to control the OU.

ou8

Now you can create new users, groups under this OU. But keep in mind you CANNOT move any users, groups which is already under AADDC users OU. It’s the default OU for the users, groups added via azure portal.

ou13

Also the users and groups added under new OU will not be visible on azure portal. It’s only valid inside the managed domain environment.

Hope this article was helpful. If you got any questions feel free to contact me on rebeladm@live.com

Step-by-Step guide to enable Secure LDAP (Lightweight Directory Access Protocol) on Azure AD managed domain

In active directory environment, LDAP (Lightweight Directory Access Protocol) is responsible for read and write data from AD. By default LDAP traffic transmitted un-secure. You can make this secured transmit based on SSL. In security prospective even in more “local” network it’s important to make secure even though most of engineers not using it. But when you have hybrid or cloud only setup this is more important. Idea of this post is to demonstrate how to enable secure LDAP on Azure AD managed domain.

There is few prerequisite required to perform this task.

1)    Azure AD Domain Service – Azure AD domain service must be enabled and configured with all prerequisite. If you need any help over please refer to my last few posts which explain how to configure.
2)    SSL Certificate – It is need to have valid SSL certificate and it need to be from valid certificate authority such as public certificate authority, enterprise certificate authority. Also you can still use self-sign SSL certificate.

In my demo,
1)    I have already configured a Azure AD managed domain and running with active subscription

sldap1

2)    I got an Azure VM connected to Azure managed domain and I will be using it to demonstrate to enable Secure LDAP.
3)    I am going to use self-signed certificate to create the secure LDAP

Create self-signed certificate

1)    Log in to domain joined server, or PC and open windows power-shell session as administrator.
2)    Execute following

$validtill=Get-Date
New-SelfSignedCertificate -Subject *.rebeladmin.onmicrosoft.com -NotAfter $validtill.AddDays(365) -KeyUsage DigitalSignature, KeyEncipherment -Type SSLServerAuthentication -DnsName *.rebeladmin.onmicrosoft.com

In here you can replace rebeladmin.onmicrosoft.com with your managed domain name.

This will generate the self-sign certificate.

sldap2

Export the SSL Certificate

Now we have the certificate, but we need to export it to use to enable secure LDAP.
1)    Log in to the PC or Server which generated certificate as administrator
2)    Go to run > mmc

sldap3

3)    File > Add/remove Snap-in

sldap4

4)    Select Certificates and click on button Add

sldap5

5)    Then select the Computer Account and click next

sldap6

6)    Select local computer and click on finish

sldap7

7)    Click on OK to open the certificate mmc

sldap8

8)    Then in console go to Personal > Certificates and you can see the new self-signed certificate we just created in previous step

sldap9

9)    Right click on the certificate and click on All tasks > export

sldap10

10)    Then its start the certificate export wizard, click on next to start

sldap11

11)    In this window select option “Yes, export the private key” and click on next
12)    Leave the .pfx option selected and click next

sldap12

13)    In next window define a password and click on next

sldap13

14)    Then define the location to save the file and click on next

sldap14

15)    Click on finish to complete the export process

sldap15

Enable Secure LDAP

Now we got the SSL exported and ready. Now it’s time to enable the secure LDAP.
1)    Log in to the azure portal and load the Azure Domain Services configuration page for your relevant directory

sldap16

2)    Then to the domain service section and click on “configure certificate” button

sldap17

3)    Then brows for the .pfx file we just exported and provide the password, then click ok to proceed

sldap18

4)    After few minutes we can see the secure LDAP is enabled

sldap19

5)    The next step is to enable the secure LDAP connection over the internet for your managed domain. For that click on the “Yes” for the option “Enable secure LDAP access over the internet” and the click save

sldap20

sldap21

6)    After few minute we can see the feature is enabled and also displaying the public ip address which can use on this.

sldap22

7)    If you wish to use secure ldap over the internet you need to create DNS entry in your dns provider and create A record to point domain to the public ip address its given.

Hope this was helpful post and if you have any question on this feel free to contact me on rebeladm@live.com