(2022-12-19) Ransomware And The Impact On Your Hybrid Identity Environment

For many years, organizations have been using Active Directory (AD) as their central on-premises identity directory service. Throughout those years many system and/or identity related configurations have been made to support different requirements. About just more than a decade ago Azure Active Directory (AAD) was officially released. For those organizations adopting AAD, something was needed to enable the so called hybrid identity environment consisting of AD on-premises and AAD in the cloud, in terms of authentication and identity provisioning and deprovisioning.

To support identity provisioning and deprovisioning in AAD using AD as the authoritative source, Microsoft offered the Windows Azure Active Directory connector for Forefront Identity Manager (FIM) and Microsoft Identity Manager (MIM). In addition DirSync was also offered, which was later replaced by Azure AD Sync, which was also replaced by Azure AD Connect (AADC). Today AADC is the tool to provision, and deprovision, users, groups and computers sourced from AD in AAD.

Not taking into account the order of offering, today to authenticate against AAD when having an hybrid identity environment, the following options exist, and can therefore be used:

1. Federated SSO
2. Pass-Through Authentication (PTA), with or without Seamless Sign-On
3. Password Hash Synchronization (PHS), with or without Seamless Sign-On

Now, the way to configure any of the available authentication mechanism, is through AADC wizard. The first option “Federated SSO” can be configured by yourself if you know what to do (which is not really difficult), or you can use the AADC wizard. For the last 2 options you must use the AADC wizard. The choice of an authentication method is done during the initial installation/configuration of AADC. Afterwards it is also possible to change the authentication method, and that can be done through the AADC wizard and changing the user sign-in.

Figure 1: Configuring The Authentication Mechanism, A.k.a. The User Sign-In, Through The AAD Connect Wizard For Azure AD

[AD.1] Federated SSO

When choosing Federated SSO, currently the AADC Wizard supports the configuration option to federate with either ADFS (Federation with ADFS), or Ping Federate (Federation with PingFederate). In both cases, you can also choose “Do not configure”, but then you have to configure all by yourself in the corresponding federation system. If you know what is needed and what to do, you can do this yourself, as it is really not that difficult. The latter option “Do not configure” is for sure required when you need some serious customization in the configuration of the federation systems and the processing of the rules for the relying party, a.k.a. application.

This option is most of the time chosen when an organization already has a federation system in place. When this option is chosen, the custom domain in Azure AD is configured as a federated domain. This means that when Azure AD wants to authenticate a user, that is part of a certain custom DNS domain, it will determine the domain is federated. Due to that, it will redirect authentication to the corresponding federation system. The federation system in turn authenticates the user against the directory service the user belongs to, and the user is redirected back to Azure AD.

So, in this case, Azure AD depends on the federation system and the federation system (e.g., ADFS) depends on the directory service (e.g., AD). In the case of a ransomware attack against either or both the directory service (e.g., AD) and/or the federation system (e.g., ADFS), authentication against Azure AD for federated domains DOES NOT work anymore.

What can you do about this? Well, the initial thought could be to “fix” the directory service (e.g., AD) and/or the federation system (e.g., ADFS). Unfortunately that can take some serious time, especially if it is too complex or worse if no backups are available. The best way to have a backup authentication, when using federated SSO, is to in addition enable Password Hash Sync (PHS) through AADC. More details about PHS later. As mentioned earlier, when using federated SSO, the custom DNS domain in Azure AD is configured as a federated domain and because of that, Azure AD will always redirect authentication to the federation system. To enable Azure AD to take over authentication, the federated domain needs to be converted to a managed domain. Because Azure AD, through PHS, has the on-premises password hashes, and the domain has been converted, Azure AD will be able to authenticate users, while AD and/or e.g. ADFS are not available yet. Make you test this conversion and determine the impact!!! I have seen it happen where Identity Protection kicks in after converting the domain and the user authenticates natively against Azure AD. When all is good and up and running again, you can convert the custom DNS domain back from managed to a federated domain so that AD/ADFS take over authentication again. Please do take into account the possible impact of people changing their password against Azure AD after converting from federated to a managed domain, and before converting back. When converting back, if a password change occurred, the password known by Azure AD does not match the password known by AD. If you have recovered your AD from a backup, and therefore went back in time, that is also a separate challenge on its own!

MY RECOMMENDATION: do you have and use federated SSO, and you do not have PHS enabled? Enable PHS as soon as possible for ALL synched accounts!!! Also make sure to have a tested and automated plan ready to convert the federated domains in Azure AD to managed domains, so that Azure AD can take over authentication. This will save your and your organizations bacon with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.2] Pass-Through Authentication (PTA), with or without Seamless Single Sign-On

When choosing for Pass-Through Authentication (PTA), with or without Seamless Single Sign-On, organizations most likely have the following situation:

• A federated system, like e.g. ADFS, is not in place
• On-premises passwords are not allowed to be stored in Azure AD in any form
• Passwords policies should also be governed by the on-premises AD and not by Azure AD

If this is the situation or are the requirements, then most likely an organization is using PTA. With PTA, custom DNS domains in Azure AD are configured as managed, but authentication is still not done by Azure AD. PTA is not exactly something like federated SSO, but it does have some similar behavior. When PTA is enabled, Azure AD knows that authentication must be redirected towards the on-premises AD. To make sure “something” on-premises knows how to handle that authentication request, a so called PTA agent is used. After enabling PTA through AADC, the AADC server hosts the first PTA agent. You can install additional PTA agents on additional servers to support the authentication redirection load from Azure AD.

So, in this case, Azure AD depends on the PTA agents and the PTA agents depend on the directory service (e.g., AD). Looks very similar to “Federated SSO” doesn’t it? In the case of a ransomware attack against the directory service (e.g., AD), authentication against Azure AD DOES NOT work anymore.

What can you do about this? Well, the initial thought could be again to “fix” the directory service (e.g., AD). Unfortunately, as before, that can take some serious time, especially if it is too complex or worse if no backups are available. OK, but is there a backup authentication like with “Federated SSO”. Well, the answer is again PHS. But wait!!! You chose PTA because you did not want to have any form of your passwords in Azure AD, and as backup you want to use PHS. First of all, that is not even possible. And if it were possible you would be using an implementation that contradicts itself. Are you also aware that ANY server with a PTA agent, must be considered as a Tier0 server? Trust me, servers with PTA agents belong in Tier0!!!

MY RECOMMENDATION: do you have and use PTA? Then get rid of it and start using PHS AS SOON AS POSSIBLE. You may not want to have your passwords in Azure AD because you think it is a risk, right? Think about the risk and impact on your users when literally not a single user would be able to authenticate, because you chose PTA! The problem with PTA is that many think about the requirements as listed earlier, but not many think about the consequences when a ransomware attack occurs. NOT using PTA, but rather PHS instead, this will save your and your organizations bacon big time with regards to the usage of online services (i.e., Azure AD) and anything connected to that if you are ransomwared!

[AD.3] Password Hash Synchronization (PHS), with or without Seamless Sign-On

So if you are or not using “Federated SSO”, and for sure not PTA, then you must be using PHS actively or have it as a backup authentication mechanism. PHS is the best option when not having a federated system and not caring about any form of passwords being stored in Azure AD. There is even a third reason why you would want to have PHS. If you want to use the leaked credential feature of Azure AD, you MUST have PHS enabled, whether or not it is being used actively.

By default with PHS, all synched (user) accounts are in scope of synching their password hash to Azure AD. Although it is possible to only scope PHS to a specific set of groups (done through scoped sync rules in AADC), I highly DO NOT recommend that when we are talking about regular users using online services in or through Azure AD. The whole idea is about being able to use online services in or through Azure AD, when your on-premises AD has been burned to the ground due to a ransomware attack. If you think it won’t happen to you, think again. Todat, it is more about “when”, then “if”.

MY RECOMMENDATION: if you are already using PHS, that means you have chosen wisely. GOOD FOR YOU! With regards to this, there is not much extra what you can do. Just make sure it scopes your complete user population, and not just a part of it.

The moral of this story therefore is:

• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• DO NOT use Pass-Through Authentication (PTA)
• At least enable Password Hash Sync (PHS) as a backup authentication if you are actively using a federation system for federated SSO against Azure AD
• Migrate to start using Password Hash Sync (PHS) as the primary authentication

