Questions we’re asked by new Centrify Server Suite for Windows (CSS) customers often center on the “how” of implementing granular Windows privilege management. How do we deploy it? What are some of the best practices you’ve found? How can we get some broad controls in place now, without waiting to boil the ocean of every last detailed right for each of our hundreds of admins?
In this blog, I’ll try to give some straightforward answers.
Let’s start by taking a common implementation use case and learning how to configure Centrify Server Suite for Windows to handle it.
The use case: Enable a user/admin to install with local admin rights any application digitally signed by Adobe.
Server Suite for Windows can do this easily. CSS uses role-based access control to manage the assignment of privileges (the rights to elevate privilege on applications), so we’ll create a role, assign it to a user, and then add the rights to the role. From there, the Centrify agent will automatically pick up the user’s role assignment on login (or periodically during a user session).
- Create a role.
- Assign the role to a user.
- Add the application right to the role.
- Done – the Centrify client gets the new role and right automatically for the user.
In the CSS Access Manager console, we’ll create a new Role Definition named “Adobe Application Install.”
We’ll assign the role to one of our users from Active Directory (Iba Kendall), and to an Active Directory security group comprised of IT contract staff (IT Staff – Contract).
We’ve created the new role and assigned it to our user and group. Now all we need to do is create the application right and add it to the role. Let’s create a new application right and give it the name “Everything signed by Adobe.”
We’ll set the right to elevate the user’s privilege to local admin when launching an Adobe installer or application.
When we create the application right, we’ll use a feature that we call the application rights builder. It’s in the Match Criteria tab of the application rights dialog.
These definition settings let us match an executable or other type of application with specific criteria of the application itself; hence the name “Match Criteria.” Any application that matches the criteria we enter into this dialog can be launched by the user with local admin privileges.
Rather than enter the digital signature information manually, we’ll pick an existing Adobe installer and ask the rights builder to fill in the information for us. We’ll check any criteria we want to use, and ignore the rest. Here’s what the application rights builder filled in for us.
And here’s the modified version that will allow the user to launch *any* executable signed by Adobe, with local admin privileges elevated by Centrify. We turned off all the criteria except the Publisher (the owner of the digital signature on the file), and deleted everything except the common name for which we made the match “contains” rather than “is.” We entered a description “Adobe Executables,” as this set of criteria will apply to EXE files.
Last, we’ll add the new application right to the role.
And we’re done. The next time Iba Kendall (or anyone in the IT Staff – Contract security group) logs into a computer running Centrify, she can right-click on an Adobe executable and Centrify will grant privileges to run it as local admin. In this case, she’ll install Adobe Flash for non-IE browsers using the “Run as Role…” menu item from Centrify.
You can put multiple match criteria into a single application right, and you can open an existing set of criteria, make a change, and save it to a different name in the same right. That makes it easy to use one set of match criteria as a template for more – for example, to add the right to run applications signed by another company simply by changing the common name on the digital signature in the Publisher field.
I hope this has been a useful introduction into one part of CSS that makes it straightforward to rapidly deploy a broad set of application rights (all Adobe executable files) to selected users and groups. This can be a key best practice for a Centrify Server Suite for Windows initial deployment, because it enables you to start your implementation of a least privilege model sooner rather than later.