I was a guest on the 425Show talking Active Directory with Daniel Stefaniak

Yesterday, I spent some time talking with Daniel Stefaniak about Active Directory. Daniel is one of the hosts of the 425Show, so we decided to record  and publicly share an hour of our regular 'Old guys yelling at cloud' discussions for this show.

 

About the 425Show

The 425Show is a Twitch live stream, run by the Microsoft Identity Developer Advocacy crew. Christos Matskas, Stefan van der Wiele and Daniel Stefaniak run this show. Their goal is to provide two livestreams per week at 10 AM ET. Of course, this is 4PM in Europe, hence the name.

When Daniel asked me to join, I didn't hesitate and immediately sais 'Yes'. We found a time slot that suited both of us and just made it work.

 

Topics

This episode of the 425Show contains our usual banter. If you're looking for some specific tidbits, tune into the following timeframes:

02:11 – 04:48 Introduction
04:48 – 10:31 Active Directory licensing explained
10:32 – 14:51 What's New in AD DS in Windows Server 2008
14:52 – 15:38 Active Directory Functional Levels
15:39 – 18:37 Backup and Restore tests as part of AD projects
18:38 – 21:11 Automating AD changes and rotating krbtgt secrets
21:12 – 24:32 Ungooglable Legacy documentation
24:33 – 27:02 Active Directory Horror Stories
27:03 – 30:58 Learning from books
20:59 – 33:33 Good consultants vs. lazy consultants
33:34 – 34:41 Microsoft Certified Masters
34:42 – 37:02 Active Directory, so lonely
37:03 – 39:20 AD Scalability vs. Azure AD
39:21 – 40:09 KDCProxy
40:10 – 41:44 The logic behind .local domain names
41:45 – 42:30 DNS, typo or PKI?
42:31 – .44:00 Active Directory and KQL
44:01 – 47:04 Krbtgt revisited, with repadmin
47:04 – 47:37 Did Daniel just stop talking there!?
47:38 – 51:45 Active Directory Replication and going back in time
51:46 – 52:21 Linked value replication (LVR) in Windows Server 2003
52:22 – 53:19 Amazed at how Active Directory still keeps running
53:20 – 59:19 Dynamic Access Control and Kerberos Armoring
59:20 – 60:03 Active Directory in Windows Server 2022
60:04 – 62:26 From Functional Levels to Star Trek
62:27 – 64:50 LDAP Pings, DCLocator and other things that might not work as expected
64:51 – 66:43 Nerding out on cloudy things
66:40 – 68:40 Password filters, LSASS crashes and analyzing memory dumps
68:40 – 70:33 Concluding

0  

HOWTO: Determine if you can remove SQL Server Express after uninstalling Azure AD Connect

Azure AD Connect

When you uninstall Azure AD Connect, you are presented with the below screen. This screen provides an option to uninstall the following supporting components:

  • Microsoft SQL Server 2012 Command Line Utilities
  • Microsoft SQL Server 2012 Native Client
  • Microsoft SQL Server 2012 Express LocalDB

Also uninstall supporting components? (Click for original screenshot)

 

Azure AD Connect comes with a SQL Server Express LocalDB installation to store its ADSync database. In its database, Azure AD Connect stores the configuration of its connectors, its connector spaces and its metaverse.

These components are installed with Azure AD Connect, unless you’ve specified to Use an existing SQL Server on the Install required components screen, when installing Azure AD Connect using Customize settings.

When SQL Server Express is not used for anything else than storing the ADSync database, SQL Server Express LocalDB and its tools and native client can be uninstalled together with Azure AD Connect.

 

Determining the SQL Server Express databases

To determine if SQL Server Express LocalDB can be uninstalled together with Azure AD Connect, we need to determine the SQL Server Express LocalDB databases instances that are running.

Note:
We don’t need to install the Microsoft SQL Server Management Studio (SSMS) on the Windows Server running Azure AD Connect to get the required information.

We can use the following line in a Command Prompt (cmd.exe) window:

sqllocaldb info