PS: make sure you update your stakeholders, management and security officers about this, and take appropriate action as needed!

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

Advertisement

(2021-10-22) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 6

Find PART 5 of this series HERE

[AD.6 – An Automation Account with a scheduled PowerShell Runbook for subsequent processing assignments]

To automate all this coolness you need an automation account that processes everything on a regular basis!

To create an automation account with all that is required, you can use the code below. Make sure to replace the parts corresponding to your own environment and requirements

Invoke-Command -ScriptBlock {
	Function retrieveTenantIDFromTenantFDQN () {
		Param (
			[string]$tenantFQDN
		)

		# Specify The Tenant Specific Discovery Endpoint URL
		$oidcConfigDiscoveryURL = $null
		$oidcConfigDiscoveryURL = "https://login.microsoftonline.com/$tenantFQDN/v2.0/.well-known/openid-configuration"
		$oidcConfigDiscoveryResult = $null

		# Retrieve The Information From The Discovery Endpoint URL
		$tenantID = $null
		$oidcConfigDiscoveryResult = $null
		Try {
			$oidcConfigDiscoveryResult = Invoke-RestMethod -Uri $oidcConfigDiscoveryURL -ErrorAction Stop
		}
		Catch {
			# Placeholder
		}

		# If There Is A Result Determine The Tenant ID
		If ($null -ne $oidcConfigDiscoveryResult) {
			$tenantID = $oidcConfigDiscoveryResult.authorization_endpoint.Split("/")[3]
		}

		Return $tenantID
	}

	Clear-Host

	# Tenant Details
	$tenantFQDN = "<SPECIFY YOUR TENANT FQDN>" # e.g. "<TENANT NAME>.ONMICROSOFT.COM"
	$tenantID = retrieveTenantIDFromTenantFDQN -tenantFQDN $tenantFQDN

	# Application Details
	$msftGraphMgmtAppApplicationID = "<SPECIFY YOUR APPLICATION ID>" # e.g. "56a7b6fe-06f9-5635-9e93-7e5ccacdc08e"

	# Private Key/Certificate Details
	$subjectName = "<SPECIFY THE SUBJECT NAME OF THE CERTIFICATE TO ACCES THE REGISTERED APPLICATION>" # e.g. "mgmt-Admin-Units-MSFT-Graph"
	$exportFolderPath = "<SPECIFY THE EXPORT FOLDER FOR THE PFX FILE>" # e.g. "C:\TEMP"
	$pfxOutputPath = Join-Path $exportFolderPath "$subjectName.pfx"
	$pfxPassword = '<SPECIFY THE PASSWORD PROTECTING THE PFX FILE>' # e.g. 'gLOPeVPMw93YaarLItOLFMF3Y5b6G90jehC1psMOfuZsyj04nElKc2yXrzf6YvHz'
	$pfxPasswordSecure = $(ConvertTo-SecureString $pfxPassword -AsPlainText -Force)

	# Connect Using Azure Automation
	Connect-AzAccount -TenantId $tenantID
	Get-AzSubscription -TenantId $tenantID
	Set-AzContext -Subscription $(Read-Host "Subscription ID...")
	
	# Details For The Automation Account And Runbook
	$displayName = "<SPECIFY THE DISPLAY NAME OF THE AUTOMATION ACCOUNT>" # e.g. "Managing-Admin-Unit-Assignments"
	$automationAccountDisplayName = "AutmationAccount-$displayName"
	$automationAccountLocation = "<SPECIFY THE AZURE LOCATION TO HOST THE AUTOMATION ACCOUNT>" # e.g. "West Europe"
	$automationAccountResourceGroup = "<SPECIFY THE RESOURCE GROUP NAME FOR THE AUTOMATION ACCOUNT>" # e.g. "RG-Automation"
	$automationAccountRunbookFilePath = "<SPECIFY THE FULL PATH TO THE POWERSHELL CODE FOR THE RUNBOOK>" # e.g. "<FULL FOLDER PATH>\AAD-Automated-Administrative-Unit-Assignment_Auto-Account-Runbook.ps1"

	# Create The Automation Account
	New-AzAutomationAccount -Name $automationAccountDisplayName -Location $automationAccountLocation -ResourceGroupName $automationAccountResourceGroup

	# Upload The PFX File Into The Automation Account
	New-AzAutomationCertificate -AutomationAccountName $automationAccountDisplayName -Name $subjectName -Path $pfxOutputPath -Password $pfxPasswordSecure -ResourceGroupName $automationAccountResourceGroup

	# Create The Required Variables
	New-AzAutomationVariable -AutomationAccountName $automationAccountDisplayName -Name "tenantFQDN" -Encrypted $False -Value $tenantFQDN -ResourceGroupName $automationAccountResourceGroup
	New-AzAutomationVariable -AutomationAccountName $automationAccountDisplayName -Name "appClientID" -Encrypted $False -Value $msftGraphMgmtAppApplicationID -ResourceGroupName $automationAccountResourceGroup

	# Import The PowerShell Script Into The Runbook Of The Automation Account And Publish It
	$runBookMgmtAUAssignments = Import-AzAutomationRunbook -Name "Runbook-$displayName" -Path $automationAccountRunbookFilePath -ResourceGroup $automationAccountResourceGroup -AutomationAccountName $automationAccountDisplayName -Type PowerShell -Published

	# Define A Schedule In The Automation Account
	$timeOfDayForRunbookToExec = "<SPECIFY THE TIME FOR THE RUNBOOK TO EXECUTE>" # e.g. "21:00:00"
	$startTime = (Get-Date $timeOfDayForRunbookToExec).AddHours(24)
	$autoAccountSchedule = New-AzAutomationSchedule -AutomationAccountName $automationAccountDisplayName -Name "Schedule-$displayName" -StartTime $startTime -DayInterval 1 -ResourceGroupName $automationAccountResourceGroup

	# Register The Previous Schedule For The Runbook To Execute
	Register-AzAutomationScheduledRunbook -RunbookName $($runBookMgmtAUAssignments.Name) -ResourceGroupName $automationAccountResourceGroup -AutomationAccountName $automationAccountDisplayName -ScheduleName $($autoAccountSchedule.Name)
}

Figure 1: Creation Of The Automation Account In Azure
–

Figure 2a: Configured Properties Of The Automation Account – Runbook
–

Figure 2b: Configured Properties Of The Automation Account – Schedule
–

Figure 2c: Configured Properties Of The Automation Account – Private Key And Certificate
–

Figure 2d: Configured Properties Of The Automation Account – Variables
–

You can now wait until the runbook executes manually, or you can start it on-demand if you wish!. Just make sure that when you start the runbook manually it completes, before it starts automatically.

Have fun and enjoy!

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-10-20) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 5

Find PART 4 of this series HERE

[AD.5 – A PowerShell script for the initial processing assignment]

In general you would not need this initial processing script. However, that really depends on the size (i.e. amount of objects that need to be processed and assigned to AUs. In my test environment, I tried what is described in AD.6 initially and that worked. But because I was working with 100000+ objects that needed to be assigned to AUs, after 3 hours Azure AD stopped the script due to fair use policy.

I saw the following error message:

Stopped
The job has been stopped because it reached the fair share limit of job execution more than 3 hours. For long-running jobs, it’s recommended to use a Hybrid Runbook Worker. Hybrid Runbook Workers don’t have a limitation on how long a runbook can execute. Refer https://docs.microsoft.com/en-us/azure/automation/automation-runbook-execution#fair-share for more details.

Of course I could restarted the runbook or just wait until the schedule would kick in until it was stopped again. This happened at least 3 times. For long running runbooks, Microsoft suggest to use Hybrid Worker Runbooks. So, that’s why I decided to updated the script to be used from an on-premises computer/laptop/server/workstation after connecting to Azure AD. OK, that still takes quite some hours but, it was able to finish without being stopped after some hours of execution due to some limit. The script can be downloaded from HERE.

$tenantFQDN = "<SPECIFY YOUR TENANT FQDN>" # e.g. "<TENANT NAME>.ONMICROSOFT.COM"
$appClientID = "<SPECIFY THE APPLICATION CLIENT ID OF THE APP PREVIOUSLY CREATED>"
$pfxOutputPath = "<SPECIFY HERE THE FULL PATH TO THE PFX FILE>"
$pfxPassword = '<SPECIFY HERE THE PASSWORD PROTECTING THE PFX FILE>'

.\AAD-Automated-Administrative-Unit-Assignment.ps1 -tenantFQDN $tenantFQDN -appClientID $appClientID -pfxFilePath $pfxOutputPath -pfxPassword $pfxPassword

Figure 1a: The PowerShell Script Performing The Initial Assignment Of User And group Objects
–

Figure 1b: The PowerShell Script Performing The Initial Assignment Of User And group Objects
–

Figure 1c: The PowerShell Script Performing The Initial Assignment Of User And group Objects
–

Figure 1d: The PowerShell Script Performing The Initial Assignment Of User And group Objects
–

The whole processing will be visible in the Azure AD Audit Logs

Figure 2: All User And Group Assignments Or Unassignments Visible In The Azure AD Audit Logs
–

To be continued in PART 6 of this series.

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-10-18) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 4

