(2019-10-08) Synched Computers/Devices Being Cleaned Up From Azure AD

Starting with version 1.4.18.0 and higher of Azure AD Connect, you may see some or all of their Windows devices disappear from Azure AD after upgrade to that version and executing a sync cycle. This is not a cause for concern, as these device identities are not used by Azure AD during conditional access authorization. This change won’t delete any Windows devices that were correctly registered with Azure AD for Hybrid Azure AD Join.

If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised that the customer allow the deletions to go through. How To: allow deletes to flow when they exceed the deletion threshold

–

Nevertheless you may want to analyze the deletion first. You can read the following blog post to see how you could do that: (2019-10-06) Examining Pending Export Deletions In Azure AD Connect

–

More information about this can be found through Understanding Azure AD Connect 1.4.xx.x and device disappearance

–

To verify which devices in your AD are candidates to be deleted in Azure AD, you can use the following PowerShell script: Export Hybrid Azure AD join computer certificates report

This script generates a report about certificates stored in Active Directory Computer objects, specifically, certificates issued by the Hybrid Azure AD join feature. It checks the certificates present in the UserCertificate property of a Computer object in AD and, for each non-expired certificate present, validates if the certificate was issued for the Hybrid Azure AD join feature (i.e. Subject Name matches CN={ObjectGUID}). Before, Azure AD Connect would synchronize to Azure AD any Computer that contained at least one valid certificate but starting on Azure AD Connect version 1.4, the synchronization engine can identify Hybrid Azure AD join certificates and will ‘cloudfilter’ the computer object from synchronizing to Azure AD unless there’s a valid Hybrid Azure AD join certificate. Azure AD Devices that were already synchronized to AD but do not have a valid Hybrid Azure AD join certificate will be deleted by the sync engine as these will be filtered from being synched to Azure AD (CloudFiltered=TRUE).

–

Now this script works great! But….unfortunately it does not work correctly with an AD forest where you may have multiple AD domains. Besides that, there is a cosmetic issue. So, let’s start with the easy part!

–

The script allows you to specify the distinguished name of a single object or the distinguished name of an OU. However, if you want to query the complete AD domain instead of just a single OU, you may think that’s not possible. Nope, that’s still possible. The original writer of the script chose to name the variable “DN” for just a single object (computer) and “OU” when query for computers in an OU. This last one may mislead due to its chosen name. Nevertheless, instead of the DN of an OU, you can also specify the DN of a container or the DN of a domain.

–

In a single AD domain environment, this will work flawlessly. However, in a multiple AD domain environment it may not. Due to historic reasons many companies may still have AD forests with multiple AD domains for which it is not cost effective to consolidate. For example, if you have the AD forest COMPANY.COM, with the following AD domains: COMPANY.COM, CHILD1.COMPANY.COM and CHILD2.COMPANY.COM. If you are COMPANY.COM and you need to query for objects in CHILD1.COMPANY.COM through PowerShell while not specifying the server variable (as in this script), it will throw an error due to a so called redirection. To query for an object from another AD domain you need to also target a DC from that same AD domain. If you need to query multiple AD domains you will be dancing all over the place! Sometimes, there is no other way, but in this case there is! And what if you want to query the complete AD forest while having multiple AD domains? You can always query every individual AD domain, but wouldn’t it be nice to just perform a single AD query that targets the complete AD forest? That is also possible!

When querying AD, especially when having an AD forest with multiple AD domains you always need to think about: (1) is all the data in my LDAP filter in the global catalog or not?, and (2) is the data that I’m looking for in the global catalog?

Then you need to ask yourself: “where to start searching?”. The closer to the objects you want, the better!

Rest assured! All domains objects are in the global catalog! The question is: “which attribute values of those objects are also replicated to the global catalog?”

