Getting Started with The Boring Toolbox #3: Learn about the various health monitoring insights and features you will find on…
Close
Close
Close
Close
Why, you may ask? Well, the aim here is to delegate the management of your XProtect system, including certain Windows services, IIS application pools, and databases, to a domain user or a “service account”. This is typically done to enhance security, improve operational efficiency, and streamline user permissions and access. Not to mention allow you to deploy Milestone in Federation.
By integrating XProtect with Active Directory, you leverage the benefits of centralized user and access management, which can greatly simplify how you control who can do what within your system.
However, this is a complex process that involves changes at the system and database level, hence should be done carefully and only attempted by experienced system administrators.
Let’s be honest, if you are considering updating your Milestone XProtect server to use an Active Directory instead of a workgroup, you probably have a good reason why and you don’t need me to tell you what it is. But just in case you are looking for further validation, here are the main benefits that I see from making this change.
For me, the most significant advantage of integrating Active Directory has been simplified authentication.
I’ve seen the relief on my team’s faces when they realize they can use their domain credentials to access the Milestone system.
No more juggling multiple passwords – a single set of credentials does the job.
Another critical aspect I’ve appreciated is how it gives me one less thing to do during the off-boarding process.
When a user is removed from the domain, their access to Milestone is automatically revoked.
Bada-bing, bada-boom.
Consider this a proactive step in maintaining security and ensuring that system access is strictly controlled.
So, you’ve initially installed Milestone as part of a workgroup or standalone system, but now you want to introduce domain users.
Now, it might seem like adding the Milestone system to the domain would be enough, but it’s not; it’s only part of the equation.
Even if you’ve added it to a domain, if you don’t update all the Milestone services to use a domain service account (a domain-bound username and password), you’ cant add domain users to the Milestone system.
I learned this the hard way.
You know that sinking feeling you get when you realize you’ve made a huge mistake. Let’s try to avoid that, okay?
Use your street smarts. Back up your system before you start this process.
As I already mentioned, there is little to no documentation on this process besides what you are reading right now. AKA if you mess it up, there aint no where else to turn.
This process that I’m sharing with you is what worked for me but its by no means fool proof.
So, don’t be a fool. Control the risk and set yourself up for success by creating a plan B.
By this point, you may be thinking, shut up Ronen and tell me how to do it already. And if so, click here to SKIP AHEAD to the step-by-step instructions.
If you’re still with me, hopefully this next section will save you a headache or two.
I’ve detailed my steps and missteps below so you can learn from my mistakes and understand what issues I ran into and how I got to the final, successful result.
My initial approach was to update the Windows services and the IIS app to use the domain user, replacing the network service that they were initially configured to use and then update permissions on the database.
Knowing that handling database permissions could prove challenging, I decided to be proactive and backed up each database to safeguard against any missteps.
My original plan was to observe the permissions assigned to the current database owner user, add my service account to the database and, and assign them identical permissions. Considering that Milestone uses about five databases and Boring utilizes one, it seemed like a reasonable approach.
Despite my careful planning, this approach did not yield the expected results. The Milestone services would not start. When I dug deeper, I found that the DBO user still displayed the old user, not the one I had just added.
To rectify this, I intended to switch the old user with the new one using an ‘ALTER’ command that I found during a Google search. However, when I tried to execute this, SQL Server informed me that the user already existed and couldn’t be altered.
Stuck in this loop, I attempted to remove the newly added user, but SQL Server wouldn’t permit this either. At this point, I restored the old database, effectively removing the new domain user I had attempted to add. Using the ‘ALTER’ command again, I managed to change the DBO owner to the new domain user – a promising development.
I then re-registered the services per the instructions. During this process, an error emerged stating not all services were registered. It wasn’t clear which ones were causing the issue. Despite multiple attempts to re-register, the error persisted.
At this point, I took the manual route: I started each service individually and then re-ran the re-register command. This time, everything fell into place, and the solution worked as expected.
The path to this solution wasn’t exactly straightforward, but sometimes you have to traverse the long road to truly understand the terrain. In the end, I managed to configure Milestone XProtect to use an Active Directory – and learned a thing or two along the way. I hope that sharing my journey can help you avoid some of these detours.
Begin by creating a domain user for your service account. This user will handle all your Windows services, IIS application pools, and take ownership of all your databases.
Next, update the rights for the service account on all XProtect Management Server:
The next step involves changing the ownership of the database:
To change the ownership, run a new query with the following command:
USE [master]
GO
ALTER AUTHORIZATION ON DATABASE::[YourDatabase] TO [NewOwner]
GO
Replace [NewOwner] with the new domain service account username.
Run this command for each of the Milestone and Boring databases, replacing [YourDatabase] each time with the name of the database you’re changing.
For example, if you’re changing the ownership for the “Surveillance” database using a domain user “MyDomain\svc_milestone”, the command would look like:
USE [master]
GO
ALTER AUTHORIZATION ON DATABASE::Surveillance TO "MyDomain\milestone"
GO
Now, it’s time to change the identities of the services and application pools. You’ll need a tool called ‘Identity Changer’ for this. Here’s how you can get it:
After downloading and opening the ‘Identity Changer’:
So there you have it – our ultimate guide to understanding, installing, and configuring Milestone Open Network Bridge. The possibilities of what you can achieve with this tool are virtually endless, but we hope this guide provides a solid foundation on which to build. For further insights and discussions on Milestone Open Network Bridge, feel free to explore our other posts and resources.
After changing the database ownership:
If you encounter an error stating that some services did not register, manually start them all and run the registration process again.
Finally, test the functionality to make sure you have full operation. If everything is working correctly, congratulations! You’ve successfully updated your Milestone XProtect server to use an Active Directory domain.
Remember, these steps may seem complex, but they are crucial for the security and operation of your server. Take your time, and if you encounter any issues, don’t hesitate to reach out to your community of fellow security admins.
We’re all in this together.
Then you’ll LOVE my [Not] Boring Newsletter!
Once a month, you’ll receive sec-tech tips, things that make you think, dad jokes, trivia, and other stuff you’ll love.
Subscribe now!
Your go-to XProtect eXPerts. We learn the technical stuff that will save you time and make it less boring.
Your go-to XProtect eXPerts. We learn the technical stuff that will save you time and make it less boring.
Getting Started with The Boring Toolbox #3: Learn about the various health monitoring insights and features you will find on…
Getting Started #2: Learn how to configure your parent and managed sites as well as connect Boring to Milestone XProtect…
Getting Started #1: This tutorial will teach you how to install The Boring Toolbox on your server and client.
Subscribe to get a monthly dose of security & surveillance industry news and insights, Milestone VMS time-saving tricks, tips for hacking your way out of boring work sent directly to your inbox!