Find PART 3 of this series HERE

[AD.4 – A registered application with the correct permissions to manage the AU assignments]

To be able to assign objects (users and groups) in an automatic manner to Administrative Units, a registered application is needed with the correct application permissions (not delegated permissions) to assign the objects that match the filter to the corresponding Administrative Unit.

The following permissions are required:

• Group.Read.All
• User.Read.All
• AdministrativeUnit.ReadWrite.All

After configuring the permissions, those permissions also need to be consented before you can actually use them.

To control the application in a secure authenticated manner, either a client secret can be used or a certificate. I those to use a certificate as that requires possession (private key) and knowledge (password for private key) instead of just knowledge (secret).

The code below will create a self-signed certificate on your local computer, export that to a CER and PFX (protected with a password) and then delete the certificate and private key from the local computer store. It will also present the password on screen for you to copy it to a secure location! Make sure to store the PFX file and its corresponding password in a secure place.

Invoke-Command -ScriptBlock {
	Clear-Host
	
	# The Subject Name
	$subjectName = "<SPECFIFY THE SUBJECT NAME FOR THE CERTIFICATE>" # e.g. "mgmt-Admin-Units-MSFT-Graph"

	# Tenant Details
	$tenantFQDN = "<SPECFIFY YOUR TENANT FQDN>" # e.g. "<TENANT NAME>.ONMICROSOFT.COM"

	# Certificate Store Location
	$certStoreLocation = "Cert:\CurrentUser\My"

	# Where To Export The Certificate And The Private Key
	$exportFolderPath = "<Folder Path To Export The Certificate Data To>" # e.g. "C:\TEMP"
	$cerOutputPath = Join-Path $exportFolderPath "$subjectName.cer"
	$pfxOutputPath = Join-Path $exportFolderPath "$subjectName.pfx"

	# Splat For Readability
	$createCertificateSplat = @{
		Type				= "Custom"
		Subject				= $subjectName
		KeyFriendlyName		= $subjectName
		KeyDescription		= $subjectName
		FriendlyName		= $subjectName
		DnsName				= $tenantName
		CertStoreLocation	= $certStoreLocation
		Provider			= "Microsoft Enhanced RSA and AES Cryptographic Provider"
		KeySpec				= "KeyExchange"
		KeyUsage			= @("None")
		HashAlgorithm		= "SHA256"
		KeyAlgorithm		= "RSA"
		KeyLength			= 2048
		NotBefore			= $([datetime]::now.AddHours(-1))
		NotAfter			= $([datetime]::now.AddDays(1185)) # 3 Years and 3 months | This is to make sure the process always start in the same period as it otherwise will crawl back!
		KeyExportPolicy		= "Exportable"
	}

	# Create Certificate
	$certificate = New-SelfSignedCertificate @createCertificateSplat

	# Get Certificate Path
	$certificatePath = Join-Path -Path $certStoreLocation -ChildPath $certificate.Thumbprint

	# Generate A Password
	# This only contains numeric and alphanumeroc characters and not any special characters to prevent issues when uploading the private keys and certs.
	# The max length of the generated password depends on the number of available characters, hence repeating the list of characters to allow very long passwords if needed
	$pfxPassword = $(-join (48..57+65..90+97..122+48..57+65..90+97..122+48..57+65..90+97..122+48..57+65..90+97..122 | ForEach-Object {[char]$_} | Get-Random -Count 64))
	$pfxPasswordSecure = $(ConvertTo-SecureString $pfxPassword -AsPlainText -Force)

	# Export Certificate Without Private Key
	Export-Certificate -Cert $certificatePath -FilePath $cerOutputPath | Out-Null
	Export-PfxCertificate -Cert $certificatePath -FilePath $pfxOutputPath -Password $pfxPasswordSecure | Out-Null

	# Deleting The Private Key And Certificate
	Set-Location $certStoreLocation
	Get-ChildItem $($certificate.Thumbprint) | Remove-Item -DeleteKey -ErrorAction SilentlyContinue | Out-Null

	# Displaying The File Paths Of The Exported CER/PFX File
	Write-Host ""
	Write-Host " > File Path For Exported CER File...: '$cerOutputPath'" -ForegroundColor Yellow
	Write-Host " > File Path For Exported PFX File...: '$pfxOutputPath'" -ForegroundColor Yellow

	# Displaying The Password For 60 Seconds. After That The Screen And The Variables Are Cleared
	Write-Host ""
	Write-Host "! ! ! Store The Password Of The Private Key In A Safe Location ! ! !" -ForegroundColor Red
	Write-Host "WARNING: In 60 Seconds The Screen And Variables Will Be Cleared. Copy The Password Value A.S.A.P.!!!" -ForegroundColor White
	Write-Host " > 'PFX Password'.................: '$pfxPassword'" -ForegroundColor Yellow
	Write-Host "! ! ! Store The Password Of The Private Key In A Safe Location ! ! !" -ForegroundColor Red
	Write-Host ""
	Start-Sleep -s 60
	$certificate = $null
	$pfxPassword = $null
	$pfxPasswordSecure = $null
	Set-Location C:\
	Clear-Host
}

Figure 1: Creating A Self-Signed Certificate And Exporting It
– 

Now we can create the application, configure the required permissions, consent those and upload the certificate to the registered application. Consenting will be done in a semi-automated manner using the device code flow. Run this code in the previous PowerShell window where you already connected to Azure AD.

Invoke-Command -ScriptBlock {
	Function retrieveTenantIDFromTenantFDQN () {
		Param (
			[string]$tenantFQDN
		)

		# Specify The Tenant Specific Discovery Endpoint URL
		$oidcConfigDiscoveryURL = $null
		$oidcConfigDiscoveryURL = "https://login.microsoftonline.com/$tenantFQDN/v2.0/.well-known/openid-configuration"
		$oidcConfigDiscoveryResult = $null

		# Retrieve The Information From The Discovery Endpoint URL
		$tenantID = $null
		$oidcConfigDiscoveryResult = $null
		Try {
			$oidcConfigDiscoveryResult = Invoke-RestMethod -Uri $oidcConfigDiscoveryURL -ErrorAction Stop
		}
		Catch {
			# Placeholder
		}

		# If There Is A Result Determine The Tenant ID
		If ($null -ne $oidcConfigDiscoveryResult) {
			$tenantID = $oidcConfigDiscoveryResult.authorization_endpoint.Split("/")[3]
		}

		Return $tenantID
	}
	
	Clear-Host

	# Load Assembly To Use The URLEncode Function
	Add-Type -AssemblyName System.Web

	# Load Assembly To Use MessageBox
	Add-Type -assemblyName PresentationFramework

	# Generic Details
	$msftGraphFQDN = "graph.microsoft.com" # FQDN For Microsoft Graph

	# Tenant Details
	$tenantFQDN = "<SPECFIFY YOUR TENANT FQDN>" # e.g. "<TENANT NAME>.ONMICROSOFT.COM"
	$tenantID = retrieveTenantIDFromTenantFDQN -tenantFQDN $tenantFQDN
	$tenantName = "<SPECFIFY YOUR TENANT NAME>"

	# Where To Import The Certificate From
	$subjectName = "<SPECFIFY THE SUBJECT NAME FOR THE CERTIFICATE>" # e.g. "mgmt-Admin-Units-MSFT-Graph"
	$exportFolderPath = "<Folder Path To Export The Certificate Data To>" # e.g. "C:\TEMP"
	$cerOutputPath = Join-Path $exportFolderPath "$subjectName.cer"
	$pfxOutputPath = Join-Path $exportFolderPath "$subjectName.pfx"

	# Azure AD Device Code Request Endpoint URL
	$aadDeviceCodeRequestEndpointURL = "https://login.microsoftonline.com/$tenantID/oauth2/devicecode"

	# Device Code Approval Endpoint URL
	$deviceCodeApprovalEndpointURL = "https://www.microsoft.com/devicelogin"

	# Application Details
	$msftGraphMgmtAppDisplayName = "<SPECIFY THE APPLICATION DISPLAY NAME OF THE REGISTERED APPLICATION>" # Example: "<TENANT NAME>: Mgmt App - Managing Automatic AU Assignments"
	$msftGraphMgmtAppIdentifierURI = "https://$tenantName.onmicrosoft.com/$($msftGraphMgmtAppDisplayName.Replace(" ","-").Replace("---","-").Replace(":-","-"))"
	$msftGraphMgmtAppReplyURL = "https://$($msftGraphMgmtAppDisplayName.Replace(" ","-").Replace("---","-").Replace(":-","-"))"

	# Required Resource Access, In Other Words The Required Permissions
	$requiredResourceAccessPSObjectListMSFTGraphMgmtApp = @(
		[PSCustomObject]@{
			resourceAppId = "00000003-0000-0000-c000-000000000000"	# MSFT Graph => (Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'")
			resourceAccess = @(
				@{
					id = "5eb59dd3-1da2-4329-8733-9dabdc435916"		# AdministrativeUnit.ReadWrite.All => (Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles | ?{$_.Value -eq "AdministrativeUnit.ReadWrite.All"}
					type = "Role"
				},
				@{
					id = "5b567255-7703-4780-807c-7be8301ae99b"		# Group.Read.All => (Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles | ?{$_.Value -eq "Group.Read.All"}
					type = "Role"
				},
				@{
					id = "df021288-bdef-4463-88db-98f22de89214"		# User.Read.All => (Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles | ?{$_.Value -eq "User.Read.All"}
					type = "Role"
				}
			)
		}
	)
	$requiredResourceAccessListMSFTGraphMgmtApp = @()
	ForEach($resourceApp in $requiredResourceAccessPSObjectListMSFTGraphMgmtApp) {
		$requiredResourceAccess = New-Object -TypeName "Microsoft.Open.AzureAD.Model.RequiredResourceAccess"
		$requiredResourceAccess.ResourceAppId = $resourceApp.resourceAppId
		ForEach($resourceAccess in $resourceApp.resourceAccess) {
			$requiredResourceAccess.resourceAccess += New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList $resourceAccess.Id,$resourceAccess.type
		}
		$requiredResourceAccessListMSFTGraphMgmtApp += $requiredResourceAccess
	}

	# Creating The App Registration
	$msftGraphMgmtApp = New-AzureADApplication -DisplayName $msftGraphMgmtAppDisplayName -IdentifierUris $msftGraphMgmtAppIdentifierURI -ReplyUrls @($msftGraphMgmtAppReplyURL) -RequiredResourceAccess $requiredResourceAccessListMSFTGraphMgmtApp
	$msftGraphMgmtAppObjectID = $msftGraphMgmtApp.ObjectID
	$msftGraphMgmtAppApplicationID = $msftGraphMgmtApp.AppId
	Start-Sleep -s 10

	# Creating The Service Principal
	$msftGraphMgmtSvcPrinc = New-AzureADServicePrincipal -DisplayName $msftGraphMgmtAppDisplayName -AppId $msftGraphMgmtAppApplicationID -AccountEnabled $true -AppRoleAssignmentRequired $false
	$msftGraphMgmtSvcPrincObjectID = $msftGraphMgmtSvcPrinc.ObjectID
	$msftGraphMgmtSvcPrincApplicationID = $msftGraphMgmtSvcPrinc.AppId
	Start-Sleep -s 10

	# Uploading The Certificate To The Application Registration
	$msftGraphMgmtCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
	$msftGraphMgmtCert.Import($cerOutputPath)
	$msftGraphMgmtCertRawData = $msftGraphMgmtCert.GetRawCertData()
	$msftGraphMgmtCertCERBase64 = [System.Convert]::ToBase64String($msftGraphMgmtCertRawData) # Base64 Encode The Public Key
	$msftGraphMgmtCertHash = $msftGraphMgmtCert.GetCertHash() # Get The Custom Key Identifier
	$msftGraphMgmtCertCustomKeyIdentifier = [System.Convert]::ToBase64String($msftGraphMgmtCertHash)
	$msftGraphMgmtCertNotBeforeISO8601Format = (Get-Date $($msftGraphMgmtCert.NotBefore)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ") # Date In ISO8601Format
	$msftGraphMgmtCertNotAfterISO8601Format = (Get-Date $($msftGraphMgmtCert.NotAfter)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ") # Date In ISO8601Format
	New-AzureADApplicationKeyCredential -ObjectId $msftGraphMgmtAppObjectID -Type AsymmetricX509Cert -Usage Verify -CustomKeyIdentifier $msftGraphMgmtCertCustomKeyIdentifier  -Value $msftGraphMgmtCertCERBase64 -StartDate $msftGraphMgmtCertNotBeforeISO8601Format -EndDate $msftGraphMgmtCertNotAfterISO8601Format | Out-Null

	# Grant Consent To The Required Permissions - Build The Request Body To Request A Device/User Code From MSFT Graph
	$msftGraphDeviceCodeRequestBody = @()
	$msftGraphDeviceCodeRequestBody += "resource=$([System.Web.HttpUtility]::UrlEncode($('https://' + $msftGraphFQDN + '/')))"
	$msftGraphDeviceCodeRequestBody += "&client_id=$msftGraphMgmtAppApplicationID"
	$deviceTokenRequestResponse = Invoke-RestMethod -uri $aadDeviceCodeRequestEndpointURL -ContentType "application/x-www-form-urlencoded" -Method POST -Body $msftGraphDeviceCodeRequestBody -ErrorAction Stop
	$msftGraphDeviceCodeResponseUserCode = $deviceTokenRequestResponse.user_code

	# Grant Consent To The Required Permissions - Put The User Code In The Clipboard To Paste It Later As Needed
	Set-Clipboard -Value $msftGraphDeviceCodeResponseUserCode

	# Grant Consent To The Required Permissions - Present A Notification On What To Do Next
	[System.Windows.MessageBox]::Show("A device code has been requested from Azure AD. For this device code the corresponding user code ($msftGraphDeviceCodeResponseUserCode) has been copied to the clipboard. After clicking [OK] an authentication screen will be opened. On that new screen just paste the user code by pressing [CTRL]+[V] and then click [NEXT] to authenticate with your Global Admin Credentials for the AAD Tenant:`n`nTenant FQDN....: '$tenantFQDN'`nTenant ID..........: '$tenantID'`nUser Code.........: '$msftGraphDeviceCodeResponseUserCode'", "Device Code Authentication - Please Read Carefully", 0, 64) | Out-Null

	# Grant Consent To The Required Permissions - Navigate To The Device Approcal URL For The Actual Consent
	[System.Diagnostics.Process]::Start($deviceCodeApprovalEndpointURL)
}

Figure 2: After Requesting The Device Code And User Code To Consent The Application Permissions
– 

Figure 3: Specifying The User Code To Continue Authentication Followed By Consent Of Application Permissions
– 

Figure 4: Signing-In Before Consenting The Required Permissions For The Registered App
– 

Figure 5: Reviewing The Required Permissions For The Registered App
– 

Figure 6: Reviewing The Required Permissions For The Registered App
–

Figure 7: The Configured Certificate For The Registered App Managing The Automatic AU Assignments
–

Figure 8: The Configured And Consented Permissions For The Registered App Managing The Automatic AU Assignments
–

To be continued in PART 5 of this series.

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-10-16) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 3

Find PART 2 of this series HERE

[AD.3 – Administrative Units with logic to support some kind of query rules]

Now the data ended up in Azure AD, it is time to start configuring Azure (AD) to support the dynamic assignment for AUs. But first I needed to create the AUs in Azure AD, and although not needed for this exercise I also configured delegation along the way! For that I first created Azure AD security groups that could be assigned role, and then after creating the AU and the groups I assigned the group for the AU the corresponding role for that AU also. 

Dynamic groups in Azure AD contain the property with the filter that looks for user objects matching that filter. In other words, the filter itself is stored on the object that needs and uses that filter. With that thought in mind I had to implement something similar for AUs. Unfortunately it appeared not to be possible to extend the Azure AD schema for “AdministrativeUnit” objects. That would have been the best option for this exercise. Therefore I had to reuse an existing attribute that I have control over. That list of attributes is not that big. I had “DisplayName” and “Description”. In this case I chose to (mis)use the “Description” attribute of the AdministrativeUnit object.

I came up with the following structure for the “Description” attribute:

”<real description|filter:user=<filter targeting user objects>|filter:group=<filter targeting user objects>”

Example: “All Test Accounts For AT – Austria|filter:user=Department eq ‘SampleData’ and Country eq ‘Austria’|filter:group=extension_b3d7ffeca7f24ab6bf35bb6ff4918986_department eq ‘SampleData’ and extension_b3d7ffeca7f24ab6bf35bb6ff4918986_location eq ‘Austria’

If you look at the code you see some sleep timers. I had to implement those to make sure that Azure AD had completely instantiated the group so that it could be used in the role assignment.

Invoke-Command -ScriptBlock {
	Function retrieveTenantIDFromTenantFDQN () {
		Param (
			[string]$tenantFQDN
		)

		# Specify The Tenant Specific Discovery Endpoint URL
		$oidcConfigDiscoveryURL = $null
		$oidcConfigDiscoveryURL = "https://login.microsoftonline.com/$tenantFQDN/v2.0/.well-known/openid-configuration"
		$oidcConfigDiscoveryResult = $null

		# Retrieve The Information From The Discovery Endpoint URL
		$tenantID = $null
		$oidcConfigDiscoveryResult = $null
		Try {
			$oidcConfigDiscoveryResult = Invoke-RestMethod -Uri $oidcConfigDiscoveryURL -ErrorAction Stop
		}
		Catch {
			# Placeholder
		}

		# If There Is A Result Determine The Tenant ID
		If ($null -ne $oidcConfigDiscoveryResult) {
			$tenantID = $oidcConfigDiscoveryResult.authorization_endpoint.Split("/")[3]
		}

		Return $tenantID
	}

	Clear-Host

	# Tenant Details
	$tenantFQDN = "<SPECFIFY YOUR TENANT FQDN>"
	$tenantID = retrieveTenantIDFromTenantFDQN -tenantFQDN $tenantFQDN

	# Connect To Azure AD
	Connect-AzureAD -TenantId $tenantID

	# Get The Required Azure AD Roles For The AU Delegation
	$aadDirectoryRoles = Get-AzureADDirectoryRole
	$adminRoleGroups = $aadDirectoryRoles | Where-Object { $_.DisplayName -eq "Groups Administrator" }
	$adminRoleAuthN = $aadDirectoryRoles | Where-Object { $_.DisplayName -eq "Authentication Administrator" }
	$adminRoleHelpdesk = $aadDirectoryRoles | Where-Object { $_.DisplayName -eq "Helpdesk Administrator" }
	$adminRoleUsers = $aadDirectoryRoles | Where-Object { $_.DisplayName -eq "User Administrator" }

	# Build A List Of Data To Create And Configure AUs
	$auData = @()
	$auData += "AT|Austria"
	$auData += "AU|Australia"
	$auData += "BE|Belgium"
	$auData += "BR|Brazil"
	$auData += "CA|Canada"
	$auData += "CH|Switzerland"
	$auData += "CY|Cyprus (Anglicized)"
	$auData += "CZ|Czech Republic"
	$auData += "DE|Germany"
	$auData += "DK|Denmark"
	$auData += "EE|Estonia"
	$auData += "ES|Spain"
	$auData += "FI|Finland"
	$auData += "FR|France"
	$auData += "GB|United Kingdom"
	$auData += "GL|Greenland"
	$auData += "HU|Hungary"
	$auData += "IS|Iceland"
	$auData += "IT|Italy"
	$auData += "NL|Netherlands"
	$auData += "NO|Norway"
	$auData += "NZ|New Zealand"
	$auData += "PL|Poland"
	$auData += "PT|Portugal"
	$auData += "SE|Sweden"
	$auData += "SI|Slovenia"
	$auData += "TN|Tunisia"
	$auData += "US|United States"
	$auData += "UY|Uruguay"
	$auData += "ZA|South Africa"
	$auData += "HIST1|HISTORY1"
	$auData += "HIST2|HISTORY2"
	$auData += "EDUC|EDUCATIONAL"
	$auData += "EMPL|EMPLOYEES"
	$auData += "CONT|CONTRACTORS"

	Write-Host ""
	Write-Host "Creating Administrative Units In The Azure AD Tenant..." -ForegroundColor Cyan
	$auData | ForEach-Object {
		$au = $_
		$auCountryCode = $au.Split("|")[0]
		$auCountry = $au.Split("|")[1]
		
		# Creating The AU
		Write-Host " > Creating Administrative Unit 'Accounts - Test - $auCountryCode - $auCountry'..." -ForegroundColor Magenta
		If ($auCountryCode.Length -eq 2) {
			$auObject = New-AzureADMSAdministrativeUnit -DisplayName "Accounts - Test - $auCountryCode - $auCountry" -Description "All Test Accounts For $auCountryCode - $auCountry|filter:user=Department eq 'SampleData' and Country eq '$auCountry'|filter:group=extension_b3d7ffeca7f24ab6bf35bb6ff4918986_department eq 'SampleData' and extension_b3d7ffeca7f24ab6bf35bb6ff4918986_location eq '$auCountry'"
		}
		Else {
			$auObject = New-AzureADMSAdministrativeUnit -DisplayName "Accounts - Test - $auCountryCode - $auCountry" -Description "All Test Accounts For $auCountryCode - $auCountry|filter:user=extension_b3d7ffeca7f24ab6bf35bb6ff4918986_employeeType eq '$auCountry'|filter:group=NA"
		}
		Start-Sleep -s 5
		
		# Creating Admin Groups For The AU
		Write-Host "   # Creating Admin Group 'cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Groups-Admin' For The AU..." -ForegroundColor Yellow
		$adminGroups = New-AzureADMSGroup -DisplayName "cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Groups-Admin" -Description "Groups Admins For AU: Accounts - Test - $auCountryCode - $auCountry" -MailEnabled $false -MailNickName $( -join (48..57 + 65..90 + 97..122 | ForEach-Object { [char]$_ } | Get-Random -Count 10)) -SecurityEnabled $true -IsAssignableToRole $true
		
		Write-Host "   # Creating Admin Group 'cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-AuthN-Admin' For The AU..." -ForegroundColor Yellow
		$adminAuthN = New-AzureADMSGroup -DisplayName "cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-AuthN-Admin" -Description "AuthN Admins For AU: Accounts - Test - $auCountryCode - $auCountry" -MailEnabled $false -MailNickName $( -join (48..57 + 65..90 + 97..122 | ForEach-Object { [char]$_ } | Get-Random -Count 10)) -SecurityEnabled $true -IsAssignableToRole $true
		
		Write-Host "   # Creating Admin Group 'cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Helpdesk-Admin' For The AU..." -ForegroundColor Yellow
		$adminHelpdesk = New-AzureADMSGroup -DisplayName "cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Helpdesk-Admin" -Description "Helpdesk Admins For AU: Accounts - Test - $auCountryCode - $auCountry" -MailEnabled $false -MailNickName $( -join (48..57 + 65..90 + 97..122 | ForEach-Object { [char]$_ } | Get-Random -Count 10)) -SecurityEnabled $true -IsAssignableToRole $true
		
		Write-Host "   # Creating Admin Group 'cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Users-Admin' For The AU..." -ForegroundColor Yellow
		$adminUsers = New-AzureADMSGroup -DisplayName "cld-AAD-Mgmt-AU-$auCountryCode-$auCountry-Users-Admin" -Description "Users Admins For AU: Accounts - Test - $auCountryCode - $auCountry" -MailEnabled $false -MailNickName $( -join (48..57 + 65..90 + 97..122 | ForEach-Object { [char]$_ } | Get-Random -Count 10)) -SecurityEnabled $true -IsAssignableToRole $true
		Start-Sleep -s 20
		
		# Configure Admin Role Assignment For The AU
		Write-Host "   # Assigning The Role '$($adminRoleGroups.DisplayName)' To The Group '$($adminGroups.DisplayName)'..." -ForegroundColor Yellow
		$adminGroupsRoleInfo = New-Object -TypeName Microsoft.Open.MSGraph.Model.MsRoleMemberInfo -Property @{Id = $adminGroups.Id }
		Add-AzureADMSScopedRoleMembership -RoleId $adminRoleGroups.ObjectId -Id $auObject.Id -RoleMemberInfo $adminGroupsRoleInfo | Out-Null
		
		Write-Host "   # Assigning The Role '$($adminRoleAuthN.DisplayName)' To The Group '$($adminAuthN.DisplayName)'..." -ForegroundColor Yellow
		$adminAuthNRoleInfo = New-Object -TypeName Microsoft.Open.MSGraph.Model.MsRoleMemberInfo -Property @{Id = $adminAuthN.Id }
		Add-AzureADMSScopedRoleMembership -RoleId $adminRoleAuthN.ObjectId -Id $auObject.Id -RoleMemberInfo $adminAuthNRoleInfo | Out-Null
		
		Write-Host "   # Assigning The Role '$($adminRoleHelpdesk.DisplayName)' To The Group '$($adminHelpdesk.DisplayName)'..." -ForegroundColor Yellow
		$adminHelpdeskRoleInfo = New-Object -TypeName Microsoft.Open.MSGraph.Model.MsRoleMemberInfo -Property @{Id = $adminHelpdesk.Id }
		Add-AzureADMSScopedRoleMembership -RoleId $adminRoleHelpdesk.ObjectId -Id $auObject.Id -RoleMemberInfo $adminHelpdeskRoleInfo | Out-Null
		
		Write-Host "   # Assigning The Role '$($adminRoleUsers.DisplayName)' To The Group '$($adminUsers.DisplayName)'..." -ForegroundColor Yellow
		$adminUsersRoleInfo = New-Object -TypeName Microsoft.Open.MSGraph.Model.MsRoleMemberInfo -Property @{Id = $adminUsers.Id }
		Add-AzureADMSScopedRoleMembership -RoleId $adminRoleUsers.ObjectId -Id $auObject.Id -RoleMemberInfo $adminUsersRoleInfo | Out-Null
		
		Write-Host ""
	}
}

Figure 1: Creating The AUs, The Delegation Groups And Configuring The Delegation Roles In Azure AD
– 

To be continued in PART 4 of this series.

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-10-14) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 2