The above command provides the databases running on the Azure AD Connect installation. If only Azure AD Connect uses a SQL Server Express, you’d expect the following databases:

  • .\ADSync
  • v11.x

The .\ADSync database is the database instance we’d expect from Azure AD Connect.

The v11.x database is a database instance is an automatic Microsoft SQL Server Express LocalDB instance that comes with the installation of Microsoft SQL Server Express LocalDB.

If additional database instances are returned, then SQL Server Express LocalDB is in use by an additional program on the Windows Server. Do not uninstall the additional components in this case.

 

Concluding

Uninstalling Azure AD Connect can throw you a curve ball now and then. Be sure you make the right choices.

0  

KnowledgeBase: You cannot uninstall Azure AD Connect from Programs and Features

Azure AD Connect

Sometimes, the configuration of Azure AD Connect goes wrong and stops. Azure AD Connect can end up in a state where you can no longer recover. Alas, in these cases uninstallation may also not be an option… or so it seems.

 

The situation

Azure AD Connect is installed on a Windows Server installation, but not configured or unable to resume configuration.

Admins now want to remove Azure AD Connect.

From the Start Menu the Add or remove programs item is searched and selected, or from the Start right-click menu (Start + X) the Apps and features menu option is chosen.

In the Apps & features window of Settings, the Microsoft Azure AD Connect item is selected. The button Uninstall is pressed.

In the This app and its related info will be uninstalled. pop-up, the button Uninstall is also pressed.

 

The issue

The following error appears:

Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item. (click for original screenshot)

Windows states it cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

 

The cause

The uninstallation option for Azure AD Connect in the Add & Features screen is broken.

 

The solution

You can uninstall Azure AD Connect using the right uninstaller.

The information we need can be gathered by issuing the following command line:

wmic.exe product

For the Microsoft Azure AD Connect product, you’ll see a *.msi file listed in the LocalPackage column. This file is located in the C:\Windows\Installer\ folder.

Perform the following steps:

  • Double-click the *.msi file.

Welcome to the Microsoft Azure AD Connect Setup Wizard

  • Click Next on the Welcome to the Microsoft Azure AD Connect Setup Wizard page of the Microsoft Azure AD Connect Setup wizard.
  • Click Remove on the Change, repair or remove page of the wizard.
  • Click Remove on the Ready to remove Microsoft Azure AD Connect page of the wizard.
    The Microsoft Azure Active Directory Connect appears.
  • Click Remove. to also uninstall the Azure AD Sync Engine, Microsoft SQL Server 2012 Command Line Utilities, Microsoft SQL Server 2012 Native Client and Microsoft SQL Server 2012 Express LocalDB.
  • Click Exit when uninstallation is completed.

 

Concluding

After Azure AD Connect is correctly removed from the Windows Server, you can start installation and configuration of Azure AD Connect from scratch, or decide to install Azure AD Connect on another Windows Server installation.

If your goal is to get rid of Azure AD Connect, then you’ve completed your goal.

0  

Exam SC-300: Microsoft Identity and Access Administrator is now available

Exam SC-300: Microsoft Identity and Access Administrator

After a period of rigorous beta testing, exam SC-300: Microsoft Identity and Access Administrator is now available for admins worldwide to show off their knowledge of Azure Active Directory. With the beta scores pouring in this week, this exam is ready for prime time!

What is an Identity and Access Administrator?

The Microsoft Identity and Access Administrator designs, implements, and operates an organization’s identity and access management systems by using Azure AD. They manage tasks such as providing secure authentication and authorization access to enterprise applications. The administrator provides seamless experiences and self-service management capabilities for all users. Adaptive access and governance are core elements to the role. This role is also responsible for troubleshooting, monitoring, and reporting for the identity and access environment.

The Identity and Access Administrator may be a single individual or a member of a larger team. This role collaborates with many other roles in the organization to drive strategic identity projects to modernize identity solutions, to implement hybrid identity solutions, and to implement identity governance.

About Exam SC-300

Exam SC-300: Microsoft Identity and Access Administrator measures your ability to accomplish the following technical tasks:

You can download the full exam skills outline here.

When you pass exam SC-300: Microsoft Identity and Access Administrator, you earn the Microsoft Certified: Identity and Access Administrator Associate certification.

Concluding

Are you looking to prove your Azure AD and cloud Identity chops? Ace this exam, earn the certification and flaunt with your accomplishments on social media!

Are you looking to hire people who have the skills of Identity and Access Administrator? Hire someone with the Microsoft Certified: Identity and Access Administrator Associate certification.

Further reading

Introducing Microsoft’s New Security Certifications 
Exam SC-300: Microsoft Identity and Access Administrator 
Microsoft Certified: Identity and Access Administrator Associate

0  

KnowledgeBase: You cannot manage the Desktop SSO feature with the Hybrid Identity Administrator role

Azure AD Connect

On March 19th, 2021, Microsoft introduced Azure AD Connect version 1.6.2.4 to incorporate the lessons learned and distribute the fixes Microsoft made to the larger public. As part of its version release history, Microsoft added the following line to the release notes for this version:

Azure AD Connect now supports the Hybrid Identity Administrator role for configuring the service.

Alas, this line applies to all but one implementation scenario.

 

The situation

You implement Azure AD Connect with the Enable seamless single sign-on option enabled, or you implement an additional Azure AD Connect installation towards an Azure AD tenant that has this option enabled.

On the Connect to Azure AD page of the the Microsoft Azure Active Directory Connect wizard, you specify an account that has the Hybrid Identity administrator role assigned, but not the Global administrator role.

The Enable seamless single sign-on option enables the Desktop Single Sign-on (DSSO) feature.

 

The issue

On the Enable single sign-on page of the Microsoft Azure Active Directory Connect wizard, you encounter an Cannot retrieve single sign-on status. error:

Error "Cannot retrieve single sign-on status." on the Enable single sign-on page of the Microsoft Azure Active Directory Connect wizard (click for original screenshot)

This error prevents you from continuing to configure Azure AD Connect.

In the Event viewer (eventvwr.exe) you additionally encounter an error:

Event ID 0 with source Azure AD Connect Authentication Agent (click for original screenshot)

The error with EventID 0 and source Azure AD Connect Authentication Agent provides the following information:

Connector registration failed: Make sure you are a Global Administrator of your Active Directory to register the Connector. Error: ‘“The registration request was denied. Details: User is unauthorized.”’

 

The cause

This error occurs because managing the Desktop SSO feature is not supported with the Hybrid Identity Administrator role.

 

The solution

The Desktop SSO feature can currently only be managed using an account with the Global Administrator role.

Press the Previous button in the Microsoft Azure Active Directory Connect wizard until you reach the Connect to Azure AD page again. Alternatively, you can click on the Connect to Azure AD node in the left navigation menu.

Enter the credentials of an account with the Global administrator role assigned on this page. Continue the wizard again, but this time with success.

 

Concluding

Following Microsoft’s recommended practices for using least privileged roles to accomplish administrative tasks proved troublesome yesterday.

In Azure Active Directory, Microsoft can fix things overnight. I’m sure this issue will be fixed in the coming months. In the meanwhile, please be advised to use an account with the Global administrator role assigned when managing Desktop SSO.

 

Safari HatHat Tip

My SCCT colleague Rob Bethbeder brought this issue to my attention.

0  

HOWTO: Get an overview of the Privileged roles assigned within an Azure AD tenant

Unless you’re using the Azure AD Privileged Identity Management (PIM) portal features from your tenant’s Azure AD Premium P2 licenses, you might have a hard time to get an overview of the Privileged roles assigned within an Azure AD tenant.

There is, however, a free, easy and Microsoft-supported way, using the AzureADIncidentResponse Windows PowerShell module.

Getting ready

First, we need to install the Windows PowerShell modules we need. Perform the following lines of Windows PowerShell in an elevated Windows PowerShell session:

Install-Module AzureAD -Force

Install-Module MSOnline -Force

Install-PackageProvider NuGet -Force

Install-Module PowerShellGet -Force

&(Get-Process -Id $pid).Path -Command { Install-Module MSAL.PS }

