Labs: Centrify for Servers Enterprise Edition 2014 - Speedy Evaluation

I've posted this video playlist:



It covers Centrify Enterprise Edition 2014 and provides a full product evaluation experience for security access controls (Authentication, Authorization, Auditing).  Here are the evaluation objectives.

Category 1:  AD Integration and Authentication - Standard Edition

1. Does not require any schema extensions or software loaded in DCs.
2. Not all AD users have access to UNIX/Linux systems by default
3. Solution uses Standards and Frameworks (LDAP, Kerberos, PAM, NSS)
4. Solution does not synchronize identities or passwords
5. UNIX-enabled AD users can be controlled from AD  (enabling/desabling, logon hours, etc.)
6. Integrating UNIX/Linux systems can be performed from the GUI or command line.
7. AD Security policy is enforced in UNIX/Linux Platforms.
8. Multiple UNIX identities can be assigned to the same AD User
9. UNIX secondary group memberships can be managed from Active Directory as well
10. Authentication can be streamlined with SSO mechanisms.
11. Provisioning/Deprovisioning of UNIX users and groups can be automated.
12. Filer integration (Samba or NFS) - identity consistency for files and folders
13. High-availability:  Users should have access if AD is not available.

Category 2:  Access and Privilege Management - Standard Edition

1. Systems can be grouped using different criteria to enforce access.
2. Access can be limited based on groups of systems defined above (role-based access control)
3. Roles can be defined to control how the user signs into the system and the privileges that can be granted (Role-based access privileges)
4. Provides mechanisms to verify who used their privileges
5. Provides the ability to enforce separation of duties (operations vs. governance)
6. It's intuitive to find out who has access to what system and what can they do

Category 3:  Advanced Auditing - Enterprise Edition

1. Provides a detailed view of user's activities (user, system accessed, duration, client computer, activities)
2. Provides a contextual view of the actions performed (replay capability)
3. Provides the ability to search sessions based on queries.
4. Provides the ability to view when privileges are used across systems

Environment

Basics: Strategies for UNIX Identities with Centrify

Background

In lab 8b, we UNIX-enabled some of the users of our test environment and accessed one of our systems. Here are the session results:

The screenshot above outlines some of the issues that will be encountered when a system is integrated in to Active Directory with Centrify and the users are UNIX-enabled with a proper planning exercise.  For our purposes this is OK, because we need to understand why planning and design exercises should be done.  After all, not everyone is a UNIX/Linux identity management expert.

Duplicated Identities

An identity conflict happens when a key user field (like login or UID) are duplicated.  In the example above the OS (CentOS/RedHat) was designed to be smart enough to warn the user about this, but this is not true of all UNIX and Linux distributions.  This problem has a trickle-down effect in many aspects.  Let's look at the root cause in depth, the culprit is the Name Server Switch (NSS) framework.  Let's look at an excerpt of the file /etc/nsswitch.conf in that system:

passwd:        centrifydc    files
shadow:        centrifydc    files
group:         centrifydc    files

All this means is that any NSS-enabled program will look first at the centrifydc source (in our case Active Directory) and if there's an identity match (for login in this case) this will be the identity picked.  CentOS was just smart enough to continue checking and letting us know that there was a match in the local /etc/passwd too.  This was verified with the subsequent command (getent) that returned a UNIX-enabled jmatthews with an AD SID-derived UID (1149240406) and the local jmatthews with UID 503.

This is true regarding the different sources that a system may have.  In complex environments you could have local databases, OpenLDAP directories, Network Information System services, etc.  It can be as complex as this:

passwd:        ldap nis  files db

In this case, any NSS-enabled program will check LDAP, then NIS, then local files, and so on for users.
This issue is very broad, because it not only applies to users (passwd), but to groups too and with all NSS-enabled programs like login, passwd, sshd, sudo, etc.

The next problem that happens has to do with file/folder ownership.  Notice that our user was unable to change folders to the home directory, in turn he is unable to read his basic environment settings!!!!  This has direct-impact in the productivity of the user, and most likely people will have to get involved to do a change of ownership of files and folders.  This is extremely inefficient.

A final, but important issue has to do with usability.  The user does not have any visual cues to find out the context of the user that he is working with.  Is this the local or the AD account?  We can finish this with some group policies.

