What you'll need Active Directory and a Centrify Zone Centrify Access Manager and access to perform the configuration A Windows System and the Centrify Standard Edition Windows Agent (DZWin)...
What you'll need
Active Directory and a Centrify Zone
Centrify Access Manager and access to perform the configuration
A Windows System and the Centrify Standard Edition Windows Agent (DZWin)
A UNIX or Linux System and the Centrify Standard Edition Agent (DirectControl/DZ)
Two Active Directory Groups and a test user.
Limiting Access to systems
When planning for access, the key task is determine the criteria to be used to group systems (e.g. PCI). Centrify offers 3 ways to group systems: Zone, Child Zone and Computer Roles - this is the scope of the role. I tend to favor Computer Roles because of the flexibility that they provide. Computer Roles created with an AD Group. Any AD admin will tell you the importance of naming conventions, so the name of the group will be: Centrify-Zone-platform-CR-Name. This means that the name of the group is: Centrify-Model-Mixed-CR-PCI (this is because it will contain UNIX and Windows computers). The Centrify up front is just a convenience, model is the name of my zone and CR stands for computer role.
Granting the appropriate rights
This simplified example, deals with one extreme: Sysadmins. Since IT folks are asked to do more each time (especially in smaller organizations) it's quite common that a Windows Sysadmin is also a UNIX/Linux sysadmin, but the organization would prefer to keep the root and administrator passwords secret. When thinking about rights, you have to focus on two areas:
How role users will access the system: In UNIX/Linux, PAM rights accomplish this (e.g. ssh, vnc, ftp, etc); In windows this can be remote (RDP, Citrix, etc). To simplify this, we'll allow the user two rights: In UNIX - ssh access only In Windows - RDP access only. This means that users assigned this role cannot log in via the console.
What privileges will the members of the group have: Here we'll make it simple: In UNIX/Linux: users with the role can elevate with dzdo and run any command as root In Windows: users with the role can elevate to an administrative desktop
These collections of rights, will be grouped in a Role called "Mixed SysAdmin" this role will have a regular UNIX shell, will work all weekdays and will be audited. The AD Group that will grant this role will be called Centrify-Model-Mixed-Role-PCI Sysadmins.
Security Operations Requirements
When a new security capability is added, ideally log aggregation should not be heavily impacted. This is because it doesn't make sense to implement a solution if you need to invest heavily into getting it to work with what's in place. The good news is that any solution (e.g. ArcSight, LogLogic or Splunk) knows how to get feeds from syslog or eventlog.
Here we need to plan the following:
how to grant/revoke the the role going forward
how to add/remove computers to this collection of systems
Both are simplified because it implies adding principals (users, computers) into security groups. Users can be added at any point (manually, automatically or even via workflow provided by any other solution); computers can be added any time by the same means.
Planning for Platforms
Depending on the platform, certain items need to be planned for, some notables:
PAM Access Rights - in IBM AIX platforms, the default is LAM, this means that to break down access you need to make a decision.
Desktop Rights and Windows 2012 and Windows 8: With the introduction of the Metro interface, elevated desktops are not available, therefore the equivalent needs to be created in application rights.
The cadence is very simple: Unix or Windows rights go into roles, these roles have certain attributes (time/day), type of access and are either audited or not. Finally the roles are assigned to AD principals (permanently or temporarily) in a given scope (zone, child zone, computer role or individual computer)
Step 1: Create the AD Groups
Manually you can open Active Directory Users and Computers (ADUC)
Navigate to your designated OU, right click > New > Group.
Select the appropriate scope and give it a name. In our case we repeat this for both Centrify-Model-Mixed-CR-PCI and Centrify-Model-Mixed-Role-PCI Sysadmins
Step 2: Create the Computer Role
Open Access Manager and right-click your Zone > Authorization > Computer Roles and Select Create New Computer Role.
In the New Computer Role window, give it a name, description and browse for the Centrify-Model-Mixed-CR-PCI group. Then Press OK.
Step 3: Create the UNIX and Windows Rights for the Mixed Role
Go to Zone > Authorization > UNIX Right Definitions > PAM Access, and make sure the ssh right for your platform is present.
Note: By default, the common UNIX and Linux ssh rights are created, if you're using solaris you have to create the ssh right for this platform. If you're using IBM AIX with Loadable Authentication Modules (LAM), you'll have to use the login-all right.
To create the Unix privileged command, right click to Zone > Authorization > UNIX Right Definitions > Commands and select "New Command" In the General tab: Name: give it a descriptive name Command: * Match Path > Specific Path: * In the Restricted Shell tab, uncheck the "Can be used in restricted role" checkbox because we plan to make this role unrestricted (shell) In the RunAs tab, no changes given that root is selected as default; no changes in the Environment tab. In the Attributes tab, we want to check the authentication required option, because this privileged elevation will require the user's AD password.
This ends the rights required for UNIX/Linux functionality.
To create an Administrative Windows desktop, right click Zone > Authorization > WindowsRight Definitions > Desktops and select "New Windows Desktop" General Tab > Name: Give it a descriptive name Run As Tab > Select "Self with added group privileges" and click "Add Built-in groups", check Administrators and press OK twice.
This will be enough for a user to be able to elevate to an administrative desktop.
Step 4: Create and Configure the Mixed Role
Right click Zone > Authorization > Role Definitions and select "Add Role" In the General tab, give it a descriptive name; In the system rights tab, check the first, second and fourth options under UNIX rights. Since we will only provide RDP access on Windows, check "Remote login is allowed" In the Audit Tab, leave as is. This means that the role sessions will be recorded on availability of the Audit Agent and Press OK. The role has been created, but it has no rights. This is a common pitfall.
On the left pane, right-click on the newly created role and select "Add Rights" check the previously created rights for ssh, the privileged command and the Admin desktop and press OK.
Now the role is ready to be assigned.
Step 4: Create and Configure the Mixed Role
Right click Zone > Authorization > Computer Roles > Your Computer Group > Role Assignments > Assign Role and select the newly created role.
This will be a permanent assignment, so press Add AD Account and in the Add Role Assignment Window, make sure the Find dropdown list is set to Group, and type in the name of the group (Centrify-Model-Mixed-Role-PCI Sysadmins in this example), press OK twice and the role has been assigned.
Step 5: Provisioning Operations
To make a computer a member of the Computer Group, you can do it two ways:
a) Via Access Manager, by adding the zoned computer as a member of the Computer Role.
b) Via ADUC by adding the computer as a member of the AD Group that is the container of the Computer Role.
Note: if the computer is running, in UNIX/Linux, an agent restart is needed to refresh group memberships; in Windows a reboot is needed.
To grant the role to an AD principal or principals (via nested groups) all you need to do is make the user a member of the group.
All actions outlined above can be automated with the Centrify Module for PowerShell or with the adedit TCL UNIX utility.
Attempt access to the systems via the console; the expected result is access denied.
Attempt access via ssh or RDP; the expected result is success
Privileged Elevation Tests
Attempt privileged actions without elevation: On Unix, attempt to edit the /etc/passwd file; expected result, file is read-only. On Windows, attempt to open Disk Management; expected result, access denied.
Attempt privileged actions with elevation (via dzdo): On Unix, attempt to edit the /etc/passwd file; expected result, file is written. On Windows, attempt to open Disk Management; expected result, disk management operations are allowed.
Security Operations Tests
Accountability On Unix, inspect the security log; expected result: user (ad name) is identified as well as actions. On Windows, inspect the Application > Centrify log; expected result, access and privilege elevation are documented.
High-availability (no domain controller available) On UNIX and Windows - access and privileges are enforced