A DirectManage Audit 3.x installation typically creates and deals with two types of databases i.e. an Audit Server database (also known as the Management database) and Audit Store database. The Audit Server database stores DirectManage Audit 3.x application specific settings whereas the Audit Store database is used to store the actual audited user sessions. A typical DirectManage Audit 3.x installation consists of one Audit Server database and one or more Audit Store database(s).
In a nutshell, here are the steps involved when migrating database from one database server to another:
Step 1 - Stop all the collectors
Step 2 - Take backup of existing databases (optional but recommended)
Step 3 - Detach the existing databases and attach them to the new database server
Step 4 - Ensure that CLR integration is enabled on the new database server and login for NT AUTHORITY\SYSTEM exists on the server
Step 5 - Restore the TRUSTWORTHY flag and owner of the database
Step 6 - Modify the newly attached Audit Server database
Step 7 - Restoring connection between Audit Server database and Audit Store database
Step 8 - Update the database entries in Active Directory
Step 9 - Start all the collectors
Attached document explains in details each step above should be taken in case if database migration is inevitable in order to keep the impact on the DirectManage Audit system as minimal as possible.
How to change log throttles manually in Centrify Agent for Linux and Centrify infrastructure Service
Centrify provides the following scripts to enable/disable debug logging:
- Centrify Agent for Linux: /usr/share/centrifycc/bin/cdebug
- DirectControl: /usr/share/centrifydc/bin/addebug
- DirectAudit: /usr/sbin/dadabug
Enable debugging in journald environmentRead more...
Do you want to give an individual remote access without giving it to all users then this blog is for you!Read more...
How to configure the integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk
Part2 - Integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk
The configuration of a profile will be made to start the recordings of the sessions from the elevation of privileges and the integration will be made with splunk so that the auditing sessions can be viewed directly from the Splunk Portal.
Configuración de integración entre Infrastructure Service (Auditing and Monitoring Service) y Splunk
Como configurar la integración entre Infrastructure Service (Auditing and Monitoring Service) y Splunk
Parte2 - Configuración de integración entre Infrastructure Service (Auditing and Monitoring Service) y Splunk
Learn the basic of Microsoft Red Forest and how Centrify can be used to provide a more effective security strategy.Read more...
[How to] Integration between Infrastructure Service (Auditing and Monitoring Service) and Splunk
Part1 - Start session recording when performing privilege elevation
We will made the configuration of a profile to start the recordings of the sessions from the elevation of privileges and the Splunk integration with Infrastructure Service (Auditing and Monitoring Service) so the auditing sessions can be viewed directly from the Splunk Portal.
Joining Linux and UNIX machines to an Active Directory domain with Centrify Infrastructure Services has countless benefits, not the least of which is the ability to do away with SSH Public Key authentication. There are several good reasons to discontinue the use of SSH Keys. For a complete list of all of them, please reference the NIST Internal Report 7966.
I can save you some dry reading, and summarize it like this. If improperly managed, the use of SSH Keys can present a massive security risk. Even if every measure is taken to properly manage them, SSH key provisioning is still prone to human error, and after all, UNIX admins are only human.Read more...
Using the adlicense command to change/fix the license type on Linux desktops and (possibly) correct License Reports within Centrify Infrastructure Services.Read more...
In this blog post we outline how you can enroll a new Windows Server system (on prem or IaaS) to Centrify Infrastructure Services and secure a local account credential password. This lab entry covers:
- Enroll a Windows system in Infrastructure Service
- Apply local settings, policy or permissions
- Add the Windows instance to a system set.
- Create a local user and secure the credential password in Infrastructure Service
We'll illustrate with Amazon AWS but the building-blocks can be used on premises or with any other IaaS provider like Microsoft's Azure or Google's GCP.Read more...
This is the second article on a series around Centrify's role to participate or enhance the Microsoft Enhanced Security Administrative environment.
The first article on the series covered MS ESAE in FAQ form and introduces 10 Principles derived from this environment.
In this article, we provide information about how centrify can enable the implementation of the general principles and recommendations.
Plesase read the original article (link below) to get the full context of the information:Read more...
[HOWTO] Silently install the Centrify Agent for Windows™ using Group Policies for MFA and Enrollment
Interested in deploying the Centrify Agent for Windows silently using Group Policy?
This article shows you how.Read more...
In this series we discuss Microsoft's Enhanced Security Administrative Environment (ESAE) and how Centrify participates and provides additional capabilities in this model.
The first article on the series is an introductory post on the topic.Read more...
Security questions are like a second password prompt. Just like passwords, users tend to create weak or easy to guess answers. Unlike passwords, security questions usually do not have policies to enforce complexity, uniqueness and guessability.
Here are some tips to help make your security question answers stronger:
1. Use a non-corresponding answer.
Using an answer that does not correspond to the question will make it harder for unauthorized users to guess or find your answer. For example, if the question is your first car model, answer with "blankcowblueYogurt". If the question is your mother's maiden name, don't use your mother's maiden name as the answer. Your mother's maiden name might be easily acquired through social media, social engineering, stolen records, public records, malware, easily guessed or many other methods.
2. Avoid answers that are vulnerable to social engineering.
Even if you use a non-corresponding answer to a security question, unauthorized users may still randomly attempt to use information that could be acquired through social media or social engineering such as the name of your child, pet, school, or company.
3. Follow password complexity rules for your answers.
Security questions are just like a second password. Hackers may use brute force or dictionary attacks on a security question. Following password complexity rules can help to make your security question answers more secure.
An easy to remember and yet complex answer is to use four random words like "blankcowblueYogurt".
4. Use spaces if possible.
Older generation brute force and dictionary attacks don't account for spaces. For modern tools, it can make it longer and harder to crack if there are spaces. Add a space in your answer if allowed. "blank cow blue Yogurt"
Centrify MFA can use security questions for:
- AD password reset / account unlock
- Computer login (Windows / Linux / Unix)
- Privilege elevation (Windows / Linux / Unix)
- Remote access through Centrify's password vault.
- Password checkout for shared privileged accounts.
- AWS Workspaces
- Horizon View
- Accessing a web application
- Accessing the Centrify User and Admin Portals.
- VPN access
Centrify users can set up their security question(s) through the Account tab in the Centrify User portal.
Centrify Infrastructure Services 2017.3 - Support for Centrify Analytics
This is part of a series of articles showcasing what's new with Centrify Infrastructure Services (formerly Centrify Server Suite) version 2017.3. In this article, we'll preview Centrify Analytics for Infrastructure Services Alpha.Read more...
[What's new] Infrastructure Services 2017.3 - Windows Self-Service Password Reset and MDM Enrollment
Centrify Infrastructure Services 2017.3 - Centrify Agent for Windows™
This is a part of a series of articles showcasing what's new with Centrify Infrastructure Services (formerly Centrify Server Suite) version 2017.3. In this article, we'll discuss what's new with the Centrify Agent for Windows™ including:
- Self-Service Password Reset using the Windows Credential Provider.
- Windows 10 MDM Enrollment.
These capabilities complement some of the platform benefits like Self-Service, Multi-Factor Authentication and Zero Sign-On.Read more...
I wanted to call attention to a feature you may not be aware of when configuring Privilege applications for the Agent for Windows. This feature further increases the security of Privilege Applications by ensuring the executable is signed by the trusted publisher by validating the certificates.
Below are the screenshots on where this feature is located in Access Manager.
Please see the documentation in the centrify-win-adminguide.pdf guide.Read more...
Centrify Infrastructure Services 2017.3 - Container Linux by CoreOS is now supported!
This is a series of articles showcasing what's new with Centrify Infrastructure Services (formerly Centrify Server Suite) version 2017.3. In this article, we'll discuss Centrify's support for Container Linux by CoreOS.
Find out how Centrify has integrated to this stripped down OS to facilitate Centralized Administration, Access Control, Privilege Management, Multi-Factor Authentication, Session Capture and Replay and Attestation Reports.
Also learn how we an assist Privilege Management in the Docker lifecycle and if needed, extend Centrify capabilities inside a container.Read more...
One of the great things about Centrify approach to deploying agents, is that Centrify’s approach provides multiple options to install a Centrify agent onto a Linux or UNIX computer. While enterprises are welcome to use popular software deployment tools such as Chef, Puppet, and Ansible to deploy Centrify agents, Centrify intrinsically offers great flexibility to deploy agents as well.Read more...
In this post, I cover some of the key audit events Centrify captures, where one can find them if they want to send these logs to SIEMs and other tools.Read more...
"Why port 389?"
A customer recently emailed me asking a few questions about the Unix agent communication security with Active Directory
- "Why does the Centrify Unix agent (adclient) communicate with Active Directory over port 389?
- How is this communucation secured?
- What are the implications to Active Directory? Specifically, how do we protect Active Directory against unsigned/unencrypted LDAP requests?"
Typically, this question tends to come from Security/Compliance and Unix teams. From their vantage, interacting with LDAP over 389 raises a flag, where traditionally communications over this port tend to be unencrypted. If the question comes from the Active Directory team, they are usually looking for confirmation and assurance that our interactions with Active Directory align with best practices and their secrity expecations.
As part of the security toolbox, we must deal with shared credentials, more specifically passwords. Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases. In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.
Using shared passwords in CLI scenarios while maintaining assurance
Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials. However, at the same time we need to maintain assurance and enforce principles like:
- Try to eliminate passwords
- Limit lateral movement
- Just in time/just enough access/privileges
- Identity Assurance
- Monitoring and Auditing
- Policy enforcement, etc
The maturity model illustrates this best:
Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party. The enrollment process looks like this:
Each system is represented by a service account in Centrify Infrastructure Service. Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services.
In Linux, this is implemented with the cenroll command. If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the email@example.com credential and enables all features):
sudo cenroll --tenant vault.centrify.vms --user firstname.lastname@example.org
--verbose --features all --agentauth identity-broker-users
--name centos7 --address centos7.centrify.vms
If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):
Enroll-CIPSystem -EnrollCode "THISIS-WHERE-YOUR-CODE-GOES"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation. In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform. Centrify includes a built-in group called: Centrify Agent Computers; by default, this group has visibility to systems, domains and databases.
As a best practice, don't overload the Centrify Agent Computers built-in group. Just use it for visibility purposes. Create sets and other roles, and leverage those instead.
For accounts, there are several entitlements
This means that you need View+Check out at the account level to check out a password. This is a mechanism for least access and limiting lateral movement.
Policy Enforcement and Monitoring
The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.
A great policy that can be implemented is the use of internal/external, datetime or even Risk. This can be applied at the account level.
Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like: Dashboards, Reports or the ability to send events to a security operations or SIEM tool.
- Enrollment codes: allow Centrify clients to enroll the platform automatically. The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
- Sets: Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
- Packages: The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.
- Policy overrides: Password lifetime overrides allow for different policies at the parent or account levels. This is useful when you need policies for human beings vs. machines.
The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).
Here's more info about cgetaccount.
Here's how it looks in PowerShell (checking out the sa SQL server account from the database enterprise for 2 minutes)
Note that these examples are interactive checkouts. Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.
The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems. Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.
The Developer Reference pages here: https://developer.centrify.com are another resource in your arsenal.
The resource management API, specifically the /Servermanage/CheckoutPassword API provides the capability of password checkouts. This reference provides the folllowing code samples:
- Node JS
- C# and
PowerShell Sample Pages in GitHub
Many of the CIP methods are already available in PowerShell using the samples posted in Github.
This is an area of a lot of interest for Centrify. Stay tuned.
Early adopters of shared account password management (SAPM) solutions have discovered that a single strategy (e.g. password-driven) does not provide the assurance for modern IT infrastructure. Despite the quick way some audit comments can be mitigated with a shared password solution, when you explore the modern enterprise, there are many issues and opportunities for improvement. In this article, we'll discuss the challenges with vaults, and how with Centrify we can either compensate, enhance or consolidate security capabilities.
The idea is to explore each topic, and propose and demonstrate a scenario, provide recommendations and use an example with Centrify Infrastructure Services.
You can also use this series to explore the capabilities of Centrify Privilege Service (a.k.a Centrify's vault)
The Traditional Password-Driven PIM Design and its Challenges
The illustration above provides a generic diagram for a password-driven PIM design; the whole premise of this design was that if you can control access to the password of a shared privileged account, provide secure access services (like terminal/desktop transport, auditing and recording) all via the vault and centralize access via a portal, then the issue could be resolved. In time, many issues were observed:
- "Productivity-driven" abuse: when vault users suddenly "camp" (check out credentials for a long time), lobby for multi-checkouts, "try to go around" the vault when they can.
- Deferment of identity or privilege consolidation: very prevalent on the UNIX/Linux world, suddenly it was OK to continue with identity duplication in /etc/passwd, /etc/group accounts as well as managing and maintaining sudoers file configurations. This was also influenced by the advent of DevOps solutions that make configuration management much easier.
- Challenges for security practicioners: Due to all the moving parts, it is hard to prove the effectiveness of these controls; there are many moving parts, and not enough compensating controls at each critical area.
- Identity duplication: The "vault" over time became another identity silo, especially if the design implied that all the local passwords for privileged accounts (e.g. root, administrator, etc) along with the user's "administrative, or -a" account was also living there. This means that rather than eliminate the problem of "too many passwords" we decided to embrace it and get a tool to manage the issue.
- Did not solve the issues faced by most enterprises: Modern enterprises need flexibility and productivity, there are challenges with Filers, client-server applications, high-frequency transaction and other scenarios where this solution set does not provide a solution or simply does not scale well. There are enterprises that have solved the problem of centralization, but simply chose the wrong infrastructure; and they want to come to Active Directory for more than just authentication.
- Did not survive the test of time: Although credential password management is one of the fundamental tools to mitigate security breaches, the goal is to achieve security assurance as threats evolve as well. A key example is that this model does not solve issues like PTH in Windows or works well in multi-private/public cloud scenarios.
- It's not really protecting the target systems: This is perhaps the biggest flaw of this design. All it's doing it's securing a privileged account password; if the system is compromised, there's no active software locally to provide assurance.
These articles will cover how Centrify Infrastructure Services addresses many of the issues outlined above, from identity consolidation to auditing and monitoring, across different platforms, however we'll do it maintaining our Identity Maturity model:
- Identity consolidation as a way to avoid vault-bypassing and to maintain assurance
- Maintains productivity
- Promotes centralized administration
- Eliminates friction to adopt other identity-driven controls (like MFA or Risk-based access control)
- Maintains flexibility for different types of enterprise challenges and apps
- MFA across multiple contexts and use cases to provide identity assurance
- At login (portal and system)
- When using a shared account with secure access
- When checking-ount a password
- When elevating privileges
- When accessing a legacy platform
- Securing the target systems with Centrify Zones
- Using Centrify Local Account Management as a temporary phase
- On the target system (UNIX, Linux or Windows)
- Enforcing least access and least privilege
- Embracing temporary access controls
- Demonstrating the efectiveness of the controls
- Monitoring (easy security operations integrations)
- Attestation (portal, system)
- Auditability and reportability (portal, systems)
- Automation, DevOps and Operations
- Components required
- How processes are affected
- Using an ITSM Solution to consolidate access requests
Combining Shared Accounts with Least Privilege
In each article, we'll try to define a challenge and illustrate the different ways Centrify can compenate or enhance the challenged caused by the Password-driven design. We'll try to use existing articles when possible to reference past Tech Blogs. As we add articles to this series, we'll list them below.
To capture configuration changes in Centrify Access Manager to your SIEM, you will need two things on the operating system running Access Manager
1. Your SIEM reflector to read and send the Application event viewer to your SIEM.
2. Configure the following registry setting:
- HKLM\Software\Centrify\AuditTrail\Centrify Suite.Centrify Configuration\AuditTrailTargets (Set the value to 3.)
- OR HKLM\Software\Centrify\AuditTrail\AuditTrailTargets (Set the value to 3.) Then delete the three child keys for HKLM\Software\Centrify\AuditTrail.
This value will write events both to the local Application event log and Direct Audit database. Events such as assigning a user to a role, creating a child zone or modifying a user's POSIX information will be logged to your SIEM.
For reference, here is the guide for all events written to the Application event log as well the syslog on Linux by the DirectAudit Agent. https://docs.centrify.com/en/css/suite2017.1/centrify-audit-events-guide.pdf