The reasons outlined above are why companies with mature identity practices for their UNIX systems do a rationalization (normalization or flattening) of their namespace.  Users have unique login names and UIDs.  Many solutions in the market require organizations to rationalize their namespace prior to implementing the solution, but with Centrify that is not the case.  This is where Active Directory and Centrify Zones come into play.  The following video illustrates how we resolve this one-off:

Strategies for UNIX User Identities with Centrify

The correct strategy depends a lot on the current environment of the customer, but, the preferred strategy is typically the end-state for the majority of the deployments: a normalized user state. The biggest constraint is that the business must go on and there are impact assessments and change-control windows to work with.

A New World of Flexibility with Centrify

Centrify allows for UNIX user identities to be defined at the Zone level, Child Zone (CZ) level and Server level.  This means that a user that is uniquely known in AD as jmatthews@corp.contoso.com, in UNIX, then can have these identities:

Level/Field	Login	UID	GID	GECOS	Home	Shell
Zone (HQ)	jmatthews	1149240406	1149240406	%{u:displayname}	%{home}/%{user}	%{shell}
CZ (Marketing)	jessie.matthews	(same as above)	(same as above)	(same as above)	(same as above)	(same as above)
Server (SOL1)	jmatthew	101	101	Jessie SysAdmin	/exports/home	/bin/bash

Notice that the user's identity was defined with the basic defaults, the login name overridden at the child zone level, and then the whole identity revamped at the Solaris server level.  Notably a truncated login name, more friendly UID/GID as well as defined Home and Shell fields.  Flexibility can be a two-edge blade because it allows for exceptions at multiple levels, and this is against two important Information Technology principles: standardization and simplicity.

Note:  The following strategies assume that the previous questions about AD-domain design, naming conventions, Zone structure, Computer Groups, Roles and Rights and naming conventions have been discussed.

The Recommended Strategy:  Normalize now and have peace of mind

1. Perform a table-top exercise to normalize your users and groups.
2. UNIX-enable (or migrate) all users at the zone level with a unique login and a UID generated from SID
3. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
4. Pre-create all the UNIX computer accounts in Active Directory
5. Place the computer account in their corresponding Computer Role
6. Join the UNIX/Linux Systems to Active Directory.
7. Run the adfixid utility
8. Run the adrmlocal utility

This strategy works if you have committed to fixing this problem and are thinking about the future.  Maybe there are mergers and acquisitions in the future and the namespace is uncertain.  The drawbacks are that the identity rationalization exercise is lengthy and the implementation requires wide change-control windows.  The biggest benefit is that as new systems come online, there's a clean-slate across the board.

Another option:  Obtain results now and normalize later

Use this strategy if you are confident in the existing namespace

1. UNIX-enable all users at the zone level with a unique login and a UID generated from SID
2. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
3. Pre-create all the UNIX computer accounts in Active Directory
4. Place the computer account in their corresponding Computer Role
5. Override all user identities at the system level (to their existing login/UID/GID)
6. Join the UNIX/Linux Systems to Active Directory.
7. Use the adrmlocal utility
8. Normalize opportunistically (with adfixid) or as new servers come online.

This strategy is the fastest path to productivity, however it does not solve the identity issues right away.  If you haven't done so, you may be forced to rationalize accounts that are using exported filesystems.  This allows for waves of systems to be normalized if needed.

Status Quo:  Be stubborn and reactive

1. Perform a user migration from an existing source (NIS, files, etc.) making sure you conserve the existing identity at the Zone
2. Perform any role assignments at the Zone, Hierarchical Zone and Computer Role levels.
3. Pre-create all the UNIX computer accounts in Active Directory
4. Place the computer account in their corresponding Computer Role
5. Join the UNIX/Linux Systems to Active Directory.
6. Use the adrmlocal utility to remove local users (if local) or clean your network-based (NIS) files
7. If inconsistencies are found, perform local-level overrides.

At the user level, a typical inconsistency is that a user may have different identities in different servers. E.g. in our test environment.  jmatthews has UID 503 on cen1, UID 1001 on suse1 and UID 101 on sol1.
Although this is possible, it's highly inefficient and promotes the same disadvantages of local administration:  non-standardization, exceptions and more exposure.  Unfortunately, this administrative model was highly promoted by Classic zones.  Use this model if you are politically defeated.

