As a product manager for Server Suite, I’m pleased to tell you about our latest version, Centrify Server Suite 2016, which we just released for general availability on Monday, December 21. But before I do, let me say that we’re very, very excited about this product. The reason is, we think this is the biggest and most important release in some time. From a feature and function perspective, there’s a lot of new stuff that people will want to take advantage of. Along with that, this is the first time we’ve built in direct integration between Server Suite and our cloud service offerings. This is enabling a completely new type of functionality for customers that we think will be really, really important for securing enterprise identities and for protecting organizations from malware and outside/inside attacks.
There’s a half-dozen major new features, and there are dozens and dozens of other enhancements. And we’ll try to cover a lot of them on the blog over the coming weeks. I’d like to focus on just a couple of them right now.
First of all, multi-factor authentication (MFA) is gaining a lot of popularity and interest from IT and security teams, because it does one thing that a lot of other methodologies can’t do — stops automated attacks and automated malware dead in their tracks. Because even if a piece of malware steals a password, or tries a privilege escalation attack using cached credentials across a network, it has no way to respond to MFA challenges. So basically, MFA stops those types of attacks.
We have a tremendous amount of interest in MFA from our customers. We’re providing a new MFA feature today, in Server Suite 2016, starting with UNIX and Linux systems. Centrify administrators can challenge their IT admins with MFA both at server login (console and/or remote SSH) and at any attempt to elevate privilege to run a particular command (e.g. using the dzdo command). This is all enabled via an integration with between Server Suite and our Centrify Identity Platform. The Identity Platform does all the heavy lifting with MFA delivery and policy, and Server Suite does all the enforcement.
One of the great things about this, from the IT admin’s perspective, is that there’s no change to the way they normally work. They don’t have to log into a Web portal, they don’t have to get a new hardware token, they don’t have to learn anything new. All they have to do is respond to the MFA challenge that Server Suite presents to them on the login, or when they try to elevate privilege. There’s a new prompt that will be generated for them right there on the shell’s command prompt that says, “hey, you’re required to respond to this challenge before you can go any further.” Here are the options your administrator has chosen for you. Pick one, respond, and you can go about your business; otherwise, we’re going to stop you right here. And as you can see from this illustration, you can use the Centrify mobile client with MFA.
It’s great from an operational perspective for your admins. From a deployment perspective, it’s simple, too. We’re basically just connecting Server Suite and the Centrify Identity Platform through our on-premises cloud connector (i.e. gateway/proxy). You’ll need to get accounts for your admins in Centrify Privilege Service (or Centrify Identity Service), for those people who you want to be able to respond to those MFA challenges. And on the Server Suite side, the Server Suite administrator determines whether or not MFA is turned on for a particular machine or set of machines, at login and/or privilege elevation, and for which users.
This is an exciting feature, and we’re entirely committed to the concept of enabling MFA as an option everywhere it makes sense, across all of our products and supported platforms. You can see a demo of Server Suite MFA here:
Local account provisioning
Another big feature we’ve added is local account provisioning — a really useful feature across your UNIX and Linux real estate. You probably have local accounts that are being used as service accounts to launch services or applications. And you have to manage those accounts either locally, one at a time, or centrally through a separate product. One of the things that’s troublesome is trying to keep track of all of those accounts, to make sure that accounts are retired properly. It’s tough to do. So we did something to help: We implemented what we call “Zone-based application account management.” You can also think of it as local account provisioning, Centrify-style.
In Access Manager, or our command line tools like adedit, you can tell the Centrify agents on a group of computers to create, edit, or delete a local account or group. This can be based on the computer’s Zone membership in Server Suite, or on their Computer Role membership.
This makes it absolutely straightforward to create an “oracle” account (for example) on all the machines that are a member of a Computer Role that says “Test DevOps Database.” And all of those machines, as long as their members of the zone or role, will automatically get that account, along with the Linux properties, provisioned to them. And if they ever move out of that zone or role, the accounts are automatically deleted on the host computers. That’s the real beauty of it. It’s a “set and forget” central management system for privileged local accounts used to run application or services. It’s intelligent enough to clean up after itself, which means you don’t have to remember to do all of this manually, or in another system, when you’re making changes to your deployment. This is more operationally efficient, and more secure because it makes sure that you’re not leaving “rogue” privileged accounts on machines after they should be deleted.
We’ve also hooked up…a hook! When the host Centrify agent touches a centrally managed local account, it automatically calls a user-defined script. That script can pretty much do anything you want it to do whenever a local account or group is created, edited, or deleted. One of the things we think will be popular will be taking new local accounts and passwords and storing it securely in Centrify Privilege Service, even taking the password under management so that it’s rotated and only Privilege Service, and the local host system, know the password. We provide a script that integrates directly with Centrify Privilege Service. But we know that some customers will want to do other things (even integrate with other security products) so we made the script general-purpose and user-definable.
Centrify Server Suite reporting services
One more feature before I close out for this blog. In very large scale deployments (we have customers running more than ten thousand Centrified-servers in a single deployment), it can take way too long to get a report back on authentication and authorization information from Active Directory. So we fixed it. We have a new option for installing a new SQL server database, and a new service that caches the Centrify information (and only the Centrify information!) from Active Directory into the database. The service is smart. It uses the Microsoft-recommended methods for incrementally add/editing/deleting information, so it requires very little CPU and bandwidth from your domain controller to keep current. The database exposes a set of normalized views from which reporting is now blindingly fast, even for very large Centrify deployments.
Along with the performance improvements, we’re announcing full support for Microsoft SQL Server Reporting Services or SSRS for Server Suite authentication and authorization data in the new cache database. SSRS is a standard feature of all editions of SQL Server (even the free Express edition). It’s a full-featured reporting product, with graphical layout and design editors, support for complex graphic elements like tables and charts, and a delivery system that will let you send reports from Server Suite into your management and operational teams’ mailboxes, automatically, on a regular schedule.
And it’s fully integrated with AD privileges, so access to reports can be granted on the basis of security group membership. All of the existing reports in the Standard Edition Report Center have been ported over to SSRS, and we’ve added new reports for regulatory compliance needs.
We’ll continue to support your existing customized reports, and the Report Center snap-in, but all our new reporting work for Standard Edition will be based on SSRS.
And there’s so much more to talk about, including the new application-to-application password management integration for Centrify Privilege Service 15.12 (which went live to customers on December 19).
But that’s all for now! I’ll be back with a lot more about Centrify Server Suite 2016, so check back here soon.