Where's the source!

SauceIn this post I will talk about data (aka the source)! In IAM there’s really one simple concept that is often misunderstood or ignored. The data going out of any IAM solution is only as good as the data going in. This may seem simple enough but if not enough attention is paid to the data source and data quality then the results are going to be unfavourable at best and catastrophic at worst.
With most IAM solutions data is going to come from multiple sources. Most IAM professionals will agree the best place to source the majority of your user data is going to be the HR system. Why? Well simply put it’s where all important information about the individual is stored and for the most part kept up to date, for example if you were to change positions within the same company the HR systems are going to be updated to reflect the change to your job title, as well as any potential direct report changes which may come as a result of this sort of change.
I also said that data can come and will normally always come from multiple sources. At typical example of this generally speaking, temporary and contract staff will not be managed within the central HR system, the HR team simply put don’t care about contractors. So where do they come from, how are they managed? For smaller organisations this is usually something that’s manually done in AD with no real governance in place. For the larger organisations this is less ideal and can be a security nightmare for the IT team to manage and can create quite a large security risk to the business, so a primary data source for contractors becomes necessary what this is is entirely up to the business and what works for them, I have seen a standard SQL web application being used to populate a database, I’ve seen ITSM tools being used, and less common is using the IAM system they build to manage contractor accounts (within MIM 2016 this is through the MIM Portal).
There are many other examples of how different corporate applications can be used to augment the identity information of your user data such as email, phone systems and to a lessor extent physical security systems building access, and datacentre access, but we will try and keep it simple for the purpose of this post. The following diagram helps illustrate the dataflow for the different user types.
IAM Diagram
What you will notice from the diagram above, is even though an organisation will have data coming from multiple systems, they all come together and are stored in a central repository or an “Identity Vault”. This is able to keep an accurate record of the information coming from multiple sources to compile what is the users complete identity profile. From this we can then start to manage what information is flowed to downstream systems when provisioning accounts, and we can also ensure that if any information was to change, it can be updated to the users profiles in any attached system that is managed through the enterprise IAM Services.
In my next post I will go into the finer details of the central repository or the “Identity Vault”
So in summary, the source of data is very important in defining an IAM solution, it ensures you have the right data being distributed to any managed downstream systems regardless of what type of user base you have. My next post we will dig into the central repository or the Identity Vault, this will go into details around how we can set precedence to data from specific systems to ensure that if there is a difference in the data coming from the difference sources that only the highest precedence will be applied we will also discuss how we augment the data sets to ensure that we are also only collecting the necessary information related to the management of that user and the applications that use within your business.
As per usual, if you have any comments or questions on this post of any of my previous posts then please feel free to comment or reach out to me directly.

Consideration for multi-forest synchronisation with a resource Exchange forest

Azure AD Connect has come a long way from the early days of DirSync, and multi-forest directory synchronisation is a great step forward, with the ability to synchronise an account forest and Exchange resource forest to Office 365 meeting the needs of many organisations.

Joining linked mailboxes

To provide synchronisation of an account forest and an Exchange resource forest AAD Connect matches accounts across forests using the same attribute used by Exchange, matching the linked mailbox account’s msExchMasterAccount attribute value with the objectSID value of the account in the other forest to join them. I’ve represented this flow here:

Linked mailbox matched with authentication account

This joining process is great for ensuring a single identity is synchronised to Azure AD where you have linked mailboxes going on and this works for most organisations out there.

Houston, we have a problem.

I’m going to draw out a scenario:

AAD Connect is installed and configured to synchronise two AD domains as shown above, and Exchange hybrid is configured with the on-premises Exchange Organisation in the resource forest. All the on-premises mailboxes have been moved to Exchange Online, and an Exchange 2013 server remains on-premises to provide administrative capability(when an account in Azure AD is synchronised from on-premises, the on-premises user object is the source of authority and so it is not possible to update values such proxy addresses in Azure AD).

Now. A new starry-eyed employee joins the organisation, at which point an account is created in the account forest, let’s call it newEmployee@account.local. As part of the on-boarding process, a linked mailbox would have been traditionally created in the resource domain as newEmployee@resource.local.

However, with Exchange Online in place, it doesn’t make sense to create a linked mailbox on-premises, only to move it to the cloud once it’s created. So the account in the resource domain is created as a remote mailbox, either through the Exchange 2013 control panel, or using the Exchange PowerShell cmdlet New-RemoteMailbox.