Basics: The Centrify Agent Cache

Background

In a previous post we described the Centrify agent (adclient) and we mentioned that the cache exists for two objectives:  performance and offline access (availability control in case AD is not accessible). Understanding the cache allows any system administrator to be more effective at using the solution.   The client caches DNS, object and authorization information.

The NSCD service

NCSD stands for name server cache daemon.  It is the best method to retrieve cached information since it's implemented and optimized for each version of UNIX/Linux.  As a basic computer science principle, retrieving items from memory is always preferable than retrieving from permanent storage. The rule of thumb is to always implement NSCD in your systems.  This is a very important design consideration.

The best thing you can do to improve performance of any application that uses Name Server Switch is to implement NSCD.  This applies to Centrify for Unix/Linux.

The Object cache

This cache stores the UNIX-enabled users and managed groups that belong to the client's zone. It's implemented as a database that is stored in the /var/centrifydc folder.  It is used so the client does not have to go to Active Directory for each query and provides support for offline access.

Object expiration and refresh intervals

When objects are retrieved they are tagged with a time-stamp and some of the AD information is retrieved (mainly the update sequence number), while the refresh interval is current, the object will be returned "as is" (no queries to AD are made), if the refresh interval expires, then the object's USN is compared to 

the one in the cache, only if the numbers are different the object will be refreshed, otherwise the time-stamp

is renewed.

The notable exception to this logic is when an end-user attempts to log in; at this point (among other things)
the validity of the account is checked (e.g. is the account disabled, locked, expired, allowed to log in at the time, etc) those checks are performed in real time.
Although there are more parameters to fine-tune the cache, the adclient.cache.expires interval governs when objects are expired. Traditionally, by default is set to 1 hour.

The Authorization Cache

This cache is used for the purposes of authorization (roles, rights etc) and it's separate from the object cache.
It uses the AD azman schema and Centrify algorithms to determine if there are changes to the group memberships (or principals) that have roles and rights tied to them. It uses the USN and the adclient.azman.refresh.interval (set to 30 minutes by default).

Depending on the complexity of the AD infrastructure, the operation can be expensive (in terms of LDAP queries) this is because corporate domains are complex and in certain scenarios it's possible that groups are merged.  Since the memberships are fully enumerated, this is something to think about.

How the Authorization Cache affects the User's ability to log in

Notice that before we have mentioned that for a user to log in they require two things: A UNIX identity, and a role that allows them to log-in. One component relates to identification, the other relates to authorization.
This means that it's possible to have a proper login, UID, GID, etc; but still be unknown to a system because the user does not have a role assigned or the role that is assigned doesn't have a PAM login right.

Note that users can be "listed" in a system.
There are other types of cache, but the two most relevant are the Object and Authorization caches.

What does this all mean?

It means that there's a fine balance to be understood in order to provide performance and high-availability. It also means that there are planning implications to the workings of the agent.  Questions like:

• What is this system used for?
  Very different settings for a shared developer's system than a slave node in a number-crunching system.
• What are the current provisioning/de-provisioning SLAs?
  This opens a great question.  The SLA dictates a lot of settings.  For example in a scheme in which users are provisioned using an IdM solution from an HR system, and there are workflows involved to approve access to UNIX/Linux systems, all components have to be accounted for, Including Active Directory replication intervals.

Adfush described

Adflush is a command line utility that allows system administrators to manipulate the cache.  It shouldn't be used without understanding how the cache works.  

usage: adflush [options]

options:

  -f, --force             flush cache even adclient is in disconnected mode

  -a, --auth               flush cached authorization data

  -d, --dns                flush the adclient dns cache and DC locator cache

  -e, --expire             expire everything in the DC and GC object cache

  -o, --objects            flush only the DC and GC object cache

  -t, --trusts             rediscover the trusted domains

  -b, --bindings           force refresh binding

  -v, --version            print version information

  -V, --verbose            print debugging information

  -h, --help               print this help information and exit.

The type of adflush can have implications from slowing things down a bit, to consuming resources to actually eliminating the ability to log-in offline.  This is important to know for roaming users of Macintosh platforms.  A user that runs a forced adflush while at home will have to wait to get back to the office to log in!!!

