Tuesday, December 31, 2013

Basics: Managing UNIX groups from Active Directory with Centrify

Background

With Centrify, UNIX group membership can be managed from AD Security groups.  There's basically a 1:1 mapping between the AD group and the UNIX group.
Note:  In version 2016 of Server Suite, Centrify has added the ability to manage local UNIX groups. Here's a post on how to test the feature: http://centrifying.blogspot.com/2016/01/labs-testing-local-account-management.html

Planning

UNIX groups may be used for different purposes, may contain different members and can mean different things for different administrative groups.  The most important goal is standardization in management, therefore the system administrators have to get together to answer these questions:

  • What is this group used for? Why?
  • Is this group still relevant?
  • Will this group be deprecated by any of the authorization components?
    This is very important, for example, Netgroups are not needed anymore with Centrify zones and Computer Roles.  The other important note is that Role Assignments eliminate the need to maintain UNIX groups for the purpose of sudo usage.
  • How many groups are uniquely identified?
  • Are there any groups that are defined differently in other systems?
  • Are the group memberships uniform?  Are there groups that have network and local users?
  • Is this a primary group for all  or a set of users?
  • What is the impact of changing the definition?
  • What is the impact of the unavailability of the group?
  • Is the group in AD going to be managed manually or with a tool?
  • Are there any workflow and approvals required?
  • Is the group subject to any attestation exercises?
  • What will be the naming convention for the AD group that corresponds to the UNIX group?
  • What is the scope of the AD group (Domain Local, Domain Global, Universal)?
All these questions need to be answered with a catalog of groups, definitions, members, etc. in a serious table-top exercise.  Because groups are units of identity management, the decisions made here can affect zone design.  
A common issue seen in the field is that a group is part of a legacy infrastructure not understood by the current management team, therefore they decide to keep the status-quo and not compromise on governance, naming or GID to be assigned, this adds complexity rather than understanding the real impact of the group.

For example:
UNIX Group:  db2-dba
UID: 1001
Group Membership:  Includes local account db2inst.
Note: This means that the agent has to be configured to merge NSS group memberships.
Purpose: Used to identify the db2 Database Admins.
Any different definitions:  No
Managed:  Manually
Attestation:  Yes
AD Standards:
                        AD Group Scope:  Domain Local
                        AD Container: UNIX Groups,
                        AD Naming Convention: UNIX-<Zone Name>-Unix Name.   UNIX-HQ-DB2 DBA

Creating the Group Mapping (Do)

Creating the UNIX Group
  1. In Access Manager, go to the Zone/UNIX Data and right click Groups and select Create UNIX Group
  2. In the Find window, find the corresponding UNIX group (e.g. UNIX-HQ-Wheel), select it and press OK
  3. Set the UNIX name (preferable  8 characters depending on platform(s) to be supported) and set the GID.

Populating the Group
  1. From ADUC, find and open the group, go to the members tab, click add and add any user principal that has been UNIX-enabled.
  2. From Access Manager, right click the UNIX group, select AD properties and follow the steps outlined above.
  3. From UNIX using adedit:
    a) Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
    b) bind to the domain
    >bind corp.contoso.com
    c) add the ade_lib library
    >package require ade_lib
    c) use the add_user_to_group function
    >add_user_to_group "jessie.matthews@corp.contoso.com" "UNIX-HQ-DB2 DBAs@corp.contoso.com"
Note:  Remember that you can use an Identity Management tool, a script (VB, PS) to populate an AD Group.

Process Reuse:  Now your organization can reuse the existing process and tools to manage the memberships to UNIX systems.

Verifying the Membership (Check)

You can always get a snapshot of the Members tab of the AD Group, however, here are some alternatives.

On UNIX with the getent command
  1. Log on to a system in the zone that the UNIX group was created.
  2. Use the getent command.  E.g. (for db2dba)
    $ getent group db2dba
    db2dba:x:1001:jessie.matthews
On UNIX with the adquery command
This report is great because it can mix the AD and local users if the agent was configured to merge them.
  1. Log on to a system in the zone that the UNIX group was created.
  2. Use the adquery group command.  E.g. (for db2dba)
    $ adquery group db2dba
    db2dba:x:1001:jessie.matthews
On UNIX with adedit
Log on to a system in the domain.
  1. Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
  2. bind to the domain
    >bind corp.contoso.com
  3. Set the object distinguished name
    >set obj_dn [principal_to_dn "UNIX-HQ-DB2 DBAs@corp.contoso.com"]
  4. select the object just retrieved
    >select_object $obj_dn
  5. Query the group members
    >get_object_field member{CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com}

On Windows from the Command Line
  1. On a computer with the AD DS tools installed, open the command prompt
  2. Run the dsget command  (eg. for the UNIX-HQ-DB2 DBAs group)
    dsget group "CN=UNIX-HQ-DB2 DBAs,OU=UNIX Groups,OU=UNIX,DC=corp,DC=contoso,DC=com" -members
    CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com"
On Windows with Access Manager Reporting
  1. On a computer with Access Manager installed, go to the Reports node.
  2. Create your own report or reuse the Groups Report (pre-created)

(Adjust)ing the Group 

Some of the events that may require an adjustment are:
  • Merging local users in the result:   This is needed in situations in which a local group (existing in the /etc/group) that contains a local user needs to be merged with the AD-managed group.   This is documented in the centrifydc.conf file:
    adclient.local.group.merge  (by default false) - use with caution.
  • Adjusting the GID:  This may be required if redefining the group's unique identifier. It can be facilitated by tools like adfixid.

Saturday, December 28, 2013

Basics: UNIX-Enabling Active Directory Users

Background

In a previous posting we discussed how UNIX systems identify users.
By default, UNIX/Linux systems using Centrify in Zone mode do not allow any user to log in to the systems unless they have:
  1. A UNIX Identity (login, UID/GID, Home, Shell and GECOS)
    This is what we call "UNIX-enabling" a user (hence the title of the posting)
  2. A role that allows the user to log-in.
UNIX-enabling simply means to provide a user (or a group) a UNIX identity in a Centrify Zone in Active Directory

Since we have established the Plan-Do-Check-Adjust model.  Here is the model for UNIX identities and Access

(Plan)ning UNIX Identities

  • Having a proper naming and identification strategy
    • What is the right login name?  Are there systems that don't like more than 8 characters?  (like HP-UX or AIX)
    • Does it have to be programmatically derived
    • What are the considerations for home directories?  Is there a central filer?
    • Is there an enterprise Shell?
    • Does anything need to be added to the GECOS field?
    • Are there different primary groups and secondary groups (other than private)?
  • What is the current state?
    • Is the namespace normalized(*)? Or does it need to be cleaned up?
      Are there users with different UIDs across systems?
      Are there different GID definitions for the same system?
      Are UNIX group memberships uniform?
    • Does the organization engage in Mergers and Acquisitions?
  • What will be the strategy if the company acquires another organization that has UNIX systems?
  • Are Samba or NFS in use?
(*) normalization is the process of rationalizing the names pase so everyone has a unique UNIX identity across the enterprise.  This is not a pre-requisite to deploy Centrify.

UNIX-enabling Users with Centrify (Do)

Users can get UNIX profiles using various methods:
  • Manually via Access Manager., Active Directory Users and Computers or ADSIEdit
  • Automatically via Centrify Zone Provisioning Agent
  • Automatically with any programming interface that can manipulate AD  (On Windows using vbscript, PowerShell, etc, and on UNIX/Linux using adedit).

Manual Method 1:  From Windows using Access Manager

  1. In Access Manager, expand the Zone, then UNIX Data, and right click Users.  
  2. Select Add Users to Zone
  3. In the Find box, type the name of the AD User account that is going to be enabled.  Select it and press OK
  4. Now, check all the boxes to pick the defaults OR, override each value to match your needs.

Manual Method 2:  From Windows using ADUC

Note: ADUC needs to have the Centrify Profile tab installed and activated
  1. In ADUC, right click the user object to UNIX-enable and select Properties
  2. Go to the Centrify Profile tab and select Add.  
  3. In the find window, press find and select the zone that the user will be added to.
  4. Follow the instructions from Step 3 above.

Manual Method 3:  From UNIX using adedit

Adedit is a TCL-based programming language included with the Centrify agent.
  1. On a Centrified UNIX system, type /usr/bin/adedit
  2. Bind to the domain with the proper credentials
    bind corp.contoso.com
  3. Select the zone to add the user to
    select_zone "cn=HQ,OU=Zones,OU=UNIX,dc=corp,dc=contoso,dc=com"
  4. Unix-enable the user
    new_zone_user jessie.matthews@corp.contoso.com
  5. Specify the UNIX identity
    set_zone_user_field uname jmatthews
    set_zone_user_field uid 0x8000000
    set_zone_user_field gid 0x8000000
    set_zone_user_field gecos "Jessie Matthews"
    set_zone_user_field home "%{home}/%{user}"
    set_zone_user_field shell "%{shell}"
    Note:  the 0x8000000 code after UID/GID specifies to use uniquely genereated code that is derive dfrom the AD object's SID.  Also, the variables under home and shell, allow this information to be picked based on the system's defaults.
  6. Verify the information
    show
    Bindings:
            corp.contoso.com: dc1.corp.contoso.com
    Current zone:
    CN=HQ,OU=Zones,OU=UNIX,DC=corp,DC=contoso,DC=com
    Current nss use:
    jessie.matthews@corp.contoso.com:jmatthews:1149240406:1149240406:Jessie Matthews:%{home}/%{user}:%{shell}:
  7. Save the Object
    save_zone_user

Manual Method 4:  From Windows using Centrify PowerShell

  1. On a Windows system with the Active Directory or Centrify PowerShell Modules
  2. Open PowerShell or PowerShell ISE as a user that has the rights to add and modify user profiles in the zone.
    Load these modules:
    Import-Module ActiveDirectory
    Import-Module Centrify.DirectControl.PowerShell
  3. Bind to the Centrify Zone in question
    $zone = Get-CdmZone -Name "HQ"
  4. Unix-enabling Jessie with defaults
    New-CdmUserProfile -Zone $zone –User jessie.matthews@corp.contoso.com -login jessie.matthews -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

Granting a UNIX Role

Once the user has an identity, the next step is to give him (or her) a role that grants them the ability to log in(*).  By this point a roles exercise has been conducted and the proper AD groups have been assigned UNIX roles.  This means that ADUC, Scripting/Programing, Identity Management Solutions and many other tools
(*) This is because users can be listed in a system, with no rights to log-in.

From Windows using ADUC
  1. Open ADUC and find the AD Group that has been assigned the role.
  2. Go to the Members tab and Click Add
  3. Find the newly UNIX-enabled user and Press OK Twice.

From UNIX Using adedit
  1. Log into UNIX/Linux with an account that can modify the group (or use kinit) and open adedit
  2. Bind to the domain
    >bind corp.contoso.com
  3. Add the ade_lib library
    >package require ade_lib
  4. Use the add_user_to_group function
    >add_user_to_group "jessie.matthews@corp.contoso.com" "UNIX Super Users@corp.contoso.com"
With PowerShell
Add-ADGroupMember "UNIX Super Users" -members "Jessie.Matthews"

At this point, when the cache refresh interval hits in the UNIX computer, the user will have the ability to log in with the corresponding role.


Verify the Access (Check)

There are multiple ways to check that the right identity and access have been provided:
  • In Windows:  via ADUC, Access Manager's User Effective Rights or Reporting
  • In UNIX with the adquery command and the dzinfo command.

To Verify the Identity in ADUC or Access Manager
  1. In ADUC, go to the user's properties, in the Centrify Profile tab, and double-click the entry.
  2. In Access manager, go to the Zone/UNIX Data/Users and double-click the user
  3. In any UNIX/Linux System in scope, run the adquery user <user name> command:
    $ adquery user jessie.matthews
    jessie.matthews:x:1149240406:1149240406:Jessie Matthews:/home/jessie.matthews:/bin/bash
To verify the level of access:
  1. In Access manager, go to the Zone/UNIX Data/Users and right-click the user and select "User Effective Rights"
  2. Select the system that you want to verify the level of access and review the settings.
Or
1. In Access Manager, go to the Reporting node.  Select the User's report or the UNIX User Effective Rights report, expand it, right click current and select Display Report

Review the systems that the user has access and what rights have been granted.
                                                                               Or 
In any System in scope, run the dzinfo <username> command.


 

(Adjust)ing the Identities or Roles assigned to a user

Due to various reasons there may be a need to adjust the user's identity or the role(s) that they may have in the systems.  Review the previous steps to perform any adjustments.  However, the most common operations are:
a) Identity Overrides:  This is when any of the default settings are modified.  E.g. they system admin does not want to change ownership of files and folders in multiple systems.  At this point he can change the UID/GID of the user to match their existing one.
b) Identity de-provisioning:  A user does not need access to UNIX systems anymore.  At this point their UNIX identity can be removed.
c) Access Changes:  A user may need to have access to more (or less systems) than required.  This may mean that they need to be added (or removed) from role assignments at the Computers Group level.
d) Temporary Access to a single or multiple systems:  These are normally exceptions. They can be dealt with temporary role assignments or computer level overrides.

Tuesday, December 24, 2013

Lab # 7: Installing the Centrify agent and joining Active Directory

In this lab

  • We will install the Centrify agent in CEN1 using RPM and join Active Directory manually
  • We will install the Centrify agent in SUSE1 using install.sh in interactive mode and join Active Directory manually
  • We will install the Centrify agent and join Active Directory on SOL1 using install.sh in unattended mode.
  • We will use some of the tools and CLI commands including with the base agent.

 Install Centrify on CEN1 using RPM

  1. Log in to CLIENT1 with Jessie Matthews (UNIX administrator) account.
  2. Open PuTTY and connect to CEN1
  3. Go to the /temp folder (or where you copied the Centrify agent files)
  4. Decompress the tarball (elevate if necessary)
    tar xzvf centrify-suite-2013.3-rhel3-x86_64.tgz
  5. Use RPM to install the base agent centrifydc-5.1.2-rhel3-x86_64.rpm
    rpm - Uvh centrifydc-5.1.2-rhel3-x86_64.rpm
  6. To verify that Centrify is installed, run the adinfo command.  Notice the output
    $ adinfo
    not joined any domain
    Licensed Features: Enabled

    The last line means that the agent can see a valid license in AD.

Join CEN1 to Active Directory

Information
Domain to join:  corp.contoso.com
Place to put the computer account:  "OU=Servers,OU=UNIX"
Zone to join:  HQ
User account that can join systems to the target container:  jessie.matthews
Desirable command output:  verbose
  1. Type the following command (requires elevation if you're not root):
    sudo adjoin -z HQ -c "OU=Servers,OU=UNIX" -V -u jessie.matthews corp.contoso.com
  2. Type the sudo and Jessie's AD password when prompted.
  3. To verify that the computer has joined successfully, type the adinfo command:
    [centrifying@cen1 temp]$ adinfo
    Local host name:   cen1
    Joined to domain:  corp.contoso.com
    Joined as:         cen1.corp.contoso.com
    Pre-win2K name:    cen1
    Current DC:        dc1.corp.contoso.com
    Preferred site:    CorpHQ
    Zone:              corp.contoso.com/UNIX/Zones/HQ
    CentrifyDC mode:   connected
    Licensed Features: Enabled
  4. Exit the PuTTY session.

Install Centrify on SUSE1 using install.sh

  1. Open PuTTY and connect to SUSE1
  2. Go to the /temp folder (or where you copied the Centrify agent files)
  3. Decompress the tarball (elevate if necessary)
    tar xvfz centrify-suite-2013.3-suse9-x86_64.tgz
  4. Use the install.sh and in interactive mode, select a custom installation and accept the DirectControl Agent, select N for the rest of the options.
    How do you want to proceed? (E|S|X|C|Q) [E]:C
    Install the Centrify DirectControl 5.1.2 package? (Q|Y|N) [Y]:Y
  5. When presented with the confirmation option, select Y.
    You chose Centrify Suite Custom Edition and entered the following:
        Install CentrifyDC 5.1.2 package: Y
        Install CentrifyDC-nis 5.1.2 package: N
        Install CentrifyDC-openssh 5.1.2 package: N
        Install CentrifyDC-ldapproxy 5.1.2 package: N
        Install CentrifyDA 3.1.1 package: N
        Express authentication mode      : N
        Run adcheck                      : N
        Join an Active Directory domain  : N
If this information is correct and you want to proceed, type "Y".
To change any information, type "N" and enter new information.
Do you want to continue (Y) or re-enter information? (Q|Y|N) [Y]:Y


To join SUSE1 to AD, follow the instructions outlined for CEN1.  Keep in mind that the adjoin command is in /usr/sbin in case you don't have it in your path.

Install the Agent and Join AD on SOL1 using an unattended installation

  1. Open PuTTY and connect to SOL1
  2. Go to the /temp folder (or where you copied the Centrify agent files)
    You may need to su to root or use Solaris roles to perform the following tasks.
  3. Run tar to decompress the tarball
    tar xvf  centrify-suite-2013.3-sol9-x86.tar
  4. Edit the following lines in the  centrifydc-install.cfg file.  Uncomment lines if necessary.
    ADJOIN="Y"
    DOMAIN="corp.contoso.com"
    USERID=jessie.matthews
    PASSWD=Jessie's or your user's password
    CONTAINER="OU=Servers,OU=UNIX"
    ZONE=HQ

    Comment the following line (add a # in front of it)
    #CentrifyDC_openssh=
    This is to stop Centrify OpenSSH from being installed with the base package.
  5. Save the file.
  6. Run install.sh in non-interactive mode
    ./install.sh -n
At this point the script will run adcheck and read the unattended file.  Some output:
Joining the Active Directory domain corp.contoso.com ...
Using domain controller: dc1.corp.contoso.com writable=true
Join to domain:corp.contoso.com, zone:HQ successful
Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: corp.contoso.com
in the Centrify DirectControl zone: CN=HQ,OU=Zones,OU=UNIX,DC=corp,DC=contoso,DC=com

Verify the objects in Active Directory

Open ADUC and expand the corp.contoso.com domain, expand UNIX, then Expand Servers.
  1. Verify that the two new computer objects are present  (refresh if necessary)
  2. Right-click the CEN1 computer object, select Properties and go to the Operating System tab.
Notice that the OS type and version exhibit the proper version.

Add each system to their corresponding computer group

  1. Open Access Manager and Navigate to the Zones/HQ/Authorization/Computer Roles node
  2. Expand Database Servers, right click Members and select Add Computer
  3. In the find box, type cen1;  click on cen1 from the results box and press OK.
  4. Expand Web Servers, right click Members and select Add Computer
  5. In the find box, type suse1;  click on suse1 from the results box and press OK

Now all the systems are joined in to AD and properly categorized, we are ready to start working with users and accessing systems.


Appendix

Installing Using a YUM Repository
http://centrifying.blogspot.com/2015/11/setting-up-simple-yum-repository-to.html
Installing Using a Simple Chef recipe
http://centrifying.blogspot.com/2015/11/deploy-centrify-and-join-active.html
Tools: Install.sh
http://centrifying.blogspot.com/2015/10/utilities-installsh.html

Basics: Installing the Agent, Joining Active Directory and About Computer Accounts

Installing the Agent - Multiple Avenues

Centrify provides multiple ways for system administrators to install and deploy the Centrify agent.  The agent (adclient) is supported in a variety of systems; the rule of thumb is this:  any commercial system that uses PAM and NSS is likely to be supported.  A great resource is this page.
The installation options are:
  • Native packages:  Centrify includes native packages for each platform (rpm, deb, etc.)
    The benefit of native packages is that it allows the use of existing package management and software distribution, repositories or configuration management platforms. Here's an example with YUM.
  • The installation script (install.sh):  This is an orchestrator that will install the software based on an interactive menu or an answer file.
    The benefit of install.sh is that it allows for easy manual setup and the integration of scripting.
  • DevOps tools like Chef, Puppet, Satellite or Ansible:
    - Example with Chef
    - Example with Puppet
  • Deployment Manager:  This is a free tool included with the suite designed to aid in deployments for very small environments.  It's not a substitute for a software distribution or configuration management solution.
    Moderation Note:  Deployment Manager is not covered in this blog.
When the Centrify agent is installed, the binaries are in place, but there are no changes to the system until it is joined to Active Directory.

Joining Active Directory on Windows - Basics

When a Windows computer joins Active Directory (at a very high level) these operations are performed:
  1. The user account performing the join operation is checked for the right authorization
  2. AD is checked for any duplicate computer account names
  3. A computer object is created for the computer account
  4. A secret is shared between Active Directory and the Computer
    This shared secret allows for encrypted communications (secure channel), Kerberos ticket processing, etc.
  5. Domain Users (and any trusted domains) become users for the computer
  6. Domain Administrators can perform administrative duties in the computer
  7. Targeted Group Policies are set to be processed
    Note:  to really find out what happens when you join a Windows computer, just read the NETSETUP.LOG file under the system folder  (or %systemroot%)\debug folder.
In general there are 3 major pre-requisites to perform a join in Windows:
  • The system needs to be able to resolve the name of the domain (proper DNS configuration)
  • The system needs to be able to establish communications correctly
  • The user account performing the join is authorized for the operation in the target container
The process is very similar with the Centrify agent, step 5 being the most notable exception.  In standard edition in zone mode, only Unix-enabled users with the proper rights can log in to the AD-joined UNIX/Linux system (centrified system).

Joining UNIX/Linux (and Mac) systems to Active Directory - Basics

 
adcheck - the Quality Assurance tool

adcheck is a tool included with the package that is used to assess the readiness of the system to join AD.  The general syntax is:  ./adcheck-platform domain
E.g. for RedHat 64 bit:   ./adcheck-rhel3-x86_64 corp.contoso.com
It's also a great tool to troubleshoot connectivity issues.   It will check

OSCHK    : Verify that the system is supported by that version of the package.
PATCH    : If there's any pre-requisite OS patches (great for AIX, HPUX and Solaris)
PERL     :  Perl is required to perform the installation tasks and to process group policies.
SAMBA    : If the system is running it, will warn to use Centrify-enhanced Samba for proper UID/GID assignments
SPACECHK : Check if there is enough disk space in /var /usr /tmp
HOSTNAME : Verifies if the hostname is acceptable (localhost and some others aren't allowed)
NSHOSTS  :  Verifies the configuration of this entry in the /etc/nsswitch.conf
DNSPROBE : Will try to communicate the DNS servers.  Will warn if there's only one entry.
DNSCHECK : Same as above.
WHATSSH  : Verifies that the SSH version has been tested and there's no issues.  It will warn to use Centrify-enhanced SSH if you will use Kerberos authentication.  Stock SSH will be fine.
SSH      : Checks the SSH configuration
DOMNAME  : Will check for the domain name, it will warn if it's a .local domain.
ADDC, ADDNS, ADPORT, GCPOR, DCUP, SITEUP: It will perform a series of checks:
- SRV records for the domain
- DNS communications
- Will verify that the proper communication ports are open for each DC and Global Catalog
- Will check for domain controllers in the AD Site.
DNSSYM   :  It will check the consistency of the DNS configuration.
ADSITE, GSITE:  It will check that the subnet is within an AD Site and that the correct site is selected.
TIME     : It will check that the clock between AD and the local time source is not skewed more than 5 minutes (Kerberos requirement)
ADSYNC   : It will check that the domain controllers are in the same page.
Typically, the most common issues are around DNS configuration, Communications, DNS symmetry and clock skews. Solve all the issues before moving forward. Warnings can be typically ignored but should be addressed depending on the situation.  After that, you can move on to join the system

adjoin - to Join Active Directory Domains

With Centrify, computers can be joined with:
  • install.sh in interactive or unattended (quiet) mode
  • the adjoin command
  • with Deployment Manager
All these methods ultimately use the adjoin command.

Joining a system is a privileged operation, so it has to be performed as root or elevating with sudo.

Adjoin Syntax

usage: adjoin [options] domain
options:
  -u, --user user[@domain] user name
  -p, --password pw        user password, prompts if absent
  -c, --container dn       subtree to create below or move to.
                           LDAP is used to create computer object,
                           if computer object does not exist.
  -n, --name comp          computer account name
  -N, --prewin2k name      pre-windows 2000 computer account name
                           must be 19 characters or less
  -D, --dnsname name       optional parameter to override the
                           dNSHostName attribute in the computer object
  -f, --force              overwrite existing joined computer
  -a, --alias alias        add an alias computer account name
  -C, --noconf             do not update PAM or NSS config
  -z, --zone zone          zone to join
  -s, --server ds          domain server for join operations
  -Z, --zoneserver ds      domain server for zone operations
                           useful if zone is in another domain
  -g, --gc ds              domain server for global catalog searches
  -U, --upn upn            user principal name for the account
  -T, --trust              trust computer for delegation, requires
                           administrator permission
  -k, --des                use DES key only
  -P, --precreate          precreate computer and extension object
  -m, --compat             make computer and extension object
                           compatible with DirectControl 2.x.
  -S, --selfserve          use reset computer account credentials to perform
                           a self-service join
  -w, --workstation        join computer to Auto Zone
  -l, --ldap               use LDAP method to create the computer object
  -x, --extramap mapname   add named nss map to nss configuration. Can be repeated
  -i, --noinit             skip cache preload
  -A, --attempt            attempt to grant authenticated users read permissions to PSO objects so that the computer account can read fine grain password security policies in the current domain.
Note that the administrator(s) may also need to grant authenticated users read permissions to PSO objects in trusted domains and forests as well for more accurate password expiration times for cross domain and cross forests users.
  -v, --version            print version information
  -V, --verbose            print debug information for each operation
  -h, --help               print this help information and exit.

Example:  To join the corp.contoso.com domain in the HQ zone, place the computer account in the Servers OU under the top level UNIX OU in verbose mode with Jesse's AD account, the adjoin command is:
adjoin -z HQ -c "OU=Servers,OU=UNIX" -V -u jessie.matthews corp.contoso.com

What happens in a system when you join Active Directory?

Several things happen:

Type

On


File location


Kerberos configuration file


Most platforms


/etc/krb5.conf




Solaris


/etc/krb5/krb5.conf


Kerberos keytab file


Most platforms


/etc/krb5.keytab




Solaris


/etc/krb5/krb5.keytab


NSS configuration file


Most platforms


/etc/nsswitch.conf


PAM configuration file


Red Hat Linux


/etc/pam.d/system-auth




All other Linux


/etc/pam.d/*




HPUX, Solaris


/etc/pam.conf


LAM configuration file


AIX


/usr/lib/security/methods.cfg


Login control files


AIX


/etc/security/user
The previous configuration is saved to be restored if the system leaves the domain.
(*) Note that these changes only apply to the centrifydc (adclient) program.  If you also install Centrify-enhanced OpenSSH, other modifications pertaining to the SSH server are made.

Sample entries in /etc/nsswitch.conf file after a system is joined to AD:
passwd:   centrifydc    nis   files
shadow:   centrifydc    nis   files
group:    centrifydc    nis   files

What does this mean?
Name Server Switch is a UNIX facility that allows for network-based services, including directory services.  As a consequence:

a) Any NSS-enabled program will check for the user or group in AD (centrifydc), an existing NIS domain, and then in the local /etc/passwd or /etc/group files. 
b) Users from local files, NIS or LDAP can coexist happily, also migrations are easier because they can be done in a phased-approach.
c) This also means that local users, service accounts and super user accounts are available and can be managed locally.
d) Hands-off approach:  any NSS (or PAM, or Kerberos-related) file does not need to be touched.  Centrify makes it work out of the box.  This includes if there's any changes in Active Directory.

Entries in the /etc/pam.d/system-auth

# lines inserted by Centrify Direct Control (CentrifyDC 5.1.0-494)
auth       sufficient     pam_centrifydc.so
auth       requisite      pam_centrifydc.so deny
account    sufficient     pam_centrifydc.so
account    requisite      pam_centrifydc.so deny
session    required       pam_centrifydc.so homedir
password   sufficient     pam_centrifydc.so try_first_pass
password   requisite      pam_centrifydc.so deny

What does this mean?
PAM is a framework to allow program to leverage authentication services.  Therefore, any PAM-enabled program will perform the account, password, session and authorization checks using Centrify's shared libraries in addition to the existing system methods.  For example, if a UNIX-enabled AD user issues the passwd command, since this command is PAM-enabled, the password module will be invoked to enforce things like length, complexity, expiration, etc. in AD  (defined in Group Policy).
At this point you define policy once (in AD) and it will be enforced in the Centrified UNIX/Linux system in addition to Windows.  More process and policy reuse!

The opposite of joining a domain is leaving the domain, and since Centrify's tools are very consistent the command is adleave.

How do I know if a system is joined to AD?
Use the adinfo command.
If the system has the Centrify binaries but is not joined to a domain, the output is
No joined to any domain
Licensed Features: Enabled

If the system has the Centrify binaries and is joined to a domain, the output is
Local host name:   suse1
Joined to domain:  corp.contoso.com
Joined as:         suse1.corp.contoso.com
Pre-win2K name:    suse1
Current DC:        dc1.corp.contoso.com
Preferred site:    HQSite
Zone:              corp.contoso.com/UNIX/Zones/HQ
CentrifyDC mode:   connected
Licensed Features: Enabled

Notice that the output of adinfo is very helpful to understand what is going on in your system and the agent.  You can tell how the system was joined, to what domain, what domain controller the agent is talking to, and if there's communications to AD.

About Computer Accounts

In Active Directory, computer accounts (just like user accounts) have passwords too, and by default they change automatically every 30 days, this applies to AD-joined systems using Centrify.
Computer accounts can belong to AD Groups.  In fact, Centrify Computer Roles (the collections of systems) are all contained within a previously created AD group.  E.g. in our lab, we have a UNIX Database Servers group, to hold the computer accounts of Database Servers.

Process and knowledge reuse

All the processes outlined by Microsoft (add, remove, move, pre-create, disabling, renaming, etc.) can be performed with centrified systems.  http://support.microsoft.com/kb/320187 
These operations affect provisioning processes, operations and even group policy processing.  Most likely, any major organization has processes in place for Windows computer accounts and they can be leveraged for the UNIX/Linux  (or Mac) systems.

Update 1  (March 2015)

This update is based on feedback, the original post has been left intact, typos and all.

Should I install Centrify-enhanced OpenSSH?
Short answer:  No
Why would you need Centrify OpenSSH?
  • If you have a version of SSH Server that is not compiled/configured for PAM support.
    Older box UNIXes used not to be ready out of the box (e.g. old HPUX, AIX, Solaris)
  • If you want granular PAM access controls to be set up automatically for you.
    For example, if you wanted to set up an account to be able to only scp a file, but not login. Centrify-enhanced OpenSSH has all those settings done for you.
  • If you want optimized Kerberos or GSSAPI support on SSH
    This version of OpenSSH is compiled to use the Centrify AD shared objects and MIT Kerberos tools.  This means that in scenarios with complex AD infrastructures (one-way trusts, etc) you don't have to worry about SSO working.
  • Smartcard Environments
    Somewhat related to the previous bullet.  In some environments, interactive sign-on is with Smartcard, then the rest is via Kerberos.
Basically the answer is No, but choosing Yes, helps in many advanced scenarios.

Should the system be restarted after Centrify installation and AD join?

The answer really depends.  Most of the time the answer is no, but the determining factor is have long-running daemons (e.g. like DB2 on UNIX, or X-Window, etc), then a restart is in order.  This is because unlike dynamic daemons (like sshd) these programs only read the PAM configuration at start-up.

A note of warning
My advice is that you reboot the system PRIOR to installing any new program.  This is because most of the pride of UNIX, Linux and post 2008 windows admins is uptime, but the longer the system is up, the more possibility that changes may have been made while the system was running.  Services may have been altered, environment variables modified but not committed, etc.  

If the system restarts, and something is not right, the logical conclusion will be to blame it to the last program that was installed. This leads to flawed troubleshooting and possibly introducing additional issues.  So, prior to a major change, have the system(s) rebooted and working again for a week, then the next window the programs or upgrades can be performed and any failures can be attributed to the recent event with accuracy.

Monday, December 23, 2013

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.