Technical Blog | REBELADMIN

Learn about Active Directory and Various Azure Services

Azure Active Directory Domain Services

Step-by-Step Guide: Enable secure LDAP (LDAPS) for an Azure Active Directory Domain Services managed domain

In an on-premises Active Directory environment, there can be application or service which required integration with Active Directory. With AD integration, the application can search for AD users, allow login, assign permissions, etc. This integration part is usually done using the Lightweight Directory Access Protocol (LDAP). By default, traffic over LDAP is not encrypted. Due to the vulnerabilities, Microsoft now recommends only to use secure LDAP (LDAPS, LDAP over SSL) connections to Domain Controllers. Azure Active Directory Domain Services (Azure AD DS) also support for secure LDAP connections. Most of the time the LDAP connection to Azure AD DS will be initiated over the public internet. So, it is important to have encryption in place to prevent man-in-the-middle attacks.

In this post, I am going to demonstrate how to enable secure LDAP for Azure AD DS. Before we start make sure you have the following prerequisites in place.

1. Valid Azure Subscription
2. Valid Azure Active Directory Domain Services (Azure AD DS) setup – I assume you already have Azure Active Directory Domain Service configured. More info about Azure AD DS setup can find on this link
3. Valid SSL certificate – We need a valid SSL certificate to enable secure LDAP. If Azure Active Directory Domain Service uses custom domain name, we can use public CA (3rd party) or enterprise CA to issue a certificate for it. If Azure Active Directory Domain Service is using Microsoft default domain .onmicrosoft.com, we have to use self-sign certificate for it as public CA can’t issue certs for the default domain. In this demo, I will be using a self-sign certificate for the configuration.
4. Test PC – We need a PC to test the secure LDAP connectivity.

Before we enable secure LDAP, we need to create a certificate for it. In this demo, my Azure Active Directory Domain Service instance is using default Microsoft domain name rebeladmlive.onmicrosoft.com. So, I have to use a self-sign certificate for it. To generate a self-sign certificate, we can use the following PowerShell commands. This can be run from any PC.

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

create self sign certificate powershell

In above, replace rebeladmlive.onmicrosoft.com with your Azure Active Directory Domain Service instance name. As we can see, it created a wild card SSL for rebeladmlive.onmicrosoft.com under Computer account.

SSL certificate mmc

We need to export this certificate as .PFX file with private key to,

1. Use it during the secure LDAP setup and upload it to Azure
2. Import it to any other PC which like to initiate secure LDAP connection (The certificate must be imported into Computer Account\Personal\Certificates as well as Trusted Root Certification Authorities\Certificates. This is because the certificate is self-sign cert and it doesn’t have trusted root certificate)

To export certificate,

1. Right-click on the certificate and go to All Tasks | Export

export ssl certificate

2. It will open up the certificate export wizard, click on Next to start the process.

export certificate wizard screen 1

3. In the next window select Yes, export the private key, and click on Next.

export certificate wizard screen 2

4. In the Export file format window, match the following selection, and click on Next.

export certificate wizard screen 3

5. In the next window, define the password for the export file and click on Next.

export certificate wizard screen 4

6. Then, select the file path for the output and click on Next.

export certificate wizard screen 5

7. In the next window, click on Finish to complete the Export process.

export certificate wizard screen 6

Now we have the .PFX file. The next step is to import it again to Trusted Root Certification Authorities\Certificates. This is required as we are using a self-sign certificate for the exercise. [Read more…] about Step-by-Step Guide: Enable secure LDAP (LDAPS) for an Azure Active Directory Domain Services managed domain

Step-by-Step guide to enable Azure AD authentication for Azure Files

"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. 

[Read more…] about Step-by-Step guide to enable Azure AD authentication for Azure Files

Step-by-Step Guide: Azure AD Access Reviews for Applications

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 https://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 

[Read more…] about Step-by-Step Guide: Azure AD Access Reviews for Applications

Step-by-Step Guide: How to setup Google federation for Azure AD B2B?

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 https://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. 

[Read more…] about Step-by-Step Guide: How to setup Google federation for Azure AD B2B?

Step-by-Step guide to configure risk-based azure conditional access policies

Some time ago I wrote this article about sign-in risk-based conditional access policies. But things have been changed over time and I thought it is time to update it with new content. The updated post can access using  https://www.rebeladmin.com/2020/11/step-by-step-guide-how-to-configure-sign-in-risk-based-azure-conditional-access-policies/

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 – https://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 – https://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.

Sign-in Activity

Risk Level

Users with leaked credentials

High

Sign-ins from anonymous IP addresses

Medium

Impossible travel to atypical locations

Medium

Sign-ins from infected devices

Medium

Sign-ins from IP addresses with suspicious activity

Low

Sign-ins from unfamiliar locations

Medium

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.