Lab # 6: Role Creation and Assignment

In this lab

• We will create the PAM access rights required for our roles
• We will create a privileged command for the system administrators
• We will create and configure the roles
• We will assign the roles to the appropriate Groups in AD.

Planning for the lab
We will use the PDCA methodology outlined in the previous basics post, to address business problem # 1. in which we agreed that there will be 3 groups of users:  System Admins, Web Server Users and Database Server Users.  After the PDCA table-top exercise, the Security, UNIX and Windows leads came up with this table:

Planning Question	Roles
	Super User	Regular User
What is the role supposed to allowed do?	To allow super users perform actions as root	To allow the member to perform user activities
What is their UNIX experience? (controlled or flexible)	Flexible	Flexible
What is the role NOT supposed be allowed to do or know?	Users don’t need to know the root password	No privileged commands
Are there any time/day restrictions to this role?	No restrictions	No restrictions
How is the role supposed to access the UNIX system?	All protocols including the console.	SSH access only
Are there any particular platform implications?	None	SOL1 uses sshd-kbdinit fork.
Are any additional controls required when privileges are used?	Authentication required	N/A
Is this assignment temporary or permanent?	Permanent	Permanent
What is the scope of this assignment?	All Systems (Zone)	Database Servers – for DB Users Web Servers – for web users
Will this role be audited?	Yes	Yes
Will we have a group of people or a single individual have this role?	Group:  UNIX System Admins	Group(s) UNIX Database Server Users UNIX Web Server Users

Create the Oracle Solaris SSH daemon PAM access right

1. Log on to CLIENT1 as Jessie Matthews
2. Open Access Manager and navigate to the HQ zone/Authorization/UNIX Rights, right click PAM Access and select Add PAM access right.
3. Create the SSH daemon for Solaris.  The name and application is sshd-kdbinit press OK

Create Privileged Command for the System AdministratorsThis command should allow system admins to run any command as super users with the requirement of having this action authenticated with their AD password.

1. In Access Manager and navigate to the HQ zone/Authorization/UNIX Rights, right click PAM Access and select New Command.
2. In the General tab, name the command (e.g. run any command as root), and in the command box, type the wildcard character (*);  and in Match Path, select Specific path, and type the wildcard again.  This makes it *.*
3. In the Restricted Shell tab, uncheck the checkbox.
4. In the Run As tab, make sure the root account is selected
5. In the Attributes tab, make sure you check the "Authentication Required" box and select the user's password.  Press OK.

 Create the UNIX System Admin role

1. In Access Manager and navigate to the HQ zone/Authorization/UNIX Rights, right click Role Definitions and select Add Role. 
2. In the General Tab, give the role a name  (UNIX System Admins)
3. In the System Rights, UNIX rights section, check:
   Password login and non-password (SSO) login are allowed
   Non-Password (SSO) is allowed
   Login with a Non-Restricted Shell
4. Press OK
   Now the role is created, but it doesn't have any rights.
5. Right-click on the newly created role, and select Add Right.  Check the following:
   login-all:  this will enable the role to log in via any PAM module including the console.
   run any command as root: this is the previously created privileged command.
   Then press OK.
6. This role is complete.

  Create the UNIX Regular User role

1. In Access Manager and navigate to the HQ zone/Authorization/UNIX Rights, right click Role Definitions and select Add Role. 
2. In the General Tab, give the role a name  (UNIX Regular User)
3. In the System Rights, UNIX rights section, check:
   Password login and non-password (SSO) login are allowed
   Non-Password (SSO) is allowed
   Login with a Non-Restricted Shell
4. Press OK
   Now the role is created, but it doesn't have any rights.
5. Right-click on the newly created role, and select Add Right.  Check the following:
   ssh:  ssh daemon for Debian and Ubuntu
   sshd: ssh daemon for all Linux and UNIX distributions except for above
   sshd-kbdinit: ssh daemon for Solaris
   Then press OK.
6. This role is complete.

Assign the Roles
Remember - sysadmins manage all systems; DB and Web Server users can only sign-in to their Server Groups.

1. In Access Manager and navigate to the HQ zone/Authorization and right click Role Assignments and select Assign Role, select the UNIX System Admin role and press OK
2. Click AD Account and in the Find drop box, select Group.
3. In the Name, type the UNIX and press Find.  In the results select the UNIX Super Users group and press OK Twice.
   Note: before performing the following assignments, make sure you have created the corresponding AD security groups.
4. Expand the Computer Roles node, then expand the Database Servers group, right click Role assignments and select Assign Role.  Select the UNIX Regular User role and press OK.
5. Click AD Account and in the Find drop box, select Group.
6. In the Name, type the UNIX and press Find.  In the results select the UNIX Database Servers Users group and press OK Twice.
7. Repeat 4-6 for Web Servers.  Use the same role (UNIX Regular User) and assign it to the UNIX Web Server users AD Group.

Process Reuse
From this point on, assigning (or removing) roles in UNIX will be performed by adding (or removing) users from those groups in AD  (you can use ADUC, PowerShell, Access Manager, vbscript and anything that can manipulate Groups in AD)

We have performed the Plan-Do.  In a later post we will perform the Check-Adjust.

Lab # 5: HQ Zone and Computer Roles Creation

In this lab

• We will use Centrify Access Manager to create the HQ Zone
• We will define the Zone UNIX identity defaults
• We will create the Computer Roles for Database and Web Servers

Create the HQ Zone

1. Log on to CLIENT1 with Jessie (UNIX administrator)
2. Open the Centrify Access Manager (on the desktop)
3. On the Connect to forest window, click OK.
4. On the Access Manager console, in the left pane, expand the Centrify Access Manager hive, right-click on Zones and select Create New Zone.
5. In the zone name, type HQ, then click next.
6. In the Agent Compatibility page we will select Hierarchical Zone.
   This blog will never use Classic Zones, click Next
7. In the Management Model window, select Standard Zone, click next and then finish.

 Set up the UNIX Identity zone defaults

1. On the left pane, expand zones, and expand the HQ zone.
2. Right click the HQ zone, select properties and go to the User Defaults tab.
3. On the UID, click the drop-down box and select AutoPrivate group, then go to the Group Defaults tab
4. On the GID, click the drop-down box and select Generate GID from SID
5. Click OK

Note:  These are just the zone defaults,  UNIX identities can always be overridden.

Create the Computer Roles for Database and Web Servers

1. On the left pane, expand zones, and expand the HQ zone and expand the Authorization node.
2. Right click the Computer Roles section and click Create Computer Role
3. In name, type Database Servers
4. Click the drop-down arrow on computers group, and click <...>
5. In the Find Objects window, type UNIX and click Find Now.
6. Double click the UNIX Database Servers group and then press OK
   Repeat the same process for the Web Servers and use the UNX Web Servers group. 

Lab # 2: Extending the Base Configuration TLG with UNIX and Linux systems

Lab Overview

1. Install CentOS 6.4, SUSE 10 SP3 and Solaris 5.10
2. Set up and verify the TCP/IP properties and SSH daemon on the UNIX/Linux systems.
3. Modify the UNIX/Linux systems to skip the graphical desktop
4. Verify or setup the Name Server Cache Daemon (NSCD) to start automatically
5. Create and modify the corresponding user for each system and enable sudo on Linux systems:
   We will create two users in all systems: centrifying and Jessie Matthews (jmatthews)
   Two users in the Database System (CEN1); Jeremy Silva (jsilva) & Ramon Jimenez (rjimenez)
   Two users in the Web System (SUSE1); Doyle Russell (drussell) & Matt Sims (msims)
   The centrifying and jmatthews users will be added to the wheel group that will be sudo-enabled.
6. Test connectivity from CLIENT1 using PuTTY 
7. Copy the Centrify agents to each corresponding system

Lab Requirements

• The requirements of the base Test Lab Guide (for DC1, APP1 and CLIENT1)
• A Centos 6.5 VM for CEN1
  http://wiki.centos.org/Download
  You may need to download the NSCD package for CentOS.
• A Novell SUSE 10 VM for SUSE
  https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=10&service_pack=sp3&architecture=x86_64&package_name=index_all
• A Solaris 5.10 VM for SOL1
  http://www.oracle.com/technetwork/server-storage/solaris10/downloads/index.html

Install UNIX/Linux Hosts

The platforms we'll be using in this guide are

• CentOS 6.4:  will be assigned IP address 10.0.0.151
• Novell SUSE 10 will be assigned IP address 10.0.0.152
• Solaris 5.10 x86 will be assigned IP address 10.0.0.153  

Configure the UNIX/Linux systems
Follow instructions for each corresponding platform:

On CEN1

1. Log in as a privileged user (or root) and open a terminal
2. Verify that the NetworkManager (NM) service is running
   service NetworkManager status
   NetworkManager (pid ####) is running
   Note:  Follow the appropriate steps if you're not using NM
3. Edit the /etc/sysconfig/network and add:
   HOSTNAME=cen1.corp.contoso.com
4. Copy the interface's MAC address: (Example eth0 with the Mac address 00.0c.29.2b.b7.ca)
   ifconfig eth0 | grep HWaddr
   eth0   Link encap: Ethernet  HWaddr  00:0C:29:2B:B7:CA
5.  Edit (or create) the /etc/sysconfig/network-scripts/ifcfg-<interface> and add (or edit) the following lines:  (using above example and the information about the lab)
   DEVICE=eth0
   NM_CONTROLLED=yes
   ONBOOT=yes
   HWADDR=00:0C:29:2B:B7:CA
   IPADDR=10.0.0.151
   NETMASK=255.255.255.0
   DNS1=10.0.0.1
6. Restart the network service:
   service network restart
7. Verify the configuration  (hostname, DNS configuration, ping test to crl.corp.contoso.com)
   # hostname
   cen1.corp.contoso.com
   # cat /etc/resolv.conf    (look for the two lines below)
   search corp.contoso.com
   nameserver 10.0.0.1
   # ping crl
   PING crl.corp.contoso.com (10.0.0.3) 56(84) bytes of data.
   64 bytes crl.corp.contoso.com (10.0.0.3): icmp_seq=1 ttl=128 time=17.2 ms
8. This verifies that the TCP/IP configuration is correct and that CEN1 is using DC1 for DNS.
9. To make sure that the SSH daemon is running, run
   chkconfig | grep ssh
10. If the sshd service is off at runlevels 3 and 5, enable them with this command
    chkconfig sshd on --level 35
11. Install and enable the NSCD daemon:
    rpm -Uvh nscd-2.12-1.132.el6.x86_64.rpm
    chkconfig nscd on --level 35
    service nscd start
12. Make sure that the SSH daemon configuration is set up for PAM and to allow Challenge Response.  In the /etc/ssh/sshd_config file, make sure these lines are enabled:UsePAM  yes
    ChallengeResponseAuthentication yes
    The opposite entries need to be commented, otherwise the last directive will be the effective setting.
13. Create an administrative user and the DBAs.useradd -m centrifying
    useradd -m -c "Jeremy Silva" jsilva
    useradd -m -c "Ramon Jimenez" rjimenez
    useradd -m -c "Jesse Matthews" jmatthews
14. Add the administrative user (centrifying in my example) user to the wheel group
    usermod -G wheel centrifying
    usermod -G wheel jmatthews
15. Enable sudo in the system
    vi /etc/sudoers
    Uncomment the authenticated section for the wheel group
    %wheel ALL=(ALL)       ALL
    Save the file.

On SUSE1

1. Log in as a privileged user (or root) and open a terminal
2. Edit the /etc/hostname file (create if it doesn't exist) and add the line
   suse1
3. Edit the /etc/hosts file.  Make sure to add the hostname to the corresponding line:
   127.0.0.1       localhost  suse1
4. Edit the /etc/resolv.conf file and add:
   search corp.contoso.com
   nameserver 10.0.0.1
5.  Edit (or create) the /etc/sysconfig/network-scripts/ifcfg-eth-<MAC> and add (or edit) the following lines:  (using above example and the information about the lab)
   DEVICE=eth0
   ONBOOT=yes
   IPADDR=10.0.0.152
   NETMASK=255.255.255.0
6. Restart the network service:
   service network restart
7. Verify the configuration  (hostname, DNS configuration, ping test to crl.corp.contoso.com)
   # hostname
   suse1.corp.contoso.com
   # cat /etc/resolv.conf    (look for the two lines below)
   search corp.contoso.com
   nameserver 10.0.0.1
   # ping crl
   PING crl.corp.contoso.com (10.0.0.3) 56(84) bytes of data.
   64 bytes crl.corp.contoso.com (10.0.0.3): icmp_seq=1 ttl=128 time=17.2 ms
8. This verifies that the TCP/IP configuration is correct and that SUSE1 is using DC1 for DNS.
9. To make sure that the SSH daemon is running, run
   chkconfig | grep ssh
10. If the sshd service is off at runlevels 3 and 5, enable them with this command
    chkconfig sshd on --level 35
11. Make sure that the NSCD daemon is running on levels 3 and 5chkconfig --list | grep nscdnscd      0:off  1:off  2:off  3:on   4:off  5:on   6:off
    If the service is not set to run by default on levels 3 and 5, enable it:
    chkconfig nscd on --level 35
12. Make sure that the SSH daemon configuration is set up for PAM and to allow Challenge Response.  In the /etc/ssh/sshd_config file, make sure these lines are enabled:
13. UsePAM  yes
    ChallengeResponseAuthentication yes
    The opposite entries need to be commented, otherwise the last directive will be the effective setting.
14. Create an administrative user and the Web Administratorsuseradd -m centrifying
    useradd -m -c "Doyle Russell" drussell
    useradd -m -c "Matt Simms" msimms
    useradd -m -c "Jesse Matthews" jmatthews
    Note:  the useradd command is in the /usr/sbin folder in case you don't have it in your path.
15. Add the user to the wheel group
    usermod -G wheel centrifying
    usermod -G wheel jmatthews
16. Enable sudo in the system
    vi /etc/sudoers
    Uncomment the authenticated section for the wheel group
    %wheel ALL=(ALL)       ALL
    Save the file.

On SOL1

In Solaris, you have to edit or review these files to change the configuration:

/etc/nodename

/etc/hostname.interface

/etc/inet/hosts
/etc/inet/ipnodes

/etc/defaultdomain

/etc/netmasks

/etc/defaultrouter 

/etc/resolv.conf 

/etc/nsswitch.conf 

 We won't be configuring a default router for now.

1. Log in as a privileged user (or root) and open a terminal
2. If your computer is set up for DHCP, remove the /etc/dhcp.<interface> (example: e1000g0)
3. Edit the /etc/nodename and add this line
   sol1
4. Edit the /etc/hostname.<interface>  file (e.g e1000g0  /etc/hostname.e1000g0)
   sol1
5. Edit the /etc/inet/ipnodes file and add this line
   10.0.0.153    sol1
6. Edit the  /etc/inet/hosts file and add this line:
   10.0.0.153    sol1
   and also modify this line:
   127.0.0.1 localhost.localdomain localhost sol1
   
7. Edit the /etc/defaultdomain file  (if it doesn't exist, create it), just write this line:
   corp.contoso.com
8.  Edit the /etc/netmasks file and add this line
   10.0.0.0    255.255.255.0
9. Edit the /etc/resolv.conf file and add:
   search corp.contoso.com
   nameserver 10.0.0.1
10. Verify that the /etc/nsswitch.conf is configured to resolve hosts using dns (add if necessary)
    cat /etc/nsswitch.conf | grep dns   You should see results for hosts and ip nodes, if not, add these lines:
    hosts:    files dns
    ipnodes:  files dns
11. You may have to restart the server (if you changed the /etc/nsswitch.conf file or restart the network (svcadm restart physical).
12. Verify the configuration  (hostname, DNS configuration, ping test to crl.corp.contoso.com)
    # hostname
    sol1
    # cat /etc/resolv.conf    (look for the two lines below)
    search corp.contoso.com
    nameserver 10.0.0.1
    # ping crl
    crl is alive
13. This verifies that the TCP/IP configuration is correct and that SOL1 is using DC1 for DNS.
14. Verify that the NSCD daemon is running$ svcs \*name-service-cache\*STATE          STIME    FMRIonline         Dec_24   svc:/system/name-service-cache:default
15. Create a couple of users useradd -m centrifying
    useradd -m -c "Jesse Matthews" jmatthews

Modify the UNIX/Linux to skip the graphical interface

We don't need to run the platforms in graphical mode since these systems are purposed as servers.

On CEN1 and SUSE1

1. Log in as a privileged user (or root) and open a terminal
2. Edit the /etc/inittab
   id:3:initdefault:
3.  Reboot the server to start in Multi-user, server mode.

 On SOL1

1. Log in as a privileged user (or root) and open a terminal
2. Disable the graphical interface
   /usr/dt/bin/dtconfig -d
3.  CDE or Java desktop have been disabled.

 Test connectivity from CLIENT1 using PuTTY

1.  Log on to CLIENT1 with a domain user
2. Open PuTTY and try to connect to the UNIX/Linux hosts.
3. Optional:  Create Saved Connections to each host.

Note:  It is not recommended that you allow root login over SSH in production systems.  If you prefer to dot his in your lab (which you should not, to develop good habits), you nee to make sure that the /etc/ssh/sshd_config file has the PermitRootLogin parameter set to yes.

 Copy the Centrify agent to each system

1.  Open Windows Explorer and browse to \\APP1\Files
2. From CLIENT1, open WinSCP
3.  Connect to CEN1.  Create a temp folder in the root of the filesystem /
4. Open /temp
5. Drag the file centrify-suite-2013.3-rhel3-x86_64.tgz (from the \\APP1\Files explorer window) into the /temp window in WinSCP and click copy.
6. Repeat the process for the next two files:
   centrify-suite-2013.3-sol9-x86.tgz goes into /temp of SOL1
   centrify-suite-2013.3-suse9-x86_64.tgz goes into /temp of SUSE1
7. Log-off CLIENT1

Lab End State

About Access Controls (Identity and Access Management)

The challenge with organizations, capabilities and projects

Many security solutions provide technical capabilities, but the sad truth is that many customers see these solutions like a project that must be implemented and forgotten.  This is why is hard to sell solutions in the Identity and Access Management space.

What's a capability?
According to the Free Dictionary,  a capability is  "the capacity to be used, treated, or developed for a specific purpose."  In the context of IT infrastructure, an IT capability typically is a triad:

• People:  members of the organization need to have the cognitive knowledge, skills and experience to launch and operate the capability.
• Process:  processes govern how the capability is implemented
• Technology:  the tools that aid in the implementation of a capability. 

Any security capability has to be aligned with Security Policy, and the security policy responds to the business risk factors. Policies are just statements, the implementation of the policies may be simple controls or fully managed capabilities.

IT Capability Fragmentation
Fragmentation happens when capabilities are duplicated (due to lack of knowledge, legacy, politics or status quo) and negatively affects the organization's agility or operational efficiency.

About Security Controls
Security controls can be preventive, corrective or detective controls, and are implemented as administrative, technical or physical controls.  A risk is truly mitigated if controls have been implemented to prevent the event from happening, to correct or recover from the event, and detect the event during or after it happens.

Access Controls
Access controls are the security capabilities that deal with the controls for Authentication, Authorization and Privilege Management and Auditing.

Authentication verifies the user's identity using different factors.  The most common is username and password (single factor).
Authorization determines if a user (or subject) is able to perform an action against an object (or resource).  Controlling what people can do in the context of operating systems, applications, resources, etc. is part of privilege management.
Auditing is the accounting of what a subject (user) actions.

What's a Directory Service?
According to Wikipedia, a directory service is the software system that stores, organizes and provides access to information in a directory.  There are many directories out there, but we will be focusing on Microsoft's Active Directory (AD).

What this blog is about?
The objective of this blog is to build a recipe of background information, use cases, requirements, solutions, step-by-step guides and any other information to leverage the Centrify Server Suite and Active Directory to address the challenges of Unix and Linux administrators in the Identity and Access Management space with deep focus on access controls.  We will attempt to marry the business and security needs with the implementation of these tools.  The ultimate goal is to achieve operational efficiency by reusing existing infrastructure, processes and knowledge. 

Tools and Methodologies
We will use existing resources like the Microsoft Test Lab Guides and the Plan-Do-Check-Adjust methodology.

Acknowledgements and Legal Notices
Active Directory, Forefront Identity Manager, SQL Server, Exchange Server are products and trademarks of Microsoft Corporation
CentOS is a trademark of the CentOS project
Solaris is a trademark of Oracle Corporation
SUSE is a trademark of Novell Corporation
Centrify, Centrifying, DirectControl, DirectAuthorize, DirectAudit, DirectSecure are trademarks of Centrify Corporation