Any attribute that has the property “isMemberOfPartialAttributeSet” set to “TRUE” also replicates its value(s) to all global catalogs in the AD forest. To find all the attributes in the AD schema for which its value(s) replicate to the global catalog, you can have a look at the following blog post (2015-01-05) Finding Attributes Marked As Members Of Partial Attribute Set (PAS). It has examples with ADFIND, PowerShell and ADSI.

–

Now looking at this script, the attribute of interest is “userCertificate”.

To see if an attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=<LDAP DisplayName>))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

–

To see if the “userCertificate” attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=userCertificate))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

Figure 1: Partial Schema Info Of The “userCertificate” Attribute

–

Or you could visit https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac, which will show you

Figure 2: AD Schema Definition Of The “userCertificate” Attribute

–

Guess what?! It does replicate to the global catalog! So, in this case the answer to both questions above is “YES”, therefore we can use the global catalog to perform this query

–

When you need to query the AD forest, you could start searching in the forest root AD domain and hopefully the client you are using supports Referral Chasing. If it does not, it may throw an error telling you it does not support it, or it just does not do anything. Wouldn’t it be nice to have something represent the AD forest? well, there is something like that, which is called a Phantom Root and it is specified by just 2 quotes and you can only use it when querying against the Global Catalog!

–

Now for all this to work, some adjustments are needed in the original script! I’ll guide you through that to get a new working script.

–

First things first. Download the PowerShell script: Export Hybrid Azure AD join computer certificates report 

–

Replace…

.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -OU ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose

…with

.EXAMPLE
    Looking at a specific computer

   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
    Looking at computer objects within a specific OU
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD domain
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘DC=child,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD forest
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN PhantomRoot -Filename "MyHybridAzureADjoinReport.csv" -Verbose

–

Replace…

Param
(
    # Computer DistinguishedName
    [Parameter(ParameterSetName=’SingleObject’,
               Mandatory=$true,
                ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # AD OrganizationalUnit
    [Parameter(ParameterSetName=’MultipleObjects’,
               Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $OU,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename

)

…with

Param
(
    # DistinguishedName of computer, OU, or domain
    [Parameter(Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename
)

–

Replace…

# Read AD object(s)
If ($PSCmdlet.ParameterSetName -eq ‘SingleObject’)
{
    $directoryObjs = @(Get-ADObject $DN -Properties UserCertificate)
     Write-Verbose "Starting report for a single object ‘$DN’"
}
Else
{
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $OU -Properties UserCertificate
    Write-Verbose "Starting report for $($directoryObjs.Count) computer objects in OU ‘$OU’"
}

…with

# Retrieve Object Type Of DN
If ($DN -ne "PhantomRoot")
{
    $objectType = (Get-ADObject -LDAPFilter "(distinguishedname=$DN)").objectClass # Do not use Get-ADObject $DN as it will throw an error if the object does not exist (even with ErrorAction defined)!
}
Else
{
    $objectType = "forestDNS" # Madeup, not for real!
    $DN = ""
}

   
# Read AD object(s)
If ($objectType -eq "computer")
{
    $domainFQDN = $($DN.SubString($DN.IndexOf(",DC=") + 1)).Replace(",DC=",".").Replace("DC=","")
    $directoryObjs = @(Get-ADObject $DN -Properties userCertificate -Server $domainFQDN)
}
ElseIf ($objectType -eq "domainDNS" -Or $objectType -eq "organizationalUnit" -Or $objectType -eq "container" -Or $objectType -eq "forestDNS")
{
    $gcFQDN = $(Get-ADDomainController -Discover -Service GlobalCatalog).HostName[0]
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $DN -Properties userCertificate -Server $gcFQDN`:3268
}
Else{
    Write-Host "Specified DN ‘$DN’" -Foregroundcolor Red
    Write-Host "Incorrect object type of specified DN or DN does not exist!" -Foregroundcolor Red
    Write-Host "Aborting Script…" -Foregroundcolor Red
   
    EXIT
}

–

UPDATE 2019-10-12: or get the updated version of the script from here

–

Hopefully this works for you in your AD environment!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-