I’ve recently been spending more and more time looking into various cloud technologies such as AWS and Azure. One of the projects I’ve been working on required the on-premises active directory to be extended to Azure to allow for a future introduction of various Office365 elements.
The process for doing this is fairly easy as it’s just a matter of installing the Azure Active Directory Connect tool onto a server, creating the domain in the Azure portal and then waiting for Azure AD connect to Sync.
For most installs, the bundled SQL express setup will do the job just fine. Microsoft does recommend that any AD installation that has more than 100,000 objects use a full SQL server install rather than the Express install.
Finding out how many objects AD contains is easy enough, Microsoft provides a one line piece of PowerShell to find out:
|
1 |
Get-ADObject -Filter {name -like '*'} -SearchBase 'CN=Schema,CN=Configuration,DC=Fabrikam,DC=COM' -ResultSetSize $null | Measure-Object |
If it’s over 100,000 objects or if the AD environment has the potential to grow that big then you’ll want to install to full SQL server and this is where the fun starts because the installer really is not very well designed for such installations. In fact, I’d go as far as saying that the custom installer elements have not been at all well tested.
With most installs that require a database, the DBA team create a suitably named database then they’d create a user and then make that user DBO (database owner) for that database and only that database and run any SQL scripts that the installer may require. During installation, it should be possible to put in the name of the database and the user that has DBO and everything works.
This approach ensures that the DBO user on that database can only make changes to that database and no other. It’s something of the fail-safe method.
Except for Azure AD Connect. This installer has to be rather difficult about the whole thing.
The installer is actually two installers. The first time the installer is run it’ll probably complain about a few missing components. It doesn’t offer to install them for you like some installers do, nope, it’ll just dump you out of the installer.
Once you’re over that hurdle, the next part is to select custom or express. For most locations express is probably fine but remember that this option will install SQL Express and that might use up more resources than you’d allocated plus there is the Microsoft 100,000 object limit recommendation.
The first time I installed AD connect I installed it onto a domain controller. After all, it seemed sensible. The domain controller is where I have all the user data and, if I don’t use SQL express then the resource usage of the AD connector will not be that high.
Before I ran the installer, I created a service account in Active Directory. I gave the account domain admin as not only does it need to read the user accounts but it needs to read the password database to sync the passwords to Azure. It doesn’t decrypt them or anything like that, it just pushes them to Azure. As this is a one-way sync from on-premises to Azure I could probably remove it from domain admins and give it some delegated rights. During the install, there are also options to have password changes and group changes that are made at Azure to sync back to on-premises AD. Clearly, this would require more rights to AD.
I duly selected custom installer and was asked for the name of a SQL server and a service account.
I created the service account and called it “AzureADConnector”. The installer wasn’t having this though as it requires the username to be in domain\username format. Ok, not a huge issue to fix but annoying as it would have been nice if I didn’t need to have the domain\ bit but it’s not a big deal.
With that minor issue fixed I hit install and nothing… Well, aside from a little red bar popping up.
Believe it or not, the red line is an error. It should have some text to the right but for whatever reason, MS haven’t coded the error text. Since I wrote this a newer version has come out and I tested it again but it still has the same bug.
This “error” caught me out. I didn’t have a clue what it needed, what the problem was or how to fix it.
To cut a very long and frustrating story short, that error is because I’m logged in as a domain admin who is also a SQL admin but I’m not logged in as the service account that I have listed under the service account dialog box name.
Even though the service account has DBO rights to the database and it’s a domain admin it’s not enough. I actually need to be logged in as the ‘AzureADConnector” user.
But it doesn’t end there. The installer cannot use a database name chosen by the IT staff or the DBA’s. The database must be called “ADSync”. But it doesn’t stop there either!
Create a database called ADsync and give the service account DBO rights to it and it’s still not enough as you’ll get this error:
The account needs to have DBO to the master database as well as have master as the default database.
The installer actually insists on creating the database in SQL itself. I can see no good reason that it needs to do this when a simple SQL script could be used to setup the database for AD Connect to use.
Once done it’s possible to remove the DBO rights from the Master database and it’ll all work fine but I don’t find that acceptable. Why is this software dictating what I call the DB and that it has to create it? I suspect somewhere there are hardcoded references to “ADSync” that haven’t been fixed yet.
In summary, if you’re doing a custom install of Azure AD connect because you want to use a full install of SQL Server you’ll need to ensure that you do the following:
- Create a service account that is either a Domain Admin or has delegated rights for the various Azure AD features that you wish to use. Make the user local admin if you’re installing AD Connect onto a server that is not a domain controller.
- Make that user DBO of the Master database on the SQL server and set “master” to be that users’ default database.
- Logon to the server with the service account name that you’ve created for the account.
- Install away.
Related materials:
