AccountExpire is not synchronized by AAD Connect

I see, that a lot of people has some pain to synchronized the Account Expiry from on-premises Active Directory to Azure AD using AAD Connect.

There are two or more requests on this topic:

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/31459621-sync-account-expired-useraccountcontrol-to-azure

and

https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/17643847-active-directory-accountexpires-attribute-does-not

The reason for this is, that AAD Connect picks up changes from the on-prem AD and the AccountExpires attribute is a static attribute, where you can configure a dateTime (as ticks), when the account should expire. If this date is reached then the account is expired, but there is no change on the object itself. As we know, AAD Connect works state based, this means, AAD Connect picks up changes using the DirSyncControl. Since there is no change on the object, because the configured date on the object itself is static date and this date is reached, there is no change to pick up by AAD Connect. This is the reason, why AAD Connect can’t sync this change.

There are some documented workarounds, but these either requires a script that runs regularly (at least once a day) as mentioned here:

https://docs.microsoft.com/en-us/archive/blogs/undocumentedfeatures/use-aad-connect-to-disable-accounts-with-expired-on-premises-passwords

or the other solution, what required to run the full sync run profile on the on-prem AD Connector at least once a day:

https://myserverissick.com/2019/01/how-to-make-azure-ad-connect-disable-expired-accounts/

I think, that the best solution for this issue is to add a new connector (management agent), where this agent can calculate and populate this value. I’ll evaluate this option and will publish here soon……

Happy Troubleshooting!

Category: AAD Connect, AccountExpires | Comments Off

January 28

Run profiles

Import

read data from the connected data source and store in Connector space (kind of mirroring) . This can be delta or full. Delta imports only the changes since the last successfully finished delta import. Full imports all of the objects (in scope).

Please keep in mind, that confidential attributes won’t be imported by AAD Connect, since these are protected attributes:

https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential

the important message is:

“Active Directory performs a read access check on an object in the following cases:

When you evaluate whether the object matches the search filter.
When you return attributes of an object that match the search filter. By default, only administrators have CONTROL_ACCESS permissions to all objects. Therefore, only Administrators can read confidential attributes. Administrators may delegate these permissions to any user or to any group.”

from:https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential

If a deny ACL is applied on an attribute or on the object for the AAD Connect connector account, then AAD Connect won’t import the object or attribute as well.

Synchronization:

Calculation of the changes based on the configured synchronization rules. The inbound and outbound rules will be applied in this step:

source connector space object = inbound rules => metaverse object = outbound synchronization rules => destination connector space (object)

This step can be also delta or full. Delta means, that only the imported changes (see delta import) will be processed.

During the full synchronization all inbound and outbound synchronization rules will be applied again. The changes will be stored in the destination connector space and the state of the destination object will be pending export (can be add, modify or delete).

Export:

Only this steps touches the destination connected data source. The calculated changes will be exported to the destination. In case of AAD Connect this is Azure AD.

Happy Troubleshooting!

Category: AAD Connect, Logical processes | Comments Off

January 28

Logical Parts of AAD Connect

AAD Connect has following logical components:

Connected Data Source

Connector (aka Management Agent)

Connector Space

Metaverse

Connected Data Source – CDS

This is the system that keeps the data out side of AAD Connect. This can be either a source system or a target system. In case of AAD Connect default installation there are 2 CDS’s: on-premises Active Directory as source directory and Azure Active Directory as target system.

Connector (aka Management Agent)

This is a small peace of the sync engine, that keeps the connection to the connected data source. This imports and exports the data from and to the CDS. The imported data are scoped by Domain, organizationalUnits, objectTypes and attributes (in case of Active Directory). To be honest I do not like the name connector because this name has two meanings AAD Connect:

1. 1. Connector that keeps the connection to the connected data source (aka Management Agent)
  2. Connector: connectivity between metaverse object and connector space object

The connector has also some configurations: how to connect to the data source and run profiles.

Connector Space:

The connector (management agent) reads the objects from the connected data source and creates a local copy (a kind of cache). This local copy is stored in the connector space. This is a special area what contains a scoped / filtered objects from the connected data source. Each connector (management agent) has its own connector space.

Metaverse:

This is the central area of AAD Connect. This contains the calculated data. This means that the imported data from the connected data source are modified by the synchronization rules and the result ins stored in the metaverse.

Happy Troubelshooting!

Category: AAD Connect, Logical Components | Comments Off

January 28

What is the version of installed AAD Connect?

There are 2 ways to check the version of the installed AAD Connect:

Help => About

Start the AAD Connect synchronization console and look for the Menu Item Help, after click on about:

and the About window appears:

2. Installed Software

Click on start and type: appwiz.cpl

after you hit enter the Programs and Features control panel will appear:

as you can see there are 3 entries here:

1. 1. Microsoft Azure AD Connect => this is the AAD Connect Wizard
  2. Microsoft Azure AD Connect Health Agent for Sync => this is the health agent
  3. Microsoft Azure AD Connect synchronization services => this is the sync service itself

sometimes you will see different version for Microsoft Azure AD Connect and Microsoft Azure AD Connect synchronization services; this means that AAD Connect is upgraded but the upgrade is not yet run to upgrade Microsoft Azure AD Connect synchronization service.

Happy Troubleshooting!

Category: AAD Connect | Comments Off

January 27

History of AAD Connect

Is this true, that AAD Connect is older than 10 years?

The short answer is yes.

The longs answer is not that easy, look why:

Microsoft acquired tow companies based in Canada:

Linkage Software (LinkAge Directory Exchange LDE)

and

Zoomit Corporation (Via).

Based on these product the 1st release of the sync tool was born:

Microsoft Metadirectory Server

After this there are several rebrands:

Microsoft Metadirectory Server (MMS) (1999–2003)
Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS)
Microsoft Identity Integration Server 2003 Feature Pack (IIFP)
Microsoft Identity Lifecycle Manager Server 2007 (ILM)
Microsoft Forefront Identity Manager 2010 (FIM)
Microsoft Identity Manager 2016 (MIM)

There is no more public available information about: MMS, MIIS, IIFP or ILM.

Microsoft Forefront Identity Manager 2010 (FIM). There is still a version history page: https://social.technet.microsoft.com/wiki/contents/articles/2229.fim-2010-build-overview.aspx

There was small spin off of the product: SharePoint User Profile Synchronization

Based on FIM 2010 the 1st cloud sync tool: DirSync was published. This was quite similar to FIM 2010, where sync rules and provisioning extensions were present and the sync rules were configured in the management agent itself.

Some times later Azure AD Sync was released in 2014 with the version: 1.0.419.0911

see here:https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history-archive#104190911

This tool was then rebranded to the current name: AAD Connect in June 2015

see here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history-archive#1086410

And the big brother is still around: Microsoft Identity Manager 2016 (MIM) :

https://docs.microsoft.com/en-us/microsoft-identity-manager/microsoft-identity-manager-2016

MIM 2016 about

As we can see here, the about page contains some referrals to the older version “Microsoft Forefront Identity Manager 2010 R2”

Happy Troubleshooting!

Category: AAD Connect | 1 Comment