Install-Module AzureADIncidentResponse

 

Note:
We need to install both the AzureAD and MSOnline modules, as the output of these modules differs. This is the state of Azure AD PowerShell today. The above lines update the PowerShell modules, if you don’t run the latest versions.

Note:
If you receive error ‘Unable to download’ when you try to install the AzureAD or MSOnline PowerShell Module, use these steps to resolve the situation.

Getting Azure AD Privileged roles

Microsoft shared its Azure AD Incident Response Windows PowerShell module on the PowerShell Gallery. Using the cmdlets in this Windows PowerShell module, we can easily get an overview of the Privileged roles assigned within an Azure AD tenant.

Run the following lines of Windows PowerShell to do so:

Import-Module AzureADIncidentResponse

Connect-AzureADIR <YourTenantId>

Sign in with an account with sufficient permissions to read privileged roles within your Azure AD tenant. By default, any user account and guest account can be used, unless account enumeration is disabled in Azure Active Directory. By default, any guest user account can be used, unless their permissions have been restricted.

Get-AzureADIRPrivilegedRoleAssignment <YourTenantId> | Out-GridView

These lines of Windows PowerShell result in a GridView window displaying the DirectoryRole containing the privileged role assignment and its DirectoryRoleObjectId. Per role, the RoleMemberName, RoleMemberObjectType (typically User or ServicePrinicpal), RoleMemberUPN and RoleMemberObjectId are displayed. The RoleMemberEnabled column provides information on the status of the role assignment. RoleMemberMail and RoleMemberAlternateEmail can be used to contact a privileged user if need be. Finally, RoleMemberOnPremDn provides the distinguished name (DN) attribute for the privileged user, if the user is synchronized from on-premises.

This information is presented per privileged role. If a user or service principal has multiple roles, multiple lines indicate these role memberships.

The information can be used to:

  • Get a quick overview of privileged users, even if the Azure AD tenant uses Azure AD free licenses.
  • Seek out dangerous service principals with privileged roles.

Concluding

While initially conceived as an incident response tool, the Azure AD Incident Response Windows PowerShell module proves useful for many other investigations.

0  

HOWTO: Enable Seamless Single Sign-on when AD FS is Configured as Sign-in Method

Azure AD Connect

Microsoft has introduced the Staged Rollout functionality to convert the sign-in method for people in your organization from federated authentication to managed authentication. However, there is one slight issue with single sign-on. In this blogpost, I’ll address the issue of having both Seamless Single Sign-on and Federation enabled in Azure AD Connect.

About Staged Rollout

Staged Rollout is a feature that allows organizations to transition the sign-in method for people in the organization based on membership to a group. Without the Staged Rollout feature, this transition is only possible per DNS domain name.

When made members of the group that would convert their sign-in method, people would sign in to Azure AD and Azure AD-integrated applications, services and systems using either password hash synchronization (PHS) or Pass-through Authentication (PTA).

The issue

When people sign in using PHS or PTA, they loose their ability to get access based on single sign-on (SSO) in certain scenarios.

These scenarios include:

  1. Not using a hybrid Azure AD-joined device
  2. Not using an Azure AD-joined device

In these cases, the Microsoft documentation refers to using the Enable single sign-on option in Azure AD Connect. This option enables the Desktop Single Sign-on feature. When the feature is enabled, people in your organization are allowed to perform Kerberos authentication towards the Azure AD sign-in infrastructure.

The Desktop SSO feature creates a computer object named AZUREADSSOACC in the default Computers container per Active Directory forest that is enabled for Desktop SSO. Its password is specifically used to encrypt the Kerberos tokens that are exchanged.

However, when you have Federation with AD FS configured in Azure AD Connect, you cannot enable the Enable single sign-on option at the same time. The option is greyed-out:

The Enable single sign-on option is greyed out in Azure AD Connect when Federation with AD FS is enabled (click for original sceenshot)

Enabling the Desktop Single Sign-on feature

To enable the Desktop Single Sign-on feature, close the Azure AD Connect configuration wizard and open an elevated Windows PowerShell window. Perform the following lines of Windows PowerShell:

Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1’

New-AzureADSSOAuthenticationContext

A modern authentication prompt appears. Sign-in with an account that has been assigned the Global Administrator and/or the Hybrid Identity Administrator role in the Azure AD tenant.

Enable-AzureADSSOForest

A Windows authentication prompt appears. Sign-in with an account that is a member of the Enterprise Admins group in the Active Directory forest for which you want to enable the Desktop SSO feature. Specify the account name in the sAMAccountName format.

Repeat this step for every Active Directory forest you want to enable the Desktop Single Sign-on feature for.

Enable-AzureADSSO -Enable $true

Checking the Desktop Single Sign-on feature

There are two ways to check the Desktop Single Sign-on feature.

You can run the following line of Windows PowerShell in the same Windows PowerShell session you used to enable the Desktop Single Sign-on feature:

Get-AzureADSSOStatus | ConvertFrom-Json

  

You can check the existence of the AZUREADSSOACC computer account in the default Computers container in the Active Directory forest.

You can start the Azure AD Connect Configuration wizard and examine the output for the Change Sign-in method task.

Further steps

after the initial configuration of the Desktop Seamless Single Sign-on (DSSO) feature, you’re ready to:

  1. Create the process for changing the password for the AZUREADSSOACC computer account on a monthly basis
  2. Deploy a Group Policy to place https://autologon.microsoftazuread-sso.com in the Intranet Zone to allow people to actually send Kerberos tokens to the Azure AD Authentication infrastructure
  3. Create and assign groups for Staged Roll-out and make people members of these groups.

Have fun!

0  

Availability of Azure AD Connect’s v2 endpoint

Azure AD Connect

For the past year, Microsoft has been offering the new ‘version 2’ endpoint for Azure AD Connect. This endpoint replaces the ‘version 1’ endpoint we’ve come to use ever since DirSync.

About Azure AD Connect’s v2 endpoint

Microsoft has deployed a new endpoint (API) for Azure AD Connect that improves the performance of the synchronization service operations to Azure Active Directory. We reported on the Public Preview availability of this v2 endpoint roughly a year ago.

When organizations use the new v2 endpoint, they'll experience noticeable performance gains on exports and imports to Azure AD. This new endpoint supports the following scenarios:

  • Syncing groups with up to 250,000 members
  • Performance gains on export and import to Azure AD

Availability of the v2 endpoint

The new v2 endpoint was announced generally available for Azure AD Connect installations connecting for tenants in the global Azure AD service on January 14th, 2021.

On April 16th, 2021, The Azure AD Connect’s v2 endpoint was announced generally available for:

  • Azure China cloud
  • Azure US Government cloud

Azure AD Connect’s v2 endpoint will not be made available in the Azure Germany cloud.

Concluding

While T-Systems still runs the Azure Germany cloud, Microsoft has not been accepting new organizations or deploying new features and services to the Germany locations. Instead, Microsoft has launched two new datacenter regions in Germany.

Currently, the Azure Germany cloud will be closing on October 29th, 2021. Now, the non-availability of Azure AD Connect’s v2 endpoint, and as a result non-standard upgrades to Azure AD Connect versions beyond version 1.6.2.4, is the first big hurdle organizations using Azure Germany face.

Further reading

Azure AD Connect version 1.6.2.4 defaults to the v2 endpoint  
Azure AD Connect’s v2 endpoint is now Generally Available (GA) 
HOWTO: Tell if Azure AD Connect is using the v2 Endpoint 
HOWTO: Use Azure AD Connect’s v2 Endpoint

0  

KnowledgeBase: A Sign-in Window appears while configuring Azure AD Connect and configuration fails

Azure AD Connect

Sometimes, the installation of Azure AD Connect can mess up your project deadlines in mere seconds. In this blogpost, I want to share an error that kept the admins of an organization occupied for several days, while it was easy to fix.

 

The situation

An organization uses Azure AD and Azure AD Connect.

After configuration of the initial Azure AD Connect installation, the organization has embraced Microsoft’s Azure identity & access security best practices.

