Tag Archives: Azure AD connect

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

Step-by-Step guide to configure self-service password reset in Azure AD

Password reset for AD users is a common call, ticket for the help desk. This is sometime negatively affecting company operations. Because users will not have access to systems and applications until the password reset by help desk engineers. What if we can allow end users to reset their passwords them self in a secure manner?

Yes Azure AD is now gives opportunity to enable self-service password reset for the end-users. Also the password resets can sync with on-premises AD.

This feature is disabled by default. In this demo I will explain how to enable this feature and configure.

On the demo setup I am using have Azure AD instance which is sync with on-premises windows server 2016 TP4 AD.

1)    Log in to the Azure Portal and load the Azure AD Instance
2)    Then in Dashboard, under configure services you can find option “Self Service Password Reset” By default it’s disabled. Click on “Configure” to proceed with configuration.

spw1

3)    Then in next page under User Password Reset Policy select option “Yes” next to “Users enabled for password reset

spw2

4)    Now it will give you options to configure the policy for the password reset. Let’s look in to  some of these options and understand what they do.

Restrict access to password reset – Using this option password reset can only allow for a security group instead of allowing it for every user in the instance. Any member of allowed security group will get option to do a self-service password reset.

Authentication Methods Available to Users – its allow you to use following options to select with. We can allow to use any selected authentication methods for users. 

Number of Authentication Methods Required – In this option we can choose how many methods required for successful password reset

spw3

Require users to register when signing in?
– When this option is enabled users can register their own authentication method when sign up.

Write back passwords to on-premises active directory
– with this option if a user reset password using self-service portal it will write back to the on-premises AD too.

In order to get this write back option work, it need to be enabled in Azure AD connect in on-premises AD.

aad1

5)    In demo I am configuring “Security Questions” as authentication method. With that option you can define the different security questions, as well as the number of questions required to answer.

spw4

6)    Once options are configure click on save to apply the changes.

spw5

7)    Let’s see how it works in user end.  I am trying to log in to azure portal as standard user. In first login it’s ask additional information to setup for password reset. Click on setup to provide the additional info.

spw6

spw7

8)    Now all the additional info is saved. Let’s see how it works. I am going to log in with wrong password to simulate it. As soon as I done it, it ask if you need to reset the login.

spw8

9)    Clicked on “Forgot your password ?” option

10)    As first check it’s asking to enter the characters in picture. Click next to continue

spw9

11)    Then it ask which option to use for the password reset, according to the policy. Select the option you like to use.

spw10

12)    Then it’s ask for the second authentication. As per the policy.

spw11

13)    Once authentication success, it’s ask to submit the new password.

spw12
14)    Once its finish you can successfully login with new password.

spw13

If you have any questions about the post feel free to ask me on rebeladm@live.com

Step-by-Step guide to configure MFA (multi-factor authentication) for azure users

MFA, I am sure it’s not a new concept today for IT administrators. Its additional layer of security to confirm the user identity. It can be in form of PIN verify, phone call, smart cards, biometrics etc.

This feature is mainly used in infrastructure when its release, extending its services to “internet face”. There are lot of MFA service providers in market. You can either use it as on-premises service or cloud based service.

When it comes to azure the same security concerns applies. If you integrated it with on-premises active directory security is more concerned as it will extend the security boundaries of the infrastructure.

In this article I will demonstrate how “easily” you can enable multi-factor authentication for azure user.

In my demo I have a windows server 2016 TP4 on-premises AD configured to sync with azure ad. I am going to enable MFA for an azure user account which is sync from on-premises AD.

1)    Log in to your azure portal
2)    Then brows > Active Directory

mfa1

3)    Load your AD directory and go to users

mfa2

4)    For my demo I am using user account “user1”, this user account is sync from local active directory
5)    Select the user account and click on “manage multi-factor authentication

mfa3

6)    Then it will load a new page to manage MFA. As you can see currently for “user1” MFA disabled

mfa4

7)    To enable, click on tick box next to “user1” and click on option ”enable” in right hand panel

mfa5

8)    Then it will open a pop up window with help options. Click on “enable multi-factor auth

mfa6

9)    Now it’s enabled. Let’s try to log in azure portal as the use to see.

mfa7

10)    Then it saying MFA is enabled and it need to setup. Click on “setup now” to proceed

mfa8

mfa9

11)    Then in next page it gives option to select the authentication method.
12)    There is 3 ways to authenticate

Authentication phone – This will send SMS or also can setup to call back to the given number. Please note if you use this option SMS and call charges will be added.

