This is a cross-post of the article that I wrote for Mike Meyer over at Aspen Systems. Go check out his site – He’s been around the virtual block as long as I’ve been doing RES.
One of the original design features of RES AM back around 2004, was that it was originally built to be completely domain independent, meaning no dependency on any DC, domain account or other AD structure or object. This is still the case, however as things moved along and more and more people got both familiar and comfortable with Windows Authentication on SQLserver and as a whole – obviously something had to be changed. During the last couple of years some customers quite simply said; Look RES we really like the Automation Manager product, but nothing goes into our datacenter unless it supports Windows Authentication. That prompted the change in the product a while back, however it’s not obvious when you install the product. For reference, the procedure can be also found in the Automation Manager Admin Guide, page 14-16.
Max’s Preinstall Rant™
While Microsoft clearly recommends using Windows Authentication wherever possible, that it’s more secure, etc – let’s agree on the main implication: It’s one more thing you are making dependent on Active Directory. Let me be crystal clear: I am not some NDS relic, touting anti-AD rhetoric. While Active directory certainly was a huge leap forward from the days of old with NT4’s user-management, at the end of the day, any directory service, AD included should in my humble opinion be treated like a glorified phonebook. This especially rings true since the policy delivery engine still hasn’t changed much the last 15 years, which has left ample room for other configuration engines such as Workspace Manager to flourish. Sure, if you insist on gargling the Kool-Aid, you without a doubt can throw everything but the kitchen-sink into AD, yet anyone who’s ever had the displeasure of cleaning up someone else’s mess knows that the more stuff you put in there, the harder it gets to find your way around policy launched scripts, loopback processing, inheritance and in this case dependence. In many cases a complete do-over is warranted if an AD becomes sufficiently messed up. You’ll be more secure, but my last argument is this; sure Windows Authentication is absolutely more secure than SQL authentication, but let’s keep in mind what we’re securing here. It’s not your financial records or user data, just automation jobs. All I’m saying is; keep a firm grasp on reality and don’t go overboard in security just for the the sake of security.
So presuming you completely disagree with me on the above, fine – let’s roll up our sleeves and see how Windows Authentication works with RES Automation Manager. You will be jumping through a lot of hoops, but when you’re done, you will be able to tick off the yes-I’m-using-windows-authentication-on-all-things-AM box..
I will presume that you already have a MSSQL server. For ease of use and to hit as large a target audience as possible, I’m doing this on a Server 2008 with SQL Server 2008 as well. It’s pretty much the same bag on Server 2012. Anyway, you can change the SQL authentication method on both the database level and the server, so if you are currently in mixed mode and decide to flip the switch as a whole on the server to Windows Authentication only, make sure that you understand the consequences, say if there are apps out there still using SQL authentication in your environment. If you’re in doubt, just configure windows authentication on the RES Automation Manager database.
To use Windows Authentication, all the consoles and dispatchers must be in a domain which are in the same forest or have trust relations established one way or another. This is typically the case for a single customer. However if you are planning on using AM across multiple domains in a multi-tenant structure and want to have your cake and eat it too, you need to look at using SQL authentication, as separate and non-trusting domains/forests per design are not meant to talk to each other. ADFS should work fine, as seen from the products point of view it just another trust.
The Automation OU:
Since the computers running the AM consoles and your top-level dispatchers, will be connecting directly to the AM datastore, it would make sense for you to put these in a common OU. Here a GPO can be applied to govern access to the database, and we’ll do that further down. I will presume that you have the OU in place already. If not, this would be a great time to create one. In the event that the computers running the dispatcher/console component’s can’t be moved in the OU structure, it’s probably because you’re using them for something else. This is of course a matter of design and we can talk for days about what you should and should not do, but then we’ll never get anywhere. Just suffice to say, things are a lot easier if you don’t start running the dispatchers on servers already allocated to other tasks, so things start going bump in the night when you move these computers in the OU structure. Morale of the story: Keep it clean!
Standing up a service account policy:
If you don’t already have one already, perhaps now would be a great time to create a generic Service Accounts group in your domain that gives the logon-as-a-service User Right. At some point before, you have probably noticed that when you manually change the logon credentials of a NT service, you get the popup; “The user FooBar has been granted the right: Logon as a service. These can be viewed in Administrative Tools | Local Security Policy | User Rights Assignment | Logon as a service. However we are going implement everything through GPO’s.
Create a regular group in AD, let’s call it Service Accounts Group. Put in the group description field that members will be given Logon As A Service user-right. Yes, I’m a stickler for proper documentation. Learn to love it :)
- If we presume that all service accounts will need administrative credentials, then you could consider adding the Service Accounts Group to Domain Admins, however the more conservative play is to add it to the local administrators group on member servers that will be running the RES components. If you do this, do not add any users to the Service Accounts Group just yet.
- In Administrative Tools | Group Policy Management, create a new policy under Group Policy Objects. Let’s call it Service Account Auth Prereqs or something equally byzantine. You will need to add two policy to your new GPO.
- Policy #1: Under Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | User Rights Assignment > Logon as a service. Add your Service Account Group here and be sure to check the “Define these policy settings” checkbox. The net result should look like this:
- Policy #2: Under Computer Configuration | Policies | Windows Settings | Security Settings | Restricted Groups. In here, you want to first browse for the Service Account Group. Once you’ve done that, add the group “Administrators” (without quotes) to the lower dialog, titled “This group is a member of:”. This will effectively put the Service Accounts group into the local Administrators group on every machine that gets hit by this policy. This policy should look like this:
Note1: Remember that RES Workspace Manager too requires it’s service account to have admin rights if you are planning on using Windows Authentication.
Note2: Don’t freak out if the Logon as a Service policy doesn’t show up in your GPresult view immediately. It will show up after you add the second policy in step 5 above and refresh the console view. Once everything is in place it should look something like this:
- Now would be a fine time to add a domain service account to the Service Account Group. Let’s call it RESAMServiceAcct.
- Last step with the GPO stuff is to link the GPO to the Automation OU we discussed previously. In the Group Policy Management console, right-click on the OU where the dispatchers and console computers are in and chose “Link an existing GPO…”, then chose the Service Account Auth Prereqs. When everything is configured correctly, you should be looking at something like this:
Preparing the database:
- Now it’s time to configure things in the SQL Management Studio. Go to the security node, right-click and create a new login. Hit the search button, then be sure to hit the Object Types button as the selector does not look for domain groups per default. Once configured search for the Service Account Group you’ve created earlier. While you’re at it, you might as well add the Domain Admins or any other group where users need to have initial access to the console. Remember, you can always lock things further down later in the Automation Manager’s security roles and trusts.
- It’s now time to create a new database. I do not subscribe to the default values recommended in the AM Admin Guide, suggesting the initial database should be 150mb/autogrow 25MB. Taking into account that a) the default payload of the database-stored components of Automation Manager itself is almost 150MB on it’s own, and b) presuming you’ll want like me to take advantage of database stored resources (firewall traversal and bandwith throttled payload delivery), I’d suggest you bump up the size to min 300MB + the size of the expected resources you’ll be uploading, and autogrow with 50MB. The logsize doesn’t matter for Automation Manager as it’s not dependent on a transaction log. You can leave that to the default 75MB/10MB autogrow.
- Once you’ve created the database, go back to the logins node in the SQL Studio and open the properties of the Service Account Group. Select the User Mapping page and check the db_owner role at the bottom of the screen. You may wish to repeat this step for Domain Admins as well, presuming you created a SQL login for that group as well in step 8. Last, if you are later logging in with another non-domain admin account and launching the installation of RES Automation Manager, you need to repeat this step for that account as well.
Note: If you’re planning on using accounts from another domain, first ddd Domain Admins from the other domain (or any other group of RES Automation Manager administrators that use the RES Automation Manager Console) and the respective service account group to a domain local group in the current domain. Then inside SQL studio, add the domain local group to the database as db_owner as described above.
Installing RES Automation Manager:
- Now it’s time to install RES Automation Manager with the installation .MSI with a user that has the role “dbo”. That would be one of the users you added in step 10 above.
- Next, next, finish through the installation which will install the AM console on your computer. When finishing up the install, chose the option to start the RES Automation Manager Console or just launch it manually when ready.
- The next part is REALLY IMPORTANT. When the AM console launches first time, it will ask you if it should create a new database. Do NOT create a new database, but connect to the one that you just created, by providing the required information and select Windows Authentication in the Database Authentication dropdown. Be sure to specify the Service Account as DOMAIN\username, and when ready, hit Connect.
- Once connected to the database, RES Automation Manager will ask for confirmation first, and when you give it the green light, AM will create the required tables in the empty database. After that it’s business as usual in AM. Remember you can deploy AM Agents to your heart’s content, regardless of the database authentication method as the AM agents never speak directly to the AM datastore.
Wrap-up and closing notes:
This concludes the setup of Automation Manager. All that needs to be discussed is what to do if you are converting an existing installation from SQL Authentication to Windows Authentication. This is typically the case if you’ve stood up a lab which you are comfortable moving into production. Follow these few steps in order to get things prepared.
- On the properties of the existing database, switch the authentication mode for the RES Automation Manager Datastore from mixed mode authentication to Windows Authentication. If you are uncomfortable making the switch in one go, you can also leave this step to the end, effectively allowing the database to be accessed both via SQL and Windows Authentication.
- Follow the steps as described above until step 7. Skip steps where you create a new database and install the software. Instead just start the AM Console and at Infrastructure | Datastore | Setup | Database, change Database authentication to Windows Authentication. Then provide the service account credentials and click Connect, whereafter the console will restart.
- Any and all existing consoles and dispatchers will still be talking via SQL Authentication to the database, so to switch these components, go to the properties of each dispatcher and console and chose Repair. This is only necessary to do on already deployed components, as every new AM console and dispatcher that you deploy will run using the provided service account credentials in the Database node. If you at a later stage change the service account name, you will have to repair all the dispatchers and consoles once again.
- Keep in mind that if you can’t get the dispatchers and agents to connect, check out the Windows Event log. You can also configure a detailed Automation Manager Trace log (details here) if you suspect it’s something out of the scope of Windows authentication itself.
Finally, according to the Admin guide, Windows Authentication for dispatchers and consoles are not supported on Domain Controllers and Small Business server. While I wholeheartedly agree that is a poor design choice to lob either onto a production DC, for the record it seems to work nicely in my Server 2008 lab. – But that still doesn’t mean that you should put it into production that way, nor that RES would support it if you did. Nuff’ said.