An admin wants to configure an additional Azure AD Connect installation in Staging Mode. He downloads Azure AD Connect, and runs it. The admin configures Azure AD Connect correctly and presses the Install button on the Ready to Configure screen.

 

The issue

During configuration, a modern authentication prompt appears:

A sign-in window appears while configuring Azure AD Connect (click for original screenshot)

The account and its password are unknown. However, the account name contains the name of the Windows Server installation on which Azure AD Connect is newly configured.

The only option is to dismiss the authentication prompt. When the authentication prompt is dismissed, configuration fails.

In the trace file, located in the C:\ProgramData\AADConnect folder, the following lines can be found:

Caught exception while creating azure service account.

An error occurred while creating the synchronization service account in Azure AD. The error was: Unable to create the synchronization service account for Azure Active Directory.  Retrying this operation may help resolve the issue.

In Event viewer (eventvwr.exe), Event ID 906 is logged:

EventID 906: GetSecurityToken: unable to retrieve a security token for the provisioning web service (click for original screenshot)

This event provides information on the failure:

GetSecurityToken: unable to retrieve a security token for the provisioning web service (AWS).

Note:
The endpoint for Azure AD Connect is not hosted on Amazon AWS. AWS is the Microsoft internal abbreviation for its Azure AD Connect provisioning web service.

 

The cause

Azure AD Connect creates a new account in Azure AD. This account acts as the Azure AD service account. The new account is subject to a Conditional Access policy.

 

The solution

Do not cancel the Azure AD Connect configuration wizard. Instead, remedy the Conditional Access policy. When requiring multi-factor authentication or other grant requirements in Azure AD Conditional Access policies, exclude the Directory synchronization accounts role.

Wait a couple of minutes and press the Retry button. Azure AD Connect will be configured without the need to rerun through the entire wizard.

 

Concluding

My recommendation is to create a separate Conditional Access policy targeting the Directory synchronization accounts role and possible other service accounts that communicate with Azure (AD) endpoints.

Limit access by only allowing access from the egress/web proxy IP address(es) for the datacenter(s) your Azure AD Connect installations reside and/or you might want to setup Azure AD Connect installations (in times of need). Block all other locations.

0  

Azure AD Web Sign-in Security Feature Bypass Vulnerability (CVE-2021-27092, Important)

Today, for its April 2021 Patch Tuesday, Microsoft released an important security update for the Azure AD web sign-in feature in Windows and Windows Server. This vulnerability is known as CVE-2021-27092 and rated with CVSSv3.0 scores of 6.8/5.9.

About Azure AD Web Sign-in

Web Sign-in is a new way of signing into a Windows system. It enables Windows logon support for non-AD FS federated providers (e.g. SAML). Web sign-in enables you to set multifactor authentication before signing in to Windows. Web Sign-in is only supported on Azure AD Joined PCs.

About the vulnerability

An elevation of privilege vulnerability exists in the way Azure Active Directory web sign-in allows arbitrary browsing from the third-party endpoints used for federated authentication.

It allows an attacker with physical access to the device to gain unauthorized access.

DISCLOSURE

The vulnerability was responsibly disclosed to Microsoft.

AFFECTED OPERATING SYSTEMS

The following Operating Systems (OSs) are affected:

  • Windows 10, version 1803
  • Windows 10, version 1809
  • Windows 10, version 1909
  • Windows 10, version 2004
  • Windows 10, version 20H2
  • Windows Server 2019
  • Windows Server, version 1909
  • Windows Server, version 2004
  • Windows Server, version 20H2

The Web Sign-in feature was introduced with Windows 10, version 1809 and  does not affect other supported Operating Systems, like Windows Server 2012 and Windows Server 2016.

Recommendation

Azure AD-joined devices that have the Web sign-in feature enabled through the Authentication CSP, should be updated with the April 2021 Cumulative Update to prevent unauthorized access.

Further reading

Azure AD Web Sign-in Security Feature Bypass Vulnerability    
What's new in Windows 10, version 1809 – Web Sign-in

0