Centrify and Oracle Demystified

Background
The article below, is a modified repost of a very popular response from the Centrify community.  We are often asked by prospects or customers how Centrify fits with Oracle.  Oracle means a lot of things to different people, I think this article does a good job at clarifying it.


I have ORACLE {x.y.z} and I want to know how Centrify can help

"Oracle" means a lot of things to different people because of the large portfolio of products:

• Oracle Solaris - supported OS for the Centrify Standard, Enterprise and Express versions
• Oracle Linux - supported OS for Centrify Standard, Enterprise and Express versions
• Oracle WebLogic - Centrify provides a Java SSO Plugin that provides SPNEGO leveraging adclient
• Oracle Database - Centrify provides the ability to use externally identified users (in AD via adclient with PAM or Kerberos)
• Oracle Database - Centrify provides shared account password management for Oracle database acounts
• Oracle e-Business Suite - Centrify provides provide SAML SSO integration with Identity Service

Let's run through these, (big caveat, I am not an Oracle expert - everything I'll explain will be from an Identity, Access Control and Security context)

Customers and prospects come to us because they have these kinds of challenges and requirements:

a) OS-level:  They want to increase accountability and provide Oracle DBAs with Access and Privilege Management rules:
Given that identity is Centralized in AD, our customers can group systems Oracle Database systems in a zone, child zone or computer role and assign roles like this one:

The management of these assignments is made easy with AD group management, this means that Oracle DBAs will be only able to sign-in via SSH, run the commands outlined (not more) and they'll be able to do so without impacting their productivity.


Users sign-in with SSO or via password and can perform their jobs like here.

[lisa.simpson@engcen7 ~]$ dzdo -l
AD Password:
User lisa.simpson may run the following commands on this host:
    (root) service oracle-xe*
    (oracle) sqlplus *
    (root) su oracle
    (root) su - oracle
    (root) adflush
[lisa.simpson@engcen7 ~]$ dzdo su - oracle
Last login: Thu Aug 20 10:50:03 PDT 2015
-bash-4.2$ exit
logout
[lisa.simpson@engcen7 ~]$ dzdo service oracle-xe restart
Restarting oracle-xe (via systemctl):                      [  OK  ]
[lisa.simpson@engcen7 ~]$ dzdo vi /etc/passwd
Sorry, user lisa.simpson is not allowed to execute '/usr/bin/vi /etc/passwd' as root on engcen7.centrify.vms.

With no need to deal with knowing PASSWORDS.

They can get also multi-factor authentication, session capture and replay of what a person does in a system, as well as Server and Domain Isolation using IPSEC.

b) They want to Centralize the administration and provide authentication services to Oracle tools and applications: 
First, it's good to know that Oracle supports two types of users(*).

• Users identified within Oracle  (they are stored and authenticated within the Oracle database) and
• Externally identified users (these are OS-authenticated users)

(*) I know, this is simplistic.  They offer way much more than that.

The role of Centrify in UNIX OS Authentiation
Centrify offers identity services, authentication and authorization using Active Directory.  We use UNIX frameworks like  Pluggable Authentication Modules (PAM) and Name Server Switch (NSS).  We also enable Kerberos in an over simplistic way, and maintain the system keytab, krb5.conf file based on the dynamically changing AD environment.  Most importantly, we make sure that it will work well with Microsoft Active Directory and Microsoft's Kerberos extensions (MS-KILE)

Oracle natively supports OS Authentication for externally identified users (in the case of modern UNIX/Linux == PAM or SSO via Kerberos).

Example # 2, logging in to Oracle tools
a) for an internal user:

$ sqlplus
SQL*Plus: Release 11.2.0.2.0 Production on Thu Jan 9 10:02:25 2014
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter user-name: sysdba
Enter password:

SQL*Plus: Release 11.2.0.2.0 Production on Thu Jan 9 10:03:01 2014
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

b) for an externally identified user (this can be a centrified ad user, a local user, ldap or even NIS user):

$ sqlplus /nolog
SQL*Plus: Release 11.2.0.2.0 Production on Thu Jan 9 10:08:42 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL>

In this sequence, Oracle leverages the OS authentication and since I had a session with a valid user, then I effectively I'm not prompted.

c) They may have Apps that use Oracle WebLogic and want to extend SSO
We provide a J2EE SSO Plugin for this.

Please select what type of J2EE server to configure:
[0] Tomcat.
[1] JBoss.
[2] WebLogic Server.
[3] WebSphere Application Server.
[4] Exit this configuration program.

This entry explains all about this:
http://community.centrify.com/t5/Get-Started-How-To-s/HOWTO-Install-configure-and-test-the-Centrify-Java-SSO-Module/ba-p/19185
This plugin for SPNEGO is slowly being phased for SAML support, given that the Java platforms support it.

HOWEVER..... what organizations are looking to do the most is this:

d) They want to provide AD users for SSO in their oracle database-based applications
 This is where the devil meets the details. Here are some of them:

• Oracle costs:  Many organizations are hopeful that they can do SSO without investing in expensive oracle tools, but that's not the case.  Traditionally Oracle required the Advanced Security Option to even do Kerberos, they later stated that ASO was free, but then there was another component (Enterprise User Security) required.
• Oracle guidance:  Oracle recommends internally identified users as their best practice.
• Advent of Federation:  This will help a lot and we provide a "behind-kicking" solution with Centrify Identity Service

But the biggest of all devils is: how the application is designed. If the application is designed and has logic based on users in a table, this becomes a bit of a challenge.  Ideally developers should move to support Kerberos or Federated authentication, but unfortunately (and just like many infrastructure folks) they are in the business of creating complexity rather than eliminating it.

e) They want to manage shared credentials from Oracle Databases
Customers may want to manage the password lifecycle of

• Request/Approve - we provide a built-in workflow engine or they can use ServiceNow
• Check-out/Check-in - the process or retrieving or returning the password to the vault (can be time based)
• Rotate/Update - password rotation based on policy or upon check-in automatically
• Enforce Policy (e.g. MFA or others) and review history

for the passwords of shared accounts from Oracle Databases.

For that, with our Centrify Privilege Service, we provide shared account password management for SQL Server and Oracle Databases (plus more to come!)

Docs: https://docs.centrify.com/en/centrify/serverref/index.html?version=1481662594#page/cloudhelp%2Fsvr_mgr_oracle.html%23ww1119449
SAPM for Oracle is available for versions 11g and 12c

f) They have Oracle e-Business Suite and want quick, simple and robust SAML federation
Customers want more than what traditional federation solutions can provide, with Identity Service we provide:

• More than 3,000 turnkey web or mobile apps
• Self-service for applications, devices, password reset and OATH tokens
• Built-in Policy and Multi-factor authentication (modern/traditional via RADIUS)
• Multiple identity sources including AD, LDAP, Google Directory, Social Directory or Federation
• Workflow and Approvals
• Mobile device, application and configuration management
• The ability to publish on-premise applications without the need of VPN access

and most importantly, you can get going in minutes/hours instead of days.

Onboarding EBS is a simple exercise.

Bottom-line:

• Centrify will help you with your Oracle Linux and Solaris systems, integrate them to AD, provide privileged user management, session capture and replay, IPSec-based isolation and will do Shared Account Password Management for those platforms.  Will provide the best AD integration and enable Kerberos like plug-n-play.
• The bullet above will help you with all Oracle "externally identified" users for tools and apps (via PAM or Kerberos).  Centrify Server Suite will not help you with users inside Oracle databases, for this you will need privilege Service and that's for shared passwords.
• We also provide an SPNEGO plugin for SSO for Oracle WebLogic  (but ideally you'll use SAML moving forward)
• When it relates to Oracle database based apps, the details are very important (cost, application, guidance and federation).
• Shared Account Password management for Oracle 11g and 12c accounts, our Privilege Service can provide those capabilities.
• If you have Oracle EBS, you can get all the benefits of Identity Service plus the ability to provide turnkey Federation/SSO

Overcoming the Identity or Infrastructure Duplication to Secure Linux Instances in Public Clouds

Background
Securing Linux instances in public (or private) clouds often requires the duplication of infrastructure (or additional overhead) just to be able to provide basic services like authentication.  Centrify just debuted a new client that leverages a capability called Identity Broker.  This allows users of Centrify privilege service to extend authenticaiton to Linux systems using Active Directory, LDAP, Google Directory and others without the need to implement extensions to AD or LDAP or any supporting infrastructure (like site-to-site VPNs).

The Challenges (AWS as an example)
In previous blog posts, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based capabilities.  The model suggested the use of Active Directory and Centrify Server Suite.
Regardless of the solution, organizations need to find ways to extend this infrastructure by using these techniques:

• Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
• Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
• Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

Centrify Privilege Service

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

• Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
• Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
• Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
• Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

New Linux Agent
The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

• No need to deploy "jumpboxes" to the private clouds (limits exposure)
• Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
• Access Request provides the assurance of "documented approvals" to sensitive systems
• Deploy MFA or access only from the OnPrem network as additional controls.

Agent Architecture
The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

Supported Platforms
Platforms supported in the initial release - more on the way

UNIX Identity
Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.
Login - user's short name (must use the fully-qualified name the first time)
UID - auto-generated based on the GUID
Primary group - auto-private (same as UID)
GECOS - the display name in Centrify Identity Service
Home/Shell - configurable in the Settings tab.

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

Automation
There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

Identity Broker
Privilege Service can accomodate several identities, including:

Note that it can accommodate identities from Active Directories without any trust relationships.
These identities can be aggregated using Identity Service Roles:

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

As you can see the model works like this:
Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

Basic Commands
Agent Operation

• cinfo – obtain information about the agent
• cenroll – enroll the identity platform and enable features
• cunenroll – leave the platform and optionally delete resource and any managed accounts
• cflush – flush the local cache

AAPM

• csetaccount – add a managed account for the resource
• cgetaccount – obtain a managed account’s password
• cdelaccount - delete a managed account's password

HOWTO - Implement a cross-platform mixed DBA Role (Oracle+SQL Server) using Centrify Server Suite

What you'll need

• Active Directory and a Centrify Zone
• Centrify Access Manager and access to perform the configuration
• A UNIX or Linux System and the Centrify Enterprise Edition Agent (DirectControl/DZ & DirectAudit)
• A Windows System and the Centrify Enterprise Edition Windows Agent (DZWin/DAWin)
• Two Active Directory Groups and a test user.

Planning

Privileges Based on Roles
In the previous entry, you saw how we conquered the issue of limiting access to systems based on business need-to-know and how we can create a SuperUser-like role across platforms.  Now it's time to implement a true Role Based governance model.  Just like with any capability (security included) you must achieve balance on the people-process-technology triad, in the context of Roles, its key is to understand how people use privileges in their job functions, implement a process around it and leverage the technology to implement it.  Here's an oversimplified example for DBAs in a mixed Oracle and SQL Server shop.

How DBAs access systems:   SSH and Toad on Linux and RDP on Windows
Typical tasks needed for operations:  In Linux, DBAs need to run the sqplus command as the Oracle account and switch user to oracle.  In Windows, DBAs need to run SQL Server Manager and to manipulate the SQL Server Service.
Typical tasks needed for change-control:  DBAs need to elevate to Root during upgrades and installations.

In my fictitious company, I will allow the SSH PAM access role and the commands to run sqlplus and switch to oracle.  The Sysadmin role (that allows to elevate to root) will only be granted with a change-control number and duration.

This process needs to be adjusted because of two things:

• Resistance to change
  I guarantee you that users will initially think that you're making their jobs harder and will try to find ways to resist.
• Nuances around how people perform their jobs
  For example, a Windows DBA may also need access to SQL Server Configuration tools; or a UNIX DBA may like to switch user without profile  (su oracle, instead of su - oracle).

So be ready to have a review of roles and rights with certain cadence, to add/remove commands or apps; as well a to make usability adjustments.  Make it part of your attestation process.

In our example, we'll use the Centrify-Model-Mixed-Role-DBAs group to provision this role.

Access Based on Roles
The concept continues to be the same as the previous post, but now you are further breaking down your access governance model based on your needs.  For example:  you may have a DEV-QA-PROD train for an application and you can grant access just to that set of systems, and you can classify systems based on that model;  This is where your investment in Centrify Professional Services can pay the most.   In my example, I'll just use a Computer Role called Mixed Database Servers, based on an AD group called Centrify-Model-Mixed-CR-Database Servers.

Security Operations Requirements
In the previous example we leveraged both the UNIX Syslog and the Windows Event log to augment log collection capabilities.  Since DirectAudit data is contained inside a SQL server database, this is another repository that can be tapped by log aggregators.  Since DirectAudit provides session data, information gathered from security operations can be further investigated by looking at session data.

Provisioning
Here the principles continue to be the same as the previous entry. Granting or revoking the role or making a system part of the collective is performed via AD Group Membership (Manually with ADUC, Programmatically with PowerShell or Scripting and controlled via any Workflow engine)

Planning for Platforms
Same exceptions apply:  IBM AIX with LAM enabled don't allow the breakdown of PAM access rights.

Implementation
Just like the previous entry, remember that these steps can be automated via Centrify adedit on UNIX/Linux or Centrify Access Module for PowerShell as well as the DirectManage SDK.

Recap: Rights go into Roles, Roles are configured and Assigned to AD Principals in a Given Scope (zone, child zone, computer role or individual computer)

Step 1:  Create the AD Groups for the Computer Role and to assign the Roles

1. Manually you can open Active Directory Users and Computers (ADUC)
2. Navigate to your designated OU, right click > New > Group.
3. Select the appropriate scope and give it a name.  In our case we repeat this for both Centrify-Model-Mixed-CR-Database Servers and Centrify-Model-Mixed-Role-DBAs

Step 2:  Create the Mixed Database Systems Computer Role

1. Open Access Manager and right-click your Zone > Authorization > Computer Roles and Select Create New Computer Role.
2. In the New Computer Role window, give it a name (Mixed Database Systems), description and browse for the Centrify-Model-Mixed-CR-Database Servers group.  Then Press OK.

Step 3:  Create the DBA commands to be used in UNIX and Linux platforms

SQL Plus as Oracle
Creating this command requires a bit of research. Information about the diversity of platforms, versions and their differences are relevant. For example, in my environment, I’m using Oracle Express 11G running on Linux.

Another important detail has to do with the environment variables. I want to conserve them in this case so sqlplus has all it needs to launch correctly:

Switching to the Oracle account
Some DBAs may need to do a simple (no profile) elevation, or they would want the opposite, Centrify offers the flexibility of Regular or Global expressions.

Service Control for the Oracle Service
More research required. In my environment, the service is oracle-xe and I will limit the directives available for service.


Step 4:  Create the DBA commands to be used in Windows platforms

SQL Server Management Studio
Windows application rights provide a lot of flexibility. Some key highlights

• You can consolidate several applications in a single command
• Applications can be defined manually, by looking at local or remote processes or by browsing directly to the file.
  
• Application arguments can be evaluated with or without case sensitivity
• Application types can be further broken down (e.g. exe, bat, cmd, vbs, ps1, etc.)
• Additional criteria can be added based on the file metadata (e.g. version, company, etc)
• Application rights can be executed in 3 different contexts
  • As a service account: the user in the role does not need to know the credentials.
  • As a member of an AD group without persistent membership
  • As a member of a Windows built-in group (like Power Users, etc.)
    

In the case of the SQL Server Management studio, I have a Windows native deployment with a SQL management account. I can easily use an AD group, but since I have this privilege elevation mechanism, I don’t need to fall into the bad habit sharing that account - there are many other ways to accomplish the same objective.

Stop, start and query the SQL Server Service command
I'm choosing to use the service control command line utility (sc.exe) in the context of the local administrator account to provide the DBA with the ability to control the SQL server service.  The alternative today is to grant the DBA administrator rights, which they can use to stop other services (like the AV or firewall).


Step 5: Creating, configuring, assigning the role and provisioning a user
This process follows exactly the same steps of the previous post. Keep in mind that the Windows rights will be for remote (RDP or Citrix) and to add the UNIX and Windows rights after the role is created.

The role assignment will be performed at the Computer Role level, so it only applies to computers provisioned into that group. Finally you can add your test user to the group that gets the role assigned.

Part of our process dictates that if they do need higher privileges, they can request it based on a change control approval.


Step 6: Verifying and the rights on the UNIX/Linux system
To view the role attributes and definition, use the dzinfo command

$ dzinfo
User: thomasf
Forced into restricted environment: No

  Role Name        Avail Restricted Env
  ---------------  ----- --------------
  Mixed            Yes   None
  DBA/Global

    Effective rights:
        Password login
        Non password login
        Allow normal shell

    Audit level:
        AuditIfPossible

    Always permit login:
        false


  PAM Application  Avail Source Roles
  ---------------  ----- --------------------


Privileged commands:
  Name             Avail Command               Source Roles
  ---------------  ----- --------------------  --------------------
  DBA Oracle -     Yes   service oracle-xe     Mixed DBA/Global
  oracle-xe              start|stop|status|re
  service                start
  control/Global
  DBA Oracle -     Yes   su oracle             Mixed DBA/Global
  switch to
  oracle
  no-profile/Glob
  al
  DBA Oracle -     Yes   sqlplus *             Mixed DBA/Global
  sqlplus as
  oracle/Global
  DBA Oracle -     Yes   su - oracle           Mixed DBA/Global
  switch to
  oracle with
  profile/Global

To view the command definitions, use the dzdo –l command

$ dzdo -l
AD Password:
User thomasf may run the following commands on this host:
    (root) service oracle-xe start|stop|status|restart
    (oracle) sqlplus *
    (root) su oracle
    (root) su - oracle

To use your privileges via privilege elevation use dzdo

$ dzdo service oracle-xe restart
Shutting down Oracle Database 11g Express Edition instance.
Stopping Oracle Net Listener.

Starting Oracle Net Listener.
Starting Oracle Database 11g Express Edition instance.

Finally, and for the benefit of security operations, all privilege elevation continues to be written to syslog:

Dec 27 15:15:53 engcen6 dzdo:  thomasf : TTY=pts/3 ; PWD=/home/thomasf ; 
USER=root ; COMMAND=/sbin/service oracle-xe restart

Step 7: Verifying and the rights on the Windows system

In Windows, to view the role definition, you can open the Authorization Center in the System Tray, the role definitions tab shows the applications defined for the role, double clicking provides a deeper dive.
 
To use your privileges, in the GUI you can use the Run as role shell extension, pick the role and the application will be launched as defined. Finally, just like with UNIX, privileged elevation will be logged in the Windows Event Log.
 

Step 8: Session Capture and Replay with Audit Analyzer
Audit analyzer provides a very neat view of what's going on with your audited systems;   in the left pane you have queries and categories, on the right side you can see the sessions.  The columns include the AD user, the client and server systems, the status of the session, etc.


If you drill down into a session, you can see an index of the commands or events that happened during the session.


Looking at a replay, provides you with the event data +  a video of the terminal or Windows session.


Reconstructing what happened (especially on Windows platforms) is as simple as just watching and controlling like a DVR.


Finally, let's look at this scenario and do some testing:

This article is a repost of  a two-part series I wrote for the Centrify Community.

Using Centrify-enhanced sudo (dzdo) validator with ServiceNow requests

Background
Regulatory frameworks have evolved to require documented evidence of approval for development or infrastructure-related change control.  These activities usually require the exercise of elevated privileges.  Some examples of these requirements and guidelines can be found on PCI DSS, SANS Critical Security controls, ISO 27001 and others:
 

Centrify DirectAuthorize and DirectAudit provide end-to-end, role-based access controls for UNIX, Linux and Windows, in addition it provides mechanisms for validation and tracking of changes via ticketing or request systems.

Requirements
We've had customers that have two categories of requirements:

• Tracking activities related to a particular change control or approved request
  For example: We want to track all privileged activities related to a change control in my security operations dashboard.
  We covered this on this on the original dzdo validator article.  When privileges are elevated, entries in both syslog or DirectAuthorize get created automatically.
  Using Centrify-enhanced sudo:
  

  $ dzdo tail /var/log/messages
  Enter the change control ticket number:1255
  

  syslog:
  

  Nov  7 15:04:39 engcen6 dzcheck.sample[35173]: User "dwirth@centrify.vms" will run "/usr/bin/tail /var/log/messages" as "root" with ticket number "1255"
  

  DA Console:
  
• Implementing controls to prevent unauthorized changes
  For example:  We want to make sure that any privilege elevation is only allowed with an approved request.
  This lab covers a basic lab setup to implement this requirement.

Lab Diagram


What you'll need:

• Centrify Standard Edition and a Centrify Zone with some UNIX roles defined
• An AD-joined UNIX or Linux  system in the Centrify zone
  The system should be able to reach the ServiceNow instance directly, via proxy or via ServiceNow MIDServer.
• A DirectAuthorize role for UNIX
• A ServiceNow instance (Fuji release minimum) and a shared credential or token to query existing requests
  Make sure that the credential only has the minimal rights (e.g. read-only) for your requests.
• Optional:  Centrify Privilege Service (Saas or On-Prem) to vault the SN user's credential. 

Use Case

1. Privileged user obtains a change control manager approval via ServiceNow workflow request.
   The request has a change control window.  (date/time range)
2. During the request validity timeframe, the privileged user needs to perform activities (using Centrify-ehnanced sudo) and when the commands are issued, the SN request number has to be provided.
3. The dzdo.validator script uses the ServiceNow Perl API to validate if the request is approved or not.
   Additional validations can be added like user, time-range, etc;  these won't be covered for blog brevity.
4. If the request is a approved, the Centrify-enhanced sudo command is allowed to execute.  If not, the user is notified.

Implementation  Overview

1. Install the ServiceNow Perl API
2. Test ServiceNow Instance connectivity
3. Optional:  Protect the shared credential using Privilege Service
4. Modify one of the sample scripts to work with ServiceNow Requests
5. Modify the dzdo.validator script to call the ServiceNow Perl API script
6. Implement the dzdo.validator via parameter or GPO
7. Test your results

Install the ServiceNow Perl API
The full instructions and requirements are here: 
http://wiki.servicenow.com/index.php?title=Perl_API#gsc.tab=0

1. Make sure you have the appropriate Perl plugins  (e.g. CentOS 6.x):
   SOAP::Lite  (e.g. yum install perl-SOAP-Lite)
   Crypt::SSLeay (e.g. yum install perl-Crypt-SSLeay)
   IO::Socket::SSL ( e.g. yum install perl-IO-Socket-SSL)
   File::Basename
   MIME::Types (e.g. yum install perl-MIME-Types)
   MIME::Type
   MIME::Base64
2. Download the Servicenow Perl API  (link to 1.01 version) to your UNIX/Linux system
3. Unzip the file in a new folder and run the following commands:
   

   ## create a new folder, download and unzip
   $ mkdir SN
   $ cd SN
   $ wget http://wiki.servicenow.com/images/e/e5/ServiceNow-Perl-API.zip
   $ unzip ServiceNoW-Perl-API.zip
   ## compile the files  
   $ perl Makefile.PL
   $ make
   $ make test
   $ make install

   Follow the prompts, once you have all the ServiceNow Perl API libraries installed to use with your scripts.

Testing Connectivity with your ServiceNow Instance (Sample Script)

1. Create a new file with these contents
   

   # This script retrieves all the requests from your servicenow instance
   # it is used to test connectivity.
   #!/usr/bin/perl -w
   
   use ServiceNow;
   use ServiceNow::Configuration;
   
   # This example uses Centrify Privilege Service's AAPM capability
   # by checking-out the password from the vault at runtime, we eliminate
   # the need to use a cleartext password in this script.
   # uses cgetaccount to check out the password for your-SN-user for 3 mins.
   # Alternatively you can enable OAuth and use Tokens (recommended)
   
   $SN_PASSWD = `cgetaccount -s -t 3 your-SN-user`;
   
   my $CONFIG = ServiceNow::Configuration->new();
   
   $CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
   $CONFIG->setUserName("your-SN-user");
   $CONFIG->setUserPassword($SN_PASSWD);
   
   my $SN = ServiceNow->new($CONFIG);
   
   my @requests = $SN->queryRequestedItem();
   my $count = scalar(@requests);
   print "Number of requests=" . $count . "\n";
   foreach my $request (@requests) {
       print "Request number: $request->{'number'}\n";
       print "Requested by: $request->{'sys_created_by'}\n";
       print "Date Created: $request->{'sys_created_on'}\n";
       print "Approval Status: $request->{'approval'}\n";
       print "\n"
   

 2. To test the script, add the execution flag and run it

$ chmod +x checksn.sh
$ ./inc2.sh
Number of requests=34
Request number: RITM0000002
Requested by: fred.luddy
Date Created: 2016-05-02 18:15:39
Approval Status: requested

Request number: RITM0000004
Requested by: fred.luddy
Date Created: 2016-09-03 17:15:39
Approval Status: requested

Request number: RITM0000005
Requested by: fred.luddy
Date Created: 2016-05-22 19:15:43
Approval Status: requested
[output truncated]

Modify the Sample Script to work with Individual Ticket Numbers
To do this, you need to change the script to require arguments and check for usage.   The modified lines would look like this:

#!/usr/bin/perl -w

# You're checking for arguments here.  If there are no arguments
# show the usage and exit.  E.g.  checksn RTM00005

if (@ARGV)  {

# The previous program can go here.  Make sure you modify this line
# to look like this:

my @requests = $SN->queryRequestedItem({'number'=> $1})


}  else {
          print "USAGE:  checksn [ServiceNow Request ID]\n"
}
   

Note that there's no error logic for requests that are not found.  We're going to have to add this later.

Modify the dzdo.validator script to to use the ServiceNow Perl API script
 Centrify provides a sample dzdo validator script called dzcheck.sample.  This script exists under /usr/share/centrifydc/bin.
With the author's limited scripting knowledge we were able to modify it to work this way:

• Initialize the proper libraries and variables
• Retrieve the password for the ServiceNow user (your-user) and store it in SN_PASSWD
• Connect to ServiceNow instance
• Prompt the user for a Change Control number
• If the number is not found, log to syslog and the user will not be allowed to run the command
• If the number is found but the status is not approved, log to syslog and the user will not be allowed to run the command
• If the number is found and approved, log to syslog and allow the end user to run the command.

Note that additional error logic and checks can be added.

#!/bin/sh /usr/share/centrifydc/perl/run
# A modified demo for Centrify-enhanced sudo (dzdo) validator 
# Modified to work with ServiceNow Requests

use strict;

use lib "../perl";
use lib '/usr/share/centrifydc/perl';
use CentrifyDC::Logger;

use ServiceNow;
use ServiceNow::Configuration;
# Use privilege service to retrieve SN shared account password
# Alternatively, you can modify the script to use an OAuth token 
my $SN_PASSWD = `cgetaccount -s -t 3 your-user`;

my $dzdo_user=$ENV{DZDO_USER};
my $dzdo_command=$ENV{DZDO_COMMAND};
my $dzdo_runasuser=$ENV{DZDO_RUNASUSER};

my $CONFIG = ServiceNow::Configuration->new();

$CONFIG->setSoapEndPoint("https://your-instance.service-now.com/");
$CONFIG->setUserName("your-user");
$CONFIG->setUserPassword($SN_PASSWD);

my $SN = ServiceNow->new($CONFIG);
my $logger = CentrifyDC::Logger->new('dzcheck');

printf STDERR "Enter the change control ticket number: ";
my $user_input=<>;

my @requests = $SN->queryRequestedItem({'number' => $user_input});

# Check if request(s) exist, if not, exit (1)
if (scalar(@requests)==0)
{
  system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
  $logger->log('INFO', "Change control ticket number: %s", $user_input);
  $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not found) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);

  exit 1;
}

foreach my $request (@requests) {

my $req_status =  $request->{'approval'};

# Exit if request is not in approved status
if ($req_status ne "approved")
    {
     system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
     $logger->log('INFO', "Change control ticket number: %s", $user_input);
     $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not approved) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input,$req_status);
  exit 2;
     }
}

# Run command and log if request is approved
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input";
my $logger = CentrifyDC::Logger->new('dzcheck');

$logger->log('INFO', "Change control ticket number: %s", $user_input);
$logger->log('INFO', "User \"%s\" will run \"%s\" as \"%s\" with ticket number \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input);

exit 0;

I've saved this script as dzcheck.snow in the same location.

Configure Centrify-enhanced sudo (dzdo) to use the ServiceNow Requests validator

1. Open the /etc/centrifydc/centrifydc.conf file for editing
2. Uncomment the dzdo.validator and set it to our scripts
   

   dzdo.validator: /usr/share/centrifydc/sbin/dzcheck.snow

3.  Perform and adreload (or restart the agent)

Testing
We'll use a modified version of the sample script to check the requests for validity first, then we'll try to flush the cache using dzdo.

1. Ticket does not exist  (ABC123)
   

   Request verification
   $ ./sncheck ABC123
   Request not found.

   $ dzdo adflush
   Enter the change control ticket number: ABC123
   Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
   
   # syslog contents
   Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: Change control ticket number: ABC123
   Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not found) "ABC123#012"
   Sep 20 18:00:52 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=35961 utc=1474412452436 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command.

2. Ticket is not approved (RITM0010022)
   

   Request verification:
   $ ./sncheck RITM0010022
   number of requests=1
   Request number: RITM0010022
   Requested by: robertson.pimentel@centrify.com
   Date Created: 2016-09-16 16:55:06
   Approval Status: requested

   
   

   $ dzdo adflush
   Enter the change control ticket number: RITM0010022
   Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
   
   # syslog content
   Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: Change control ticket number: RITM0010022
   Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not approved) "RITM0010022#012"
   Sep 20 18:03:04 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36009 utc=1474412584884 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command

3. Ticket is approved (RITM001003)
   

   $ ./sncheck RITM0010003
   number of requests=1
   Request number: RITM0010003
   Requested by: diego.jimenez@centrify.com
   Date Created: 2016-09-11 14:57:57
   Approval Status: approved

   
   

   $ dzdo adflush
   Enter the change control ticket number: RITM0010003
   Demo Password:
   DNS cache flushed successfully.
   Authorization cache store flushed successfully.
   GC and DC caches expired successfully.
   The auditing service's name cache has been successfully flushed.
   The DirectAudit installation information cache has been successfully flushed.
   
   # syslog content
   Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: Change control ticket number: RITM0010003
   Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: User "dwirth@centrify.vms" will run "/usr/sbin/adflush" as "root" with ticket number "RITM0010003#012"
   Sep 20 18:06:22 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|0|dzdo granted|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36106 utc=1474412782119 centrifyEventID=30000 status=GRANTED service=dzdo command=/usr/sbin/adflush runas=root role=UNIX Sysadmin/Global env=(none)

Benefits if you're using DirectAudit
If you have Enterprise Edition, DirectAudit's events will contain information about the Change Control and you can now search for all activity related to an individual change control number.


Benefits if you're using the Centrify Splunk App
The Splunk App will display reports on the reasons why the privilege elevation failed.  You can also add alerts based on this to identify any privileged user trying to fish.


Improvements
This is a lab blog post, therefore this is just a simple concept, but here are the improvements I'd make:

• Use OAuth tokens for ServiceNow instead of a shared credential
  http://wiki.servicenow.com/index.php?title=OAuth_Setup#gsc.tab=0
• Compare the date of execution with the change control date range (we only did simple checks)
• Provide better feedback to the user interactively
• Allow the user to create a request if it's not in the system and notify the approver (cli-driven workflow)

Quick Overview Video

 Notes:  ServiceNow, PCI DSS, SANS and ISO 27001 logos are registered trademarks of their respective owners.

Enabling Centrify Identity Service and Privilege Service for Smart Card Authentication

Background
Many governmental and commercial organizations have implemented smart cards as their preferred method for Multi-factor Authentication.  This post explains how to configure Centrify Identity Service (CIS) or Centrify Privilege Service (CPS) to provide authentication using Smart Cards.  This article provides the configuration steps to enable Smartcard (certificate)-based authentication for CIS or CPS.

How it works
Generally, cryptographic credentials (user certificates) are stored in the smart card (PIV or CAC card) and the system has a dedicated reader.   Upon successful authentication (credentials verified and PIN submitted) the operating system or application will use a standard protocol (like Kerberos) or a one-time-code to grant access to the system or application.

For example, Centrify Server Suite allows the user of Kerberos for SSO to applications like Secure Shell (SSH).  Our DirectAuthorize can enforce if the user is allowed to log in with a password or with Kerberos/GSSAPI only.

In the case of Identity Service and Privilege Service, we use a Centrify capability called Zero Sign-on (SZO).  SZO provides a one-time token to use for authentication if the Authentication Profile that applies to the user is configured for Certificate-based Authentication.  All the user needs to do is navigate to the CIS/CPS site, select the smart card certificate and PIN.

This setup provides strong authentication to access Apps or for Privileged Identity Management scenarios.

What you'll need:

1. An instance of Centrify Identity Service App+ or Privilege Service  (CPS can be SaaS or On-Prem)
2. Public Key Infrastructure Infrastructure  (Enterprise CA, Revocation Infrastructure, well-configured PKI clients) and understanding of how the subject name is being provisioned.
3. A copy of the Certificate Chain (or Root CA) for your PKI infrastructure.
4. A SmartCard or Yubikey configured for authentication into your environment.
   This post contains instructions to set up a lab. See "Lab - Base Setup"

Strong Disclaimer:  This is a PKI-related topic.  You should always be workign with your PKI SME with anything related to certificates, trust chains, revocations, etc.

Configuration Overview
The configuration depends on the deployment option of the service.

1. Configuring the Root CA in Identity Service App+ or Privilege Service
2. Configuring a Policy that allows for Integrated Windows Authentication
3. Testing the configuration
4. Appendix:  Configure Privilege Service On-Premises CNAME and Zero Sign-on SSL Certificate

Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)

1. Sign-in to Cloud Manager
2. Go to Settings > Authentication > Certificate Authorities
   Note:  If you can't see the Certificate Authorities option, you're not running the App+ edition or in the case of Privilege Service on-premises, you have to perform the activation steps (see below).
3. Press Add and complete the follwing information:
   
   Name:  descriptive name of the CA
   Extract login name from:  The options are
   a) Principal Name from Subject Alternate Name
   b) E-mail address field from Subject Alternate Name
   c) Username from Subject
4. Click Browse and select the location of the root ca certificate.
5. If you are confident that you have a highly-distributed (Internal & Internet facing) Certificate revocation infrastructure, check the "Enable Client Certificate Revocation Check" if you are not sure un-check the box for now.
   Note:  If you don't know what PKI certificate revocation is, it's time to find your in-house PKI expert and get him or her involved.  This is a serious topic.
6. Press Save

Configuring a Policy that allows for Integrated Windows Authentication

1. Sign-in to Cloud Manager
2. Go to Policies > [Select your Test Policy] > Expand User Security Policies > Login Authentication
3. Set the "Enable authentication policy controls" setting to Yes, if not selected.
4. Scroll down to "Other Settings" and make sure that the "Allow IWA connections..." is checked.  Then note the following:
   Note: Certificate-based authentication bypasses the login authentication rules set up for that profile.  The key settings are:
   
   The first setting "Use certificates for authentication..." is the main switch.  If you un-check this box, the users in scope for this policy won't be able to use smart cards for authentication.  This bypasses any controls set under "Login Authentication" in the preceding section.
   The second setting  "Set identity cookie..."  controls whether the cookie is set for the browser.   I would not set this flag if you expect users to access via non-managed systems.
   The third setting "Accept connections using certificate..." defines whether if users logging in with smart cards or certs are treated as "strongly-authenticated"
   
   Make your selections based on your desired security posture.
5. Press Save.

Testing your configuration

1.  Navigate to your Identity Service or Privilege Service URL
2. Depending if your browser is configured correctly, you'll see any of the following pop-ups will come up:
   
3. After selecting the Certificate on the Smart Card, you'll be prompted for the PIN:
   
4. Once you type-in the PIN, you'll be redirected to the appropriate portal (User | Cloud Manager | Privilege Manager).

Quick Setup Video


Appendix 1:  Enabling Certificate Authorities for Centrify Privilege Service (On-Premises)
Background:  Centrify Privilege Service can be deployed on premises on a Windows Server 2012 R2 system.  You need a CNAME record for the Zero Sign-On website and a x.509 certificate with that DNS name.

Pre-requisite tasks:
a) Set-up a DNS CNAME record to with the name hostname[zso].domain.name pointing to the hostname.domain.name.  E.g. if your system name is app1.corp.contoso.com, create a CNAME record to app1zso.corp.contoso.com and point it to the original host name.
b) You need an SSL Certificate with the DNSname for the SZO special host.

1. Log in to the server hosting Centrify Privilege Service
2. Open an Administrative PowerShell and navigate to %Programfiles%\Centrify\Centrify Identity Platform\Scripts
3. Run the setup_certauth.ps1 script.   The program will ask if the pre-requisites have been met.
   
4. Confirm and you'll be prompted to provide the x.509 (SSL) cert for the SZO site.
5. Once completed, you can return to Cloud Manager and perform the steps outlined above in the:  "Configuring the Root CA in Identity Service App+ or Privilege Service (SaaS)" section.

Other Resources and Related Topics
Documentation:  https://stage-docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FCloud_Policy.13.html
Centrify's support for Derived Credentials: 
- Blog: https://www.centrify.com/products/identity-service/emm/derived-credentials/
- Docs:  https://docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2FderivedCreds.html

This article was originally written as a Centrify Tech Blog.

Basics: Centrify Zone Schema Types and Identity Sourcing - Part II

This article is a continuation an blog post I started last month about how Centrify supports multiple schemas to store UNIX information in Active Directory.  We also discussed the challenges with UNIX namespaces, the type of schemas supported by Centrify Server Suite and strategies for discovery leveraging PowerShell and other tools.


 In this part of the article we discuss strategies on how to source UNIX identity information into Centrify Zones in Active Directory.

Terminology

• Sourcing: extracting identity data and injecting from source to destination.  I don't mean synchronization.  This is meant to be a one-time thing.
• Provisioning:  Once identity migration happens, provisioning are the operational add/moves or changes.

Strategies
Centrify Standard Edition for UNIX implementations consist of analysis and design work to migrate (source) and operate (provision).  Organizational goals vary and must balance project and production needs. That's why a good design is based on a detail analysis of the organization's process.

Let's picture an organization with this makeup

In this case we have an organization that needs to maintain an old namespace because of legacy UNIX systems, however a big mistake that I see in many of our customers is not closing the project correctly.

In this scenario there should be a strategy like this:
For the migration

• Linux systems are going to be normalized and migrated, users keep their usernames and UID/GIDs if aligned with current username standards.  Duplicates will be taken care of.
• The AIX systems will be migrated to the Centrify DB2 Plugin that can take care of the existing challenges.  This is within a 3 month of Centrify operations.  A new child zone will be created for this purpose, during migration this will be overriden at this level. 
• The HP-UX systems will be retired with application attrition.  The vendor is out of business and management has given two years to find a replacement (most likely web-based).  This can be handled with a child zone or local overrides.
• Old NIS Maps:  The old nis maps will be maintained using the Centrify NIS proxy, but the application that relies on YP will be decommisioned in a year.  To compensate for the unencrypted traffic, Centrify DirectSecure will be implemented.

For operations

• Users will get a unix login name based on their AD username
• GIDs will be long integer numbers that are derived from the AD SID

Notice the clear end of the legacy operations.   Unfortunately, in the field this is not the reality;  many times organizations end-up carrying legacy problems for years.

Now let's talk about how to source and provision data for migrations and operations.

Sourcing Data Into Centrify Zones
Centrify zones can source data using different options.  Flexibility is the key here. Ultimately, a tool that uses the Centrify APIs is required to insert data into zones.  
The tools available are:

• With Centrify Access Manager (mmc snap-in)
  • Manually using the zone defaults
  • Manually using the import wizard
• Centrify DirectManage PowerShell
• Centrify adedit
• Centrify Zone Provisioning Agent
• Custom programs that use the Centrify DirectManage SDK

Using the Zone Defaults
Each zone can be configured to provide information from default values.  The options are:

• Login name:  defaults to the AD username (sAMAccountName) - it can be truncated.
• UID can be:
  • Not defined:  no value provided (requires manual intervention)
  • Auto-incremented:  this lends itself to collisions
  • Generated UID from SID: provides a unique 32-bit integer number generated using Centrify's algorithm
  • Use Apple UID Scheme:  provides a unique 32-bit integer generated using Apple's algorithm
  • RFC2307:  You need the 2016.1 version of AM to see this, but this option is quite useful to source existing RFC2307 data.

Import Wizard
The import wizard can process UNIX identity data from local files or a NIS directory.  The key is to arrive to a consolidated set of files and that the inconsistencies are understood.

Our professional services teams provide sets of of scripts to identity anomalies with user/group identities and once a consolidated /etc/passwd or /etc/group file has been identified, then the fun can begin:

Another benefit of the import wizard is that combined with the getent command, provides a fast way to onboard users and groups from 3rd parties.  This video should illustrate what I mean.

This topic has been covered as well in different entries:

• Migrating from /etc/users
• Migrating from /etc/group
• Cleanup with the adfixid & adrmlocal utilities by @tchariya

DirectManage PowerShell
Active Directory PowerShell Modules can be combined with DirectManage PowerShell for some interesting sourcing/provisioning options.  For example:  You can identity all users with posixAccount information (generally those that don't have the uidNumber populated).
If using a Centrify Standard or RFC2307 zone, you can use this information to provision data into the zone.

$zone = Get-CdmZone -Name RFC
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
New-CdmUserProfile -Zone $zone –User $user.UserPrincipalName -Login $user.SamAccountName  -Uid $user.uidNumber -PrimaryGroup $user.gidNumber –HomeDir $user.unixHomeDirectory –Gecos $user.name –Shell $user.loginShell
}

 Alternatively, if you're using an SFU zone and the information is normalized, you only need to update the msSFU30NisDomain attribute to the NIS domain set for the zone in the particular domain. 

$zone = Get-CdmZone -Name SFU30
$nisdomain = $zone.NisDomain
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
Set-ADUser -Identity $user.SamAccountName -Replace @{msSFU30NisDomain =$nisdomain}
}

Zone Provisioning Agent
ZPA is a utility provided for automatic provisioning.  It relies on AD Security groups as the "source" and based on group memberships the service will provision UNIX user or group identities.  ZPA options extend the options seen on the zone defaults.

ZPA can be viewed as a provisioning utility rather than a "sourcing" tool.

Centrify adedit
adedit is a TCL-based utility that can be used to modify Active Directory data and it powers many of the operations performed by the centrify's adclient.

Here's an excerpt for user provisioning:

>bind centrify.vms
>select_zone "cn=rfc,cn=zones,ou=unix,dc=centrify,dc=vms"
>new_zone_user wanda.web@centrify.vms
>set_zone_user_field uname wanda.web
>set_zone_user_field uid $userUID
>set_zone_user_field gid 0x8000000
>set_zone_user_field gecos "Wanda Web"
>set_zone_user_field home "%{/home}/%{user}"
>set_zone_user_field shell "%{shell}"
>show
Bindings:
        centrify.vms: dc.centrify.vms
Current zone:
        CN=RFC,CN=Zones,OU=UNIX,DC=centrify,DC=vms
Current nss zone user:
        wanda.web@centrify.vms:wanda.web:134217728:134217728:Wanda Web:%{/home}/%{user}:%{shell}:
Forests have valid license:
>save_zone_user

adedit is a deep topic.  Here's the documentation:  https://docs.centrify.com/en/css/suite2016/centrify-adedit-guide.pdf

Centrify DirectManage SDK

The directmanage SDK provides the ability for developers to write their own apps for sourcing or provisioning.  The best resource to find documentation and other resources is to leverage the Centrify Developers page.  The sample applications are in the Suite.  Access Manager, Zone Provisioning Agent and the migration wizards are all created using the SDK by Centrify developers

There are also customers making very innovative use of these resources.


Conclusion
The key to current customers and prospects is flexibility.  Regardless of where and how complex your organization's UNIX identity data is, Centrify offers the deepest options to seamlessly integrate to your existing Active Directory regardless of deployment.