Find PART 1 of this series HERE

[AD.2 – Azure AD Connect configuration to sync the required data to Azure AD]

Hybrid Scenario ONLY

Azure AD Connect is THE TOOL to sync data between AD and Azure AD and vice versa as supported. You need to check if the data you need in Azure AD from AD is already being synched or not. If it is not synched already because no sync rules exists, see if those attribute can be configured in sync rules (Inbound Sync from AD and Outbound Sync to Azure AD). If you cannot create a sync rule from existing attributes you need to update the Azure AD Connect configuration by either selecting the required attribute or use the Directory Extension Attribute Sync feature.

To do this start the Azure AD Connect Wizard and choose the option “Customize Synchronization Options”. When reaching the “Optional Features” section, if the option “Directory Extension Attribute Sync” feature is not yet checked, do not check it for now. Click [Next]

Figure 1: Azure AD Connect Configuration Wizard – Optional Features Section
–

When reaching the “Azure AD Attributes” section, see if the required attribute is already selected or not. If it is not yet selected, selected it. If the attribute is not listed, then go back to the “Optional Features” section and check the option “Directory Extension Attribute Sync” feature if it was not yet selected. If it was already checked, then continue by clicking [Next].

Figure 2: Azure AD Connect Configuration Wizard – Azure AD Attributes Section
–