Then we wait for AAD Connect to work its magic…

…and two accounts appear in Office 365. One with a mailbox, and the other without. The new employee is also unable to connect to their new Exchange Online mailbox as access is denied. This obviously is not a good place to have arrived at!

Looking at the linked mailbox joining process in AAD Connect I discussed earlier, you may be able to see why this is occurring. A remote mailbox is not the same as a linked mailbox. As a result,  Azure AD Connect does not join the accounts newEmployee@account.local and newEmployee@resource.local with the result that two accounts are created in Azure AD.

What are the options?

There are two ways forward for you from here:

  1. Continue to create a linked mailbox on-premises and then move the on-premises linked mailbox to Exchange Online as a second step
  2. Modify the newEmployee@resource.local account through some ADSIEdit jiggery-pokery.

Now I’m going to stop here and recommend you stick with the first approach here. It requires an extra step, but so does the second option. Option 1 is also a solution which allows for account and mailbox creation using your existing administrative tools. Getting at AD object attributes, which used to be hidden in your management tools, is a lot easier these days. That doesn’t make it any safer to do without a good understanding of what it is you’re planning to do.

I was presented with an additional complication recently, where a customer had an incumbent vendor providing a managed service for email and charged extra for every mailbox created in the on-premises Exchange environment. Not wanting to give away more money than they needed to, the customer did not want to create a linked mailbox first when on-boarding new users.

Luckily the customer I was working with has FIM in place allowing them to populate AD user object attributes consistently and correctly (this ain’t something I’d be wanting to do manually).

Given AAD Connect matches accounts with the msExchMasterAccountSID and objectSID values, you can manually update newEmployee@resource.local so that it’s msExchMasterAccountSID equals the objectSID for newEmployee@account.local and all will be good right?

Well, the answer is no…

It turns out that AAD Connect checks that the AD object is a linked mailbox before it attempts to match its msExchMasterAccountSID value. This is done using the recipientTypeDetails attribute (a value of 2 designates a linked mailbox).

Account matching process

So, there are two attributes which need to be updated on the resource forest account, they are:

  1. msExchangeMasterAccountSID with the objectSID of the authentication account
  2. recipientTypeDetails with a value of 2

Once you’ve got these being updated you should be set.

Jason.

Failure Upgrading DirSync with a Remote SQL Instance

I’ve just recently come across an issue when performing the upgrade procedure for the Microsoft Azure Directory Sync tool with a remote SQL database. The procedure seems simple enough at first glance and is documented here.

To break down the process it is only a few simple steps:

Install the new dirsync –

Dirsync.exe /fullsql

Click next on the upgrade wizard until complete

Run Powershell –

Import-Module DirSync

Run the following PowerShell cmdlet to update the backend database –

Install-OnlineCoexistenceTool -UseSQLServer –SqlServer <ServerName> -Upgrade -Verbose -ServiceCredential (Get-Credential)

The Issue

This particular issue will occur during the upgrade procedure on the PowerShell step Install-OnlineCoexistenceTool with the following error –

VERBOSE: Running InstallOnlineCoexistenceTool in Upgrade mode.

Install-OnlineCoexistenceTool : The SQL Server Instance specified during an upgrade must match the previously

configured SQL Server Instance. Expected SQL parameter for upgrade were Server: Instance:

At line:1 char:1

+ Install-OnlineCoexistenceTool -UseSQLServer -SqlServer servername …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (Microsoft.Onlin…CoexistenceTool:InstallOnlineCoexistenceTool) [Inst

all-OnlineCoexistenceTool], DirectorySyncInstallException

+ FullyQualifiedErrorId : 201,Microsoft.Online.Coexistence.PS.Install.InstallOnlineCoexistenceTool

The first time I got this error, I assumed that I had provided incorrect syntax for the cmdlet and proceeded to try every variant possible. Nothing seemed to satisfy the shell so I started to look elsewhere. Next step along the process was to go look at the possible FIM configuration settings listed in the registry that I knew of –

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters

I found the two keys that I ‘presumed’ that the cmdlet was using for verification –

Server = <Server FQDN>

SQLInstance = <blank>

Based on these two key values I then went back to my shell and tried to enter the syntax exactly as I could see it. I thought that maybe because my ‘SQLinstance’ value was empty, PowerShell was finding it hard for me to process this in the cmdlet of a null value. To cut a long troubleshooting story short, it didn’t matter. I had stared at the cmdlet long enough and resided to the fact that it wasn’t happy about the values stored elsewhere, and I wasn’t going to find them any time soon.

Cause

There was an issue in previous versions of DirSync where the following two registry keys were not written when installed using the /FullSQL flag –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\storeserver

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\SQLINSTANCE

DirSync attempts to read these keys when performing the in-place upgrade to verify the SQL Server and Instance name, and then the upgrade fails when it cannot find them.

Solution

Copy value data from key –

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters\Server\<ServerName>

Create a new string value of –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\storeserver

Paste the value data from above

Copy value data from key –

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters\SQLInstance

Create a new string value of –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\SQLINSTANCE

Paste the value data from above (if any)

Note: For me this key was blank as the default instance was being used not a named instance.

Re-run cmdlet –

Install-OnlineCoexistenceTool -UseSQLServer –SqlServer <ServerName> -Upgrade -Verbose -ServiceCredential (Get-Credential)

Expected Output –

PS C:\Windows\system32> Install-OnlineCoexistenceTool -UseSQLServer -SqlServer <SQL Server NAME> -Upgrade -Verbose -ServiceCredential (Get-Credential)

cmdlet Get-Credential at command pipeline position 1

Supply values for the following parameters:

Credential

VERBOSE: Running InstallOnlineCoexistenceTool in Upgrade mode.

VERBOSE: Skipping Microsoft SQL Server 2012 SP1 Express installation.

VERBOSE: Upgrading Microsoft Forefront Identity Manager

VERBOSE: AbandonKeys: C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\Bin\miiskmu.exe /q /a

VERBOSE: AbandonKeys: C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\Bin\miiskmu.exe /q /a ExitCode:0

VERBOSE: Uninstalling msiexec.exe /quiet /l miisUninstall.log /x {C9139DEA-F758-4177-8E0F-AA5B09628136}

REBOOT=ReallySuppress…

VERBOSE: Please wait while the Synchronization Engine is uninstalled.

VERBOSE: The Synchronization Engine was successfully removed. Msiexec /x returned 0.

VERBOSE: Installing msiexec.exe /quiet /l “C:\Program Files\Windows Azure Active Directory Sync\miissetup.log” /i “C:\Program Files\Windows Azure Active Directory Sync\SynchronizationService.msi” INSTALLDIR=”C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS” storeserver=<servername> serviceaccount=<credentials> servicedomain=<domain> groupadmins=FIMSyncAdmins groupoperators=FIMSyncOperators groupbrowse=FIMSyncBrowse groupaccountjoiners=FIMSyncJoiners grouppasswordset=FIMSyncPasswordSet servicepassword=<Hidden>

REBOOT=ReallySuppress…

VERBOSE: Please wait while the Synchronization Engine is installed.

VERBOSE: The installation of the Synchronization Engine was successful. Setup returned 0.

VERBOSE: The Synchronization Engine was installed successfully.

VERBOSE: Installing msiexec.exe /quiet /lv “C:\Program Files\Windows Azure Active Directory Sync\MSOIDCRLSetup.log” /i “C:\Program Files\Windows Azure Active Directory Sync\Msoidcli.msi” REBOOT=ReallySuppress…

VERBOSE: Please wait while the Microsoft Online Services Sign-in Assistant service is being installed.

VERBOSE: The Microsoft Online Services Sign-in Assistant service installation succeeded. Setup returned 0.

VERBOSE: The Microsoft Online Services Sign-in Assistant service was installed successfully.

VERBOSE: Installing msiexec.exe /quiet /lv “C:\Program Files\Windows Azure Active Directory Sync\dirsyncUpgrade.log” /i “C:\Program Files\Windows Azure Active Directory Sync\DirectorySync.msi” TARGETDIR=”C:\Program Files\Windows Azure Active Directory Sync\” REBOOT=ReallySuppress…

VERBOSE: Please wait while the Directory Sync tool is installed.

VERBOSE: The Directory Synchronization tool install succeeded. Setup returned 0.

VERBOSE: The Directory Synchronization tool was installed successfully.

 

Once again we must make a big thankyou to Yaran at Microsoft PSS for helping me resolve this issue.

Follow ...+

Kloud Blog - Follow