Office Phone – This option is to request contact using office phone specified by admin

Mobile App – With this option you can install mobile application (Azure Authenticator) on your phone and it can set to send notification via app when try to login or to use verification code

mfa10

13)    Once select the option and its settings, click on setup

mfa11

14)    In my demo I used mobile app option. Once its completed the setup (you need to follow different options to setup based on your selection) let’s check the login page again

mfa12

15)     Now it’s asking for the PIN verification before login.

As we can see now MFA is enabled for the selected azure ad user.
In future post I will explain how we can change settings for MFA.

If you have any question feel free to contact me on rebeladm@live.com

How to Monitor your on-premises AD infrastructure with “Azure AD Connect Health”?

As system administrator, how you currently monitor your AD infrastructure? I am sure I will get lot different answers such as SCOM, Event viewer, Performance monitor, Third party application monitors etc. when the AD infrastructure expand, grow the effort and cost you need to put to monitor the AD infrastructure increase too. This is getting more complex if you using hybrid infrastructure. Integrating Azure AD with on-premises AD gives you reliable and productive identity platform for your cloud and on-premises resources. But same time it makes more important to maintain healthy on-premises AD infrastructure and sync service in order to achieve this goal.

Microsoft introduces “Azure AD Connect Health” to monitor your on-premises AD infrastructure. It will give opportunity to view alerts, performance, sync errors, configuration settings etc. Idea behind this is to build a central, cloud based approach to get more insight about the on-premises AD infrastructure.

aadconnecthealth2

Another feature of AD connect Health is the AD FS 2.0 & 3.0 support. This also can monitor the health of on-premises AD FS configuration.

According to Microsoft Azure AD connect health for sync provides following services,

•    View and take action on alerts to ensure reliable synchronizations between your on-premises infrastructure and Azure Active Directory.
•    Email notifications for critical alerts
•    View performance data

Azure AD Connect Health for AD FS provides following services,

•    View and take action on alerts for reliable access to AD FS protected applications including Azure AD
•    Email notifications for critical alerts
•    View performance data to determine capacity planning
•    Detailed views of your AD FS login patterns to determine anomalies or establish baselines for capacity planning

Requirements

In order to use AD health connect service following requirements needs to fulfil,
1)    Azure AD premium subscription
2)    Azure AD connect health agent installed in target server (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health-agent-install/)
3)    If you monitoring AD FS, audit must be enabled (https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health-agent-install/#installing-the-azure-ad-connect-health-agent-for-ad-fs)
4)    Outbound connectivity to following end points

new: https://management.azure.com
new: *.blob.core.windows.net
new: *.queue.core.windows.net
*.servicebus.windows.net – Port: 5671
https://*.adhybridhealth.azure.com/
https://*.table.core.windows.net/
https://policykeyservice.dc.ad.msft.net/
https://login.windows.net
https://login.microsoftonline.com
https://secure.aadcdn.microsoftonline-p.com

5)    Following firewall ports needs to be open in any server running agent

TCP/UDP port 80
TCP/UDP port 443
TCP/UDP port 5671

So enough talking, let’s see how we can configure this service. For demo I am using on-premises AD server which is built on windows server 2016 TP4.

1)    Log in to the Azure portal and search for “Azure AD Connect Health

aad1

2)    Select the service and in next window click on “Create”

aad2

3)    Once its created, it can see in portal dashboard

aad3

4)    Then click on the shortcut to go to the detail service page. In here click on “Quick Start” button to start the process

5)    In next window it give option to download the relevant agent.  For the demo I need “Download Azure AD Connect (configures Azure AD Connect Health agent for sync)”

aad5

6)    Once it’s downloaded to the target computer, double click it. ( you need to have required permissions on the target computer to do the installation)

aad6

7)    In the demo, the target server is do not have Azure AD connect configured. If you already had it, it is not necessary to do the agent install. Once installation is done, double click on the short cut for azure AD connect. Then in first window, accept the terms and click continue.

aad7

8)    In next window, I will use express settings.

aad8

9)    In next window, provide the Azure AD connect info

aad9

10)    Then type the AD admin credentials and click next

aad10

11)    Then in next window, click install to start the installation and synchronization

12)    After the sync completes, log back in to the azure AD connect health and you can see the monitoring info.

aad11

aad12

if you have any question feel free to contact me on rebeladm@live.com

image source : https://acom.azurecomcdn.net/80C57D/cdn/mediahandler/docarticles/dpsmedia-prod/azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health/20151223054713/aadconnecthealth2.png