When reaching the “Directory Extensions” section, select the attributes for which Azure AD Connect should create a new extension in the Azure AD schema for the scoped object. Continue by clicking [Next] and completing the wizard until the end.

Figure 3: Azure AD Connect Configuration Wizard – Directory Extensions Section
–

Azure AD Connect implements the “Directory Extension Attribute Sync” feature by creating a app registration in Azure AD called “Tenant Schema Extension App”. That’s the app that stores all Azure AD Connect configured schema extensions for Azure AD. Looking up the app you can fond all the extensions (mine has more than needed for this exercise, but that’s due to different tests)

Get-AzureADApplication -SearchString "Tenant Schema Extension App" | Get-AzureADApplicationExtensionProperty | FL

Figure 4: Extensions In The Azure AD Schema Implemented By Azure AD Connect
–

After this, you need to create the sync rules. That is done by the Azure AD Connect Sync Rule Editor. For this exercise “Department” and “Country” for user objects was already being synched because during my initial installation I selected all the Azure AD Attributes (Figure 1 and 2). I only had to add sync rules for the extension attributes

WARNING: As soon as you edit any sync rule, during the next sync cycle, Azure AD Connect will perform a Ful Sync end-to-end. If you have many objects being synched this might take some time and because of that it may require planning!

Start the Azure AD Connect Sync Rule Editor.

Select the appropriate custom AD inbound sync for user objects and add the attributes that need to be synched. If no custom rule exists, select the appropriate default AD inbound sync rule for user objects and clone it. Then edit the clone.

Select the appropriate custom AD inbound sync for groups objects and add the attributes that need to be synched. If no custom rule exists, select the appropriate default AD inbound sync rule for group objects and clone it. Then edit the clone.

Select the appropriate custom AAD outbound sync for user objects and add the attributes that need to be synched.If no custom rule exists, select the appropriate default AAD outbound sync rule for user objects and clone it. Then edit the clone.

Select the appropriate custom AAD outbound sync for group objects and add the attributes that need to be synched.If no custom rule exists, select the appropriate default AAD outbound sync rule for group objects and clone it. Then edit the clone.

If you used the “Directory Extension Attribute Sync” feature then Azure AD Connect already updated the appropriate sync rules. Check for the sync rules for users and groups, inbound and outbound, that contain the word “DirectoryExtension”

Figure 5: Attribute Flow Transformation In The AD Inbound Sync Rule For User Objects And Directory Extensions
–

Figure 6: Attribute Flow Transformation In The AAD Outbound Sync Rule For User Objects And Directory Extensions
–

Figure 7: Attribute Flow Transformation In The AD Inbound Sync Rule For Group Objects And Directory Extensions
–

Figure 8: Attribute Flow Transformation In The AAD Outbound Sync Rule For Group Objects And Directory Extensions
–

Figure 9: Attribute Flow Transformation In The AD Inbound Sync Rule For Group Objects And Directory Extensions
–

Figure 10: Attribute Flow Transformation In The AAD Outbound Sync Rule For Group Objects And Directory Extensions
–

After having this configured, I enabled the sync schedule again to allow Azure AD Connect perform a Full Sync

To be continued in PART 3 of this series.

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-10-12) Azure AD Administrative Units – Dynamically Managing AU Assignments – Part 1

Quite some time ago I blogged about Azure AD Administrative Units (AU). The details can be found in the found through the following blog posts:

• (2019-07-04) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 1)
• (2019-07-07) Azure AD Delegation Through Roles And Administrative Units – The Good, The Bad And The Ugly (Part 2)

And more recently:

• (2021-09-11) Azure AD Administrative Units – Delegating Scoped Admin Tasks In Azure AD

Microsoft documentation: https://docs.microsoft.com/en-us/azure/active-directory/roles/administrative-units

In my most recent article about Administrative Units I already summarized how interesting it is to use Administrative Units in those scenarios where delegation of admin is required. Nevertheless, I think one of the very interesting features is unfortunately not (yet) supported!

Figure 1: Administrative Units In Azure AD – Management Supported/Unsupported Options
–

Automating assigning user and group objects to specific Administrative Units would seriously have a lot of manual work. Unless you have something external to Azure AD regarding the logic and execution leveraging the Microsoft graph, by default Azure AD does not support that, today. Hopefully it will be soon, as I think many want to get rid of the manual burden or any custom solution. Until automatic assignment is supported/possible by Azure AD itself, you may be able to use what is in this post. Please be aware this is an example and that if you want to use this for your own environment, you need to customize the filters/configurations to that data in your Azure AD tenant!

