Tag Archives: Active Directory

on-Premises Azure Active Directory Password Protection

Last year I wrote a blogpost on password in Azure Active Directory (Choose a password that’s harder for people to guess – https://jaapwesselius.com/2018/10/15/choose-a-password-thats-harder-for-people-to-guess/) in which I mentioned the banned password lists and the Azure AD Password Protect feature. Back then this was only for Azure AD, but right now it is also available for on-premises Domain Controller as well (for some time already). It is possible for on-premises Domain Controllers to use the password protect functionality in Azure AD and thus block the possibility to use weak passwords in your on-premises environment. Let’s see how it works.

The password protection feature on-premises uses a Password Protection Agent that’s running on the on-premises Domain Controllers. When a user initiates a password change, the new password is validated by the Azure AD Password Protection agent, which request a password policy from the Azure AD Password Protection proxy service. This Password Protection service requests a password policy from Azure AD. The new password is never sent to Azure AD. This is shown in the following picture (borrowed from the Microsoft website):

azure-ad-password-protection

After receiving the password policy, the agent returns pass or fail for the new password. In case of fail the user must try it again.

Installation of the password protect consists of two steps:

  • The Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe software installer. This is installed on a domain joined computer that has access to the Internet and proxies the password policy request to Azure Active Directory.
  • The DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi package. This runs on the Domain Controllers and send the password policy requests to the server running the proxy service.

Both can be downloaded from the Microsoft download center on https://www.microsoft.com/en-us/download/details.aspx?id=57071

Password Protection Proxy Installation

The first step is to install the password protection service. This server should be able to access Azure AD and since the Domain Controller does not have an internet connection this should be installed on a separate server. In my lab environment I have installed the password protection service on the Azure AD Connect server.

Installation of the password protection proxy is straightforward; you can use the GUI or the command line setup with the /quit switch for unattended install (and Server Core). After installation use PowerShell to register the proxy in Azure AD by using the following commands:

[PS] C:\> Import-Module AzureADPasswordProtection
[PS] C:\> Register-AzureADPasswordProtectionProxy -AccountUpn 'administrator@tenant.onmicrosoft.com'

This command can work when you have MFA enabled for admin accounts, if you don’t require MFA on your admin accounts (which is a bad practice IMHO) you can use the following command:

[PS] C:\> $globalAdminCredentials = Get-Credential
[PS] C:\> Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials

The last step is to register the forest in Azure Active Directory. This is very similar to the registration process of the proxy service. You can use the following PowerShell commands to register the forest:

Register-AzureADPasswordProtectionForest

[PS] C:\> Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’

Again, when MFA is not enabled you can use the following command to register your forest in Azure AD:

[PS] C:\> $globalAdminCredentials = Get-Credential 'yourglobaladmin@yourtenant.onmicrosoft.com'
[PS] C:\> Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials

Note. A multi-forest scenario is supported for the Password Protection service, you can install multiple forest using these commands. Multiple domains against one tenant is supported, one domain against multiple tenants is a not-supported scenario.

Some remarks:

  • The server where the password proxy agent server is installed should have .NET Framework 4.7 or higher installed.
  • For high availability it is recommended to install the password protection agents on multiple servers
  • The password protection proxy supports an in-place upgrade, so a newer version can be installed without uninstalling the previous version.

So how does this work, and how does the password protection service find the proxy server (or servers)?

When the Password Protection Proxy is installed it is registered in Active Directory with a well-know GUID. The Password Protection Agent checks Active Directory for this well-know GUID and finds the server where the Password Protection Agent is installed.

You can use the following PowerShell commands to find the Password Protection Proxy:

$SCP = "serviceConnectionPoint"
$Keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter {objectClass -eq $SCP -and keywords -like $Keywords }

It returns the server, and you can use ADSIEdit to inspect the computer:

Azure AD Password Protection Proxy SCP

This is much like how domain-joined Outlook clients find the Autodiscover SCP in Active Directory.

Installing the DC agent service

When the proxy service is installed and registered the Domain Controller agent service can be installed. It is just an MSI package that can be installed (using the GUI, accept license agreement and click install) or you can install it on the command line using the following command (use elevated privileges):

C:\> msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn

Note. Installation of the DC agent requires a restart, but you can use the /norestart switch to reboot at a more convenient time.

After rebooting the Domain Controller the password protection service is ready for use.

Some remarks:

  • Azure AD Password protection service requires an Azure AD Premium P1 or P2 license.
  • Domain Controllers should be Windows 2012 or higher.
  • Domain Controllers should have .NET Framework 4.5 or higher installed.
  • You never know which Domain Controller is going to process a password change. Therefore, the Password Protection service need to be installed on all Domain Controllers. For a straightforward environment this should not be a problem, but for large enterprises with lots of DC’s it can be an issue (I deliberately do not that about security officers at this point :-))
  • Both the proxy service and the DC agent support an in-place upgrade, so a newer version can be installed without uninstalling the old version.

Testing the Azure AD Password Protection service

So, after installing the Password Protection Proxy and the DC agent it’s time to test which is relatively simple. Logon to a domain-joined workstation, use CTRL-ALT-DELETE to change the password. When using a simple password like “Summer2019” or something it fails with the following error message.

Unable to update the password

From this moment on it is no longer possible to use weak passwords, locally enforced by Azure Active Directory and again a step closer to a safer environment.

Ignite 2018 – Azure AD and security sessions

A little later than originally planned because of an unexpected visit of the Massachusetts General Hospital in Boston on my way…. In my previous postings I blogged about the start of the conference and some of the Exchange sessions I attended in the first two days. Now how much I do love Exchange, most of my clients are moving towards Office 365 and Exchange Online, so what else is important here?

Yes, authentication! Azure Active Directory, Identity and Access Management and security around these solutions. And this happens to be important for Exchange and Exchange Online as well, so….

Secure access to Office 365/Azure Active Directory with new features in AD FS in Windows Server 2019 and Azure AD Password Protection

Sessions “BRK3226 – Secure access to Office 365/Azure Active Directory with new features in AD FS in Windows Server 2019 and Azure AD Password Protection” is all about authentication in Azure AD. It explains the traditional password hash sync as well as the ADFS options (more that 71 million users are actively using ADFS). But there are also 1.29 billion authentications blocked in August 2018 and 81% of all security breaches are because of weak, default or stolen passwords.

securing-resources

Common passwords used in (Azure) AD are Password, Spring, Summer, Autumn, Winter, 2018, 1234, your favorite football team etc. And these in turn are used in password spray attacks! Also vulnerable are passwords where number and letters are changed, for example “I” becomes “!”, “O” becomes “0” etc. And now you wonder, how many of my users are doing this? Password protection in Azure AD also includes normalization of the password, so these changes are automatically blocked. The good thing is, Azure AD password protection is coming to on-premises AD as well!

You can find the presentation on Youtube https://youtu.be/DC4cyF_JEgw and the presentation can be found here https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3226.pptx

Azure Active Directory best practices from around the world

The title of the session was renamed to “Azure AD: Do’s and Don’ts”, but this is a more ‘notes from the field’ session with a lot of practical information around Azure AD, legacy authentication, modern authentication, Hybrid Azure AD Joine (HAADJ, I hate 3 letter acronyms, let alone 5 letter versions 😊) and what to do to get a better and more safe authentication experience.

legacy-authentication

Interesting in this presentation is that is also discusses what step you need to take to move from legacy authentication to modern authentication, and also the pitfalls you might encounter, including links to more information (found in the presentation).

associating-devices

You can see the presentation on Youtube https://youtu.be/wGk0J4z90GI and you can find the presentation here https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3408.pptx

Scott Schnoll’s Exchange and Office 365 tips and tricks

I don’t know how many times Scott Schnoll has delivered this session, but it still is an awesome session and contains so much practical information around Exchange and nowadays Exchange Online.

scott-schnoll

I tried to make some pictures with Office Lens, but I think the color of the slides and text are not identified correctly so they are horrible. The slides aren’t available (yet), so you have to check the presentation on Youtube: https://youtu.be/0WNMX8EKYZk

Topics include anti-virus exclusions, DMARC enhancements, decommission on-premises Exchange in (or after) hybrid, changes to EOP IP ranges, migrating DL’s to Office 365 (including a script to do so), a license administrator in Office 365 (preview), DLP and credit card numbers and Mail Flow Insights, a new tool/dashboard that is currently being developed. Scott is doing a demo on this at the end of his presentation. Very cool, very promising, very useful!

Summary

So, after 5 days (well, four and a half days) we can say it was a very successful event. It is so huge, approx. 30,000 attendees from 5,000 organizations. So many sessions, break-out, theatre, workshop, hands-on, almost too much. And the sheer size of the location, I guess one can walk between 6 and 7 miles every day between the various locations. Would I go again? Sure, next year, again in Orlando, November 4-8. Hope to see you there!

More information/sessions

And some more interesting sessions to view online….

BRK2407 – Windows 10 and Office 365 ProPlus lifecycle and servicing update (CONDENSED)

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK2407.pptx  https://youtu.be/t9Bs55czc1E

BRK3234 – An IT pros guide to Open ID Connect, OAuth 2.0 with the V1 and V2 Azure Active Directory endpoints (very informative, but not available online yet I’m afraid)

BRK3397 – Protect and control your sensitive emails with Office 365 Message Encryption

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3397.pptx

https://youtu.be/Ld4b4pFua0g

BRK3408 – Azure Active Directory best practices from around the world

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3226.pptx

https://youtu.be/wGk0J4z90GI

BRK3146 – What’s amazing and new in calendaring in Outlook!

https://youtu.be/-ZrNTylawOA

THR3024 – How to add MFA to your Exchange Online/on-premises mailboxes in 20 minutes or less

https://youtu.be/7hoEmEwV8Rk

BRK3081 – Implementing a modern network architecture to get the most out of Office 365

https://youtu.be/FGMzS_MjuPY

BRK3145 – Deploying Outlook mobile securely in the enterprise

https://youtu.be/4mHlxdJMh1Q

THR3036 – Azure Active Directory hybrid identity and banned password detection

https://youtu.be/kuVkfIiapI4

 

 

 

Office 365 Directory Synchronization without Exchange server

I get a lot of questions regarding Office 365, Directory Synchronization from an on-premises Active Directory and decommissioning Exchange servers on-premises. A lot of customers want an Active Directory on-premises, they want Mailboxes in Office 365 and they don’t want an Exchange server on-premises anymore.

So the question is basically “Can we decommission our Exchange servers after moving to Office 365?”

It is an easy question with an easy answer, and the answer is “No, you cannot decommission your last Exchange server on-premises”. Let me explain why.

Source of authority

In an earlier blogpost I already discussed the three types of Identities:

  • Cloud Identities.
  • Synced Identities.
  • Federated Identities.

With Directory Synchronization (through Azure AD Connect) in place we’re talking about Synced Identities or Federated Identities. Important to note is that the Source of Authority, which means where the identities are managed, is the on-premises Active Directory. Account are created and managed on-premises and not in the cloud. This is also true for properties of the accounts.

Suppose we have the following situation. There’s an Active Directory environment, no Exchange servers on-premises and there’s an AADConnect server for replication purposes to Azure Active Directory as shown in the following picture.

image

Figure 1. Azure AD Connect is synchronizing user accounts to Office 365.

The internal domain is Exchangelabs.local, the external domain Exchangelabs.nl is only verified in Office 365 and set as the default domain. In the on-premises Active Directory there’s an OU=Accounts where objects are in various OU’s like OU=Groups, OU=Users, OU=Contacts etc.

image

Figure 2. User accounts in Active Directory Users and Computers. Please note the different settings in the E-mail Address column.

The installation of Azure AD Connect automatically detects that there’s no Exchange server installed (the Active Directory Schema is not even prepared, so it’s truly a green-field Active Directory) and thus the Exchange Hybrid option is not available in the setup application:

image

Figure 3. Azure AD Connect is configured with Password hash synchronization

The only option that’s selected is the Password hash synchronization. The Organizational Unit OU=Accounts as mentioned before is the only OU that’s selected for object replication, so after finishing the setup application and the initial synchronization the user account will appear in the Microsoft Online Portal.

When the Office 365 (E3) licenses are assigned to the replicated user accounts, one strange thing is visible. The user account is exactly as expected, i.e. bwesselius@exchangelabs.nl, but the primary SMTP address does not reflect this, and is actually based on the tenant name, i.e. bwesselius@exchangelabsnl.onmicrosoft.com as shown in the following screenshot.

image

Figure 4. User’s email address is set incorrectly. The tenant email address is set as primary SMTP address.

When you want to change the email address from the tenant email address to the regular email address you’ll see the following warning:

image

Figure 5. It is not possible to change the user’s primary SMTP address

The Set as Primary button is greyed out, so it’s not possible to change the email address.

When you try this in the Exchange Admin Center (in Exchange Online) it doesn’t work either and you get the following error message:

The operation on mailbox “Bram Wesselius” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Bram Wesselius’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

image

Figure 6. An error message about ‘write scope’ is shown when the user’s Email address is changed.

Now it gets interesting. Have a closer look at Figure 2. You will see that user BWesselius does not have an email address set in Active Directory, but user Ahaverkamp does have an email address. This is not an Exchange email address (since Exchange is not installed on-premises, Active Directory doesn’t have the Exchange schema changes applied, it really is a green-field Active Directory) but the email address is set in Active Directory Users and Computers.

image

Figure 7. The user’s Email address is set in Active Directory Users and Computers.

When the Email address is set using Active Directory Users and Computers it is synchronized correctly to Office 365 and used in Exchange Online as the user’s primary Email address.

So, now we know how to set the primary Email address when the user is provisioned in the on-premises Active Directory. Despite the fact the user now has the correct primary Email address, it is still not possible to change the user’s Email address in the Office 365 portal or Exchange (online) Admin Center.

This behavior is caused by the fact that the account in this scenario is a Synced Account. The source of authority is the on-premises Active Directory, and this is where all changes need to be made. Once changed the new settings are synchronized to Office 365.

So, to change the primary Email address for user BWesselius it’s a matter of adding the Email address to the mail property in Active Directory users and computers and wait for synchronization to happen (or force directory synchronization). If you want to change an Email address, for example for user AHaverkamp you can just change the mail property of the user in Active Directory Users and Computers.

image

So, now we know how to create a user in the on-premises Active Directory and have the Exchange Online primary Email address set correctly. In my next blog I’ll talk more about an on-premises Exchange server.

Hosted Exchange 2013

Almost two years ago I wrote a couple of blog posts regarding Hosted Exchange 2010 SP2 (or later):

When building Hosted Exchange 2013 things are not very different. You have to prepare Active Directory for hosting purposes and set the permissions in Active Directory on OU level. When it comes to Exchange 2013 itself, address list segregation is still achieved by using Address Book Policies. One thing that is fundamentally different is SMTP routing in a hosted Exchange. In Exchange 2010 3rd party Routing Agents were used, but in Exchange 2013 there’s an Address Book Policy Routing agent that respects the Address Book Policies that are provisioned for every tenant. Continue reading Hosted Exchange 2013

Building Hosted Exchange – Part II

In my previous blog post I tried to explain why Microsoft is following the partner model for hosted environment. If you fully understand the Microsoft guidance document and really want to build it yourself instead of using a 3rd party Control Panel vendor (which I always recommend) I’ll try to outline the various steps that need to be done.

Please note that this blog post is published ‘as is’ and is my personal belief on how stuff can be done. You still have to test everything in a lab environment before building things in production. I cannot, will not nor take any responsibility about your environment when things go wrong!

Continue reading Building Hosted Exchange – Part II