Interesting enough, I have found a way to automatically assign user/groups, based upon attributes of those objects, to specific administrative units. This blog is fully dedicated to that! So please hang on, keep reading and in the end you might end up with a solution that might work for you!

DISCLAIMER: please make sure to test this in a TEST environment/tenant first and improve where needed!

For all this to work we need the following components:

1. Objects with attributes and values in those attributes to be able to use in filters
   1. Hybrid scenario
   2. Cloud only scenario
2. Azure AD Connect configuration to sync the required data to Azure AD
   1. Hybrid scenario ONLY
3. Administrative Units with logic to support some kind of query rules
4. A registered application with the correct permissions to manage the AU assignments
5. A PowerShell script for the initial processing assignment
6. An Automation Account with a scheduled PowerShell Runbook for subsequent processing assignments

So, let’s get started!

[AD.1 – Objects with attributes and values in those attributes to be able to use in filters]

Hybrid Scenario

In my on-premises test and demo AD I have about 100000+ user objects and also lots of groups. For this exercise I needed a data set of users and groups. For that I chose the objects in the 5 category OUs and the objects in the country OUs. For every of the yellow marked OUs, an AU will be created in Azure AD. In the country OUs both users and groups are (already) being synched to Azure AD. In the category OUs only users are being synched to Azure AD. In both cases Azure AD Connect is doing the synching,

Figure 2: OUs In AD With Objects Being Synched To Azure AD
–

The AUs in Azure AD need to have objects assigned automatically based upon some data to be queried in filters. So you need to think about the AUs you want to create and how to decide, which objects will go into which AUs and what data will be used to make those decisions. If the data is not there (yet) you need to populate that data in AD from some system that has it.

In this example scenario I made the following decisions:

• user objects in the country OUs
  • “department” attribute being equal to the fixed string “SampleData”
  • “country” attribute being equal to the string “<country name>” (e.g. Netherlands)
• group objects in the country OUs
  • “department” attribute being equal to the fixed string “SampleData”
  • “location” attribute being equal to the string “<country name>” (e.g. Netherlands)
• user objects in the category OUs
  • “employeeType” attribute being equal to the string “<employee category>” (e.g. CONTRACTORS)
• group objects in the category OUs
  • N.A. (not being synched)

Figure 3: Sample Data For User Objects In The Country OUs
–

Figure 4: Sample Data For Group Objects In The Country OUs
–

Figure 5: Sample Data For User Objects In The Category OUs
–

Cloud Scenario

For objects authoritatively created in Azure AD, you will have to make sure those objects (users and groups) have the required data stored in some attribute. You may even need to extend the Azure AD schema to store the data if no attribute contains the data you require.

To read more about extending the Azure AD schema, please check out the following posts:

• https://www.xtseminars.co.uk/post/azure-ad-schema-and-directory-extensions
• https://blog.atwork.at/post/Azure-AD-schema-extensions-and-Microsoft-Graph

To be continued in PART 2 of this series.

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/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2021-07-21) Azure AD Connect v2.0.3.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect" (Always The Latest Downloadable Version Only!)

–

IMPORTANT: Major release. Lots of changes/updates!

–

Azure AD Connect: Version Release History

2.0.3.0

Released: 7/20/2021 – Released for download only, not available for auto upgrade

Note: This is a major release of Azure AD Connect. Please refer to the Azure Active Directory V2.0 article for more details.

–

Prerequisites for Azure AD Connect

–

Functional changes

• We have upgraded the LocalDB components of SQL Server to SQL 2019.
• This release requires Windows Server 2016 or newer, due to the requirements of SQL Server 2019.
• In this release we enforce the use of TLS 1.2. If you have enabled your Windows Server for TLS 1.2, AADConnect will use this protocol. If TLS 1.2 is not enabled on the server you will see an error message when attempting to install AADConnect and the installation will not continue until you have enabled TLS 1.2. Note that you can use the new “Set-ADSyncToolsTls12” cmdlets to enable TLS 1.2 on your server.
• With this release, you can use a user with the user role “Hybrid Identity Administrator” to authenticate when you install Azure AD Connect. You no longer need the Global Administrator role for this.
• We have upgraded the Visual C++ runtime library to version 14 as a prerequisite for SQL Server 2019
• This release uses the MSAL library for authentication, and we have removed the older ADAL library, which will be retired in 2022.
• We no longer apply permissions on the AdminSDHolders, following Windows security guidance. We changed the parameter "SkipAdminSdHolders" to "IncludeAdminSdHolders" in the ADSyncConfig.psm1 module.
• Passwords will now be reevaluated when the password last set value is changed, regardless of whether the password itself is changed. If for a user the password is set to “Must change password” then this status is synced to Azure AD, and when the user attempts to sign in in Azure AD they will be prompted to reset their password.
• We have added two new cmdlets to the ADSyncTools module to enable or retrieve TLS 1.2 settings from the Windows Server.
  (You can use these cmdlets to retrieve the TLS 1.2 enablement status, or set it as needed. Note that TLS 1.2 must be enabled on the server for the installation or AADConnect to succeed.)
• Get-ADSyncToolsTls12
• Set-ADSyncToolsTls12
• We have revamped ADSyncTools with several new and improved cmdlets. The ADSyncTools article has more details about these cmdlets. The following cmdlets have been added or updated:
• Clear-ADSyncToolsMsDsConsistencyGuid
• ConvertFrom-ADSyncToolsAadDistinguishedName
• ConvertFrom-ADSyncToolsImmutableID
• ConvertTo-ADSyncToolsAadDistinguishedName
• ConvertTo-ADSyncToolsCloudAnchor
• ConvertTo-ADSyncToolsImmutableID
• Export-ADSyncToolsAadDisconnectors
• Export-ADSyncToolsObjects
• Export-ADSyncToolsRunHistory
• Get-ADSyncToolsAadObject
• Get-ADSyncToolsMsDsConsistencyGuid
• Import-ADSyncToolsObjects
• Import-ADSyncToolsRunHistory
• Remove-ADSyncToolsAadObject
• Search-ADSyncToolsADobject
• Set-ADSyncToolsMsDsConsistencyGuid
• Trace-ADSyncToolsADImport
• Trace-ADSyncToolsLdapQuery
• We now use the V2 endpoint for import and export and we fixed issue in the Get-ADSyncAADConnectorExportApiVersion cmdlet. You can read more about the V2 endpoint in the Azure AD Connect sync V2 endpoint article.
  We have added the following new user properties to sync from on-prem AD to Azure AD
• employeeType
• employeeHireDate
• This release requires PowerShell version 5.0 or newer to be installed on the Windows Server. Note that this version is part of Windows Server 2016 and newer.
• We increased the Group sync membership limits to 250k with the new V2 endpoint.
• We have updated the Generic LDAP connector and the Generic SQL Connector to the latest versions. Read more about these connectors here:
• Generic LDAP Connector reference documentation
• Generic SQL Connector reference documentation
• In the M365 Admin Center, we now report the AADConnect client version whenever there is export activity to Azure AD. This ensures that the M365 Admin Center always has the most up to date AADConnect client version, and that it can detect when you’re using and outdated version
• Provides a batch import execution script which can be called from Windows scheduled job so that the customers can automate the batch import operations with scheduling.
• Credentials are provided as an encrypted file using Windows Data Protection API (DPAPI).
• Credential files can be use only at the same machine and user account where it’s created.
• The Azure AD Kerberos Feature supported for the MSAL library. To use the AAD Kerberos Feature, the customer needs to register an on-premises service principal name into the Azure AD. Provides importing of an on-premises service principal object into the Azure AD.

–

Fixed issues/Bug Fixes:

• We fixed an accessibility bug where the screen reader is announcing incorrect role of the ‘Learn More’ link.
• We fixed a bug where sync rules with large precedence values (i.e. 387163089) cause upgrade to fail. We updated sproc ‘mms_UpdateSyncRulePrecedence’ to cast the precedence number as an integer prior to incrementing the value.
• Fixed a bug where group writeback permissions are not set on the sync account if a group writeback configuration is imported. We now set the group writeback permissions if group writeback is enabled on the imported configuration.
• We updated the Azure AD Connect Health agent version to 3.1.110.0 to fix an installation failure.
• We are seeing an issue with non-default attributes from exported configurations where directory extension attributes are configured. When importing these configurations to a new server/installation, the attribute inclusion list is overridden by the directory extension configuration step, so after import only default and directory extension attributes are selected in the sync service manager (non-default attributes are not included in the installation, so the user must manually reenable them from the sync service manager if they want their imported sync rules to work). We now refresh the AAD Connector before configuring directory extension to keep existing attributes from the attribute inclusion list.
  
• We fixed an accessibility issues where the page header’s font weight is set as "Light". Font weight is now set to "Bold" for the page title, which applies to the header of all pages.
• The function Get-AdObject in ADSyncSingleObjectSync.ps1 has been renamed to Get-AdDirectoryObject to prevent ambiguity with the AD cmdlet.
• The SQL function ‘mms_CheckSynchronizationRuleHasUniquePrecedence’ allow duplicates precedence on outbound sync rules on different connectors. We removed the condition that allows duplicate rule precedence.
• We fixed a bug where the Single Object Sync cmdlet fails if the attribute flow data is null i.e. on exporting delete operation
• We fixed a bug where the installation fails because the ADSync bootstrap service cannot be started. We now add Sync Service Account to the Local Builtin User Group before starting the bootstrap service.
• We fixed an accessibility issue where the active tab on AAD Connect wizard is not showing correct color on High Contrast theme. The selected color code was being overwritten due to missing condition in normal color code configuration.
• We addressed an issue where users were allowed to deselect objects and attributes used in sync rules using the UI and PowerShell. We now show friendly error message if you try to deselect any attribute or object that is used in any sync rules.
• We made some updates to the “migrate settings code” to check and fix backward compatibility issue when the script is ran on an older version of Azure AD Connect.
• Fixed a bug where, when PHS tries to look up an incomplete object, it does not use the same algorithm to resolve the DC as it used originally to fetch the passwords. In particular, it is ignoring affinitized DC information. The Incomplete object lookup should use the same logic to locate the DC in both instances.
• We fixed a bug where AADConnect cannot read Application Proxy items using Microsoft Graph due to a permissions issue with calling Microsoft Graph directly based on AAD Connect client id. To fix this, we removed the dependency on Microsoft Graph and instead use AAD PowerShell to work with the App Proxy Application objects.
• We removed the writeback member limit from ‘Out to AD – Group SOAInAAD Exchange’ sync rule
• We fixed a bug where, when changing connector account permissions, if an object comes in scope that has not changed since the last delta import, a delta import will not import it. We now display warning alerting user of the issue.
• We fixed an accessibility issue where the screen reader is not reading radio button position, i.e. 1 of 2. We added added positional text to the radio button accessibility text field.
• We updated the Pass-Thru Authentication Agent bundle. The older bundle did not have correct reply URL for HIP’s first party application in US Gov.
• We fixed a bug where there is a ‘stopped-extension-dll-exception’ on AAD connector export after clean installing AADConnect version 1.6.X.X, which defaults to using DirSyncWebServices API V2, using an existing database. Previously the setting export version to v2 was only being done for upgrade, we changed so that it is set on clean install as well.
• The “ADSyncPrep.psm1” module is no longer used and is removed from the installation.

• From v1.5.29.0: This hotfix build fixes an issue introduced in build 1.5.20.0 where a tenant administrator with MFA was not able to enable DSSO
• From v1.5.22.0: This hotfix build fixes an issue in build 1.5.20.0 if you have cloned the In from AD – Group Join rule and have not cloned the In from AD – Group Common rule.

–

Known issues:

• The AADConnect wizard shows the “Import Synchronization Settings” option as “Preview”, while this feature is generally Available.
• Some Active Directory connectors may be installed in a different order when using the output of the migrate settings script to install the product.
• The User Sign In options page in the Azure AD Connect wizard mentions “Company Administrator”. This term is no longer used and needs to be replace by “Global Administrator”.
• The “Export settings” option is broken when the Sign In option has been configured to use PingFederate.
• While Azure AD Connect can now be deployed using the Hybrid Identity Administrator role, configuring Self Service Password Reset will still require user with the Global Administrator role.
• When importing the AADConnect configuration while deploying to connect with a different tenant than the original AADConnect configuration, directory extension attributes are not configured correctly.

–

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle! I do not have auto-upgrade enabled, therefore unfortunately I cannot say anything about this version.

–

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/ ###################
————————————————————————————————————————————————————-

(2020-05-08) Upgrading Azure AD Connect – Some Tips

These are some tips I would like to share with you when upgrading Azure AD Connect

[1] Before the upgrade I always export the global configuration and sync rules of Azure AD Connect through a PowerShell script I wrote to a folder

–

[2] During upgrade, I  ALWAYS UNcheck the following. Why? I like to have the opportunity to check things before any sync cycle starts

Figure 1: “Ready To Configure” In The Azure AD Connect Upgrade Wizard

–

[3] After the upgrade I always check the global configuration options to see if anything is different compared to before the upgrade. You either need to have a good memory or create screenshots before the upgrade to be able to compare

Azure AD Connect Wizard –> Configure –> View current configuration

Figure 2: Global Configuration Of Azure AD Connect

–

[4A] After the upgrade I always check the selected forests/domains/OUs to see if anything is different compared to before the upgrade. You either need to have a good memory or create screenshots before the upgrade to be able to compare or have documentation describing what should be configured

Azure AD Connect Wizard –> Configure –> Customize Synchronization Options

In this screen I really want to make sure everything is as it should be! For every connected directory I always expand every AD domain to be sure only required OUs are selected and nothing else. This only applies if you have selected AD domains and OUs that need to be synched. The check is very simple. For every AD domain, expand and then collapse again. Look at the difference in figure 3 and 4

Figure 2: Domain And OU Filtering – BEFORE Expanding

–

Figure 3: Domain And OU Filtering – AFTER Expanding And Collapsing

–

[4B] After the upgrade I always check the Optional Features, Azure AD Apps, Azure AD Attributes and Directory Extensions to see if anything is different compared to before the upgrade. You either need to have a good memory or create screenshots before the upgrade to be able to compare or have documentation describing what should be configured. I always close/cancel the wizard by clicking on the cross in the upper right corner

–

[5] After the upgrade I always export the global configuration and sync rules of Azure AD Connect through a PowerShell script I wrote to a folder

–

[6] After the upgrade I always compare the global configuration exported before the upgrade and the global configuration after the upgrade. This is done through a PowerShell script I wrote

–

[7] After the upgrade I always compare the sync rules exported before the upgrade and the sync rules after the upgrade. This is done through a PowerShell script I wrote

–

[8] After the upgrade I always check the “Application Event Log” for any “weirdness” whatever that may be

–

[9] After the upgrade I always check the most recent log files in the folder “C:\ProgramData\AADConnect” to see what happened during the AAD Connect upgrade and to see if there is any weirdness

–

[10] And when everything is OK, I reenable the sync schedule and manually start of a sync cycle!

–

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/ ###################
————————————————————————————————————————————————————-

(2020-05-08) Azure AD Connect v1.5.29.0 (And v1.5.22.0) Have Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect" (Always The Latest Downloadable Version Only!)

–

 

IMPORTANT: In one environment I upgraded from Azure AD Connect 1.5.20.0. I noticed that it triggered a Full Synchronization on the AD MA/Connector(s). Since the full syncs may take some time, depending on the size of your AD/AAD environment in terms of number objects being synched, make sure that you have taken the necessary steps to support this or hold off on upgrading until you have found a convenient moment to do so.

–

Azure AD Connect: Version Release History

1.5.29.0 / 1.5.22.0

Released: 4/23/2020 / 4/20/2020

Released for download.

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

Functional changes ADSyncAutoUpgrade

• N.A.

–

Fixed issues:

• From v1.5.29.0: This hotfix build fixes an issue introduced in build 1.5.20.0 where a tenant administrator with MFA was not able to enable DSSO
• From v1.5.22.0: This hotfix build fixes an issue in build 1.5.20.0 if you have cloned the In from AD – Group Join rule and have not cloned the In from AD – Group Common rule.

–

I ran the MSI and upgraded from the previous version without any issues and ran at least one scheduled sync cycle! I do not have auto-upgrade enabled, therefore unfortunately I cannot say anything about this version.

–

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/ ###################
————————————————